 All right, it looks like we are officially live now. Hi, my name is Joe Brockmeyer and today we are doing an cloud chat Moderating the chat. This is going to be sort of a preview What we're going to be doing at the enterprise end user summit in a couple of weeks in New York City Today we're going to have with us Greg de Konigsberg and we're also going to have Alan Clark Believe Chip Childers from the cloud stack project is going to be joining We're also expecting Richard Morrell from Red Hat. Greg of course is from Eucalyptus and Alan is with Sousa And open stack So we're going to go through some questions We've already gotten prepared and we're also going to ask you if you have any questions You'd like to see the panel answer to go ahead and submit those in chat and our offline moderator will be So those questions to go through So let's go ahead and get started with some of the questions. We already have prepared first question a lot of people are concerned about portability others chip hi chip A lot of people are concerned about cloud portability So I want to open up the floor to talk a little bit about the importance of portability What it means to you and what kind of tools users need to have to really be portable across cloud Sorry Greg you want to get started? sure So Eucalyptus has a particular place in the world and so I speak from that perspective and and that perspective is that AWS is the dominant public cloud by an order of magnitude And we feel like it is a worthy endeavor just to focus on making interoperability with AWS clouds as easy as possible For those who want their own open source private cloud so We feel like Interoperability is of course hugely important and it's going to be getting more important all the time and our very particular take on that is to Have those people who are sort of hooked on AWS making sure that they've got a good open source option Okay, thanks Greg Chip you want to respond to that or you have anything to add or what are your thoughts on? Yeah, you know portability is one of the more complicated topics in the space right because you you're really not just talking about API fidelity Although that is a very very critical topic You're also talking about virtual machine images You're dealing with some of the challenges around data gravity, right? So as a particular Company organization continues to consume services from a from a specific provider They're putting more and more data in that provider and one of the bigger challenges actually how do you deal with all of those bits being moved? So to me it's a little bit more of a broader topic than simply you know API eyes And and I would say that right now the industry is still trying to figure out the API Answer some answers are you know AWS and cloud stack does support that as well I think that's obviously the leader in the market right now most organizations are Looking at Amazon as the initial way to join you know, we're start using the cloud But we're still really early on and as you consume more and more services It actually gets harder and harder to migrate to like environments. So it's gonna be interesting to see how this evolves Okay Alan what do you have to say on the topic? Also, I agree with you the gentleman that's spoken about the API interfaces So we do have somewhat of a de facto standard there from from AWS to build upon So let me add one more point. I think it's also important that you have a standard operating environment That's available both in in the public space across the public clouds in private space So particularly as you start talking about enterprises They're building use of clouds in their private in their private enterprises as well as Developing the use of public clouds. It's very important that they can have a standard operating environment Which includes a standard operating system in both environments Okay Anything anything to add or to talk about with that Greg or chip any concerns When you're thinking about You know a standard operating system or you know, I know a lot of people are much less concerned Maybe with the operating system level now than being able to replicate the same Toolset with puppet or something like that rather than the operating system itself any thoughts on that tons I mean You know every organization is going to have to as a matter of course figure out how to standardize their environment In a way that maybe they've never had to before or haven't had to in the same way Having an image or images that are identical across environments is obviously critical Understanding the provenance of how those environments were created Having tools that can guarantee that those environments are as similar to one another as is possible, you know, ideally identical These are all their prerequisites for doing anything the cloud way And fortunately, I think that you know in the open-source world. There's so many good choices That it really is a matter of taste, you know If you look at you know the dominance of a boon to in in Amazon for instance the number if you ever go through and look at How many you know images are out there? There's just a ton of a boon to images Because people are comfortable with it You know and I think that The easy availability of Linux and the ease to standardize on it is making it a great choice for that Okay Anything to add to that chip? Yeah, well, I completely agree that you know Linux tends to be the the predominant workload for the cloud Obviously, you know Windows and continues to be a big player in a lot of companies And so there's gonna there's gonna still be a need for for those companies to transition applications to a different Different environment and hopefully you know take advantage of at least some of the Cost savings you can get through scale the the other interesting thing to consider is is the past Landscape right so so we've we've really been talking about virtual machines and in the context of infrastructure as a service What I find to be really intriguing right now is how the kind of line of business developers and large companies are They're beginning their shift away from just simply getting VMs as quick as they can to focusing on the applications themselves No, I mean, I'm not here to represent a past project or anything But I believe that the application is always the the reason why you use infrastructure And we're gonna see some of the exact same discussions occur at that that application container level that right now We're really focused on at the VM container level and it's also possible that it might simplify You know some of the infrastructure in the service debates as More applications are designed to run it up has and and that has itself could just simply select one OS Okay Let's shift gears a little bit and talk about one of the things that I You know we talked about last year. I think at Linux con and cloud open Was the open cloud and and everybody has a for many people have slightly different Opinions of what open really is for example Red Hat, I think it was Maybe Richard who's supposed to be joining had coined a you know a seven layer Thing for openness whereas other players say well, we have an open API and that makes us open It doesn't matter if the source is open so if you're you know when you're talking about open what makes a cloud open and If all of the tools are open source does that guarantee that it's open? What you know what makes open cloud for you? You want to start Greg? Sure, what makes open cloud for me is a cloud that I have in my own hot little hands that's open And that's almost the extent of it There's this sort of whole overarching open cloud idea and And you know, I think the the conversation Sort of gets hung up You know because public clouds by their nature are sort of not open their service providers It's a different thing what you want is the opportunity to be able to build an Environment for yourself that you have control of and you want to be able to make sure that you can get workloads Into it easily from whatever public cloud provider you've chosen and if you want to you know burst out to the public cloud when you You know your your private cloud is full You want to have that option as well And for me, that's you know, pretty much as far as it goes, right? And obviously the enablers before that are Questions around API questions about images and having open images that can be widely shared. That's important I think increasingly having open standards around Software defined networking is going to be gigantic, right? You know from the people I see who are putting together clouds Almost without exception the hardest part to get right is the networking piece. It's the it's the piece that people are least likely to Understand and get right immediately and so I think Open protocols open standards around networking are going to be hugely helpful All right, so by what you were saying there if if vmware for examples vCloud had a Convenient way to move workloads back and forth to other providers Open if you have control over it even though you don't have a source Well, all the so all of the open source caveats apply right when I say I have a cloud You know I have been an open source so long that when I say that I mean that I have the source code to the cloud Right, so I have my own cloud I have control over the bits and the source code and can hack it up and innovate with it and make changes as necessary But that's all private cloud right and with the public cloud the uncomfortable truth is that you are never going to know Precisely what's running there? Because they're they're not your you know, it's not your machine. You can't touch the bits, right? So, you know and I'm happy for good faith efforts that people are you know sharing that source code But you know that the open cloud I care most about is the one I can put my hands on Okay, who wants to go next chip or Alan? I Could just add to I'll go ahead. I can just add to that. So I so I agree with what Greg is saying But if you think about it open source We're all running under the app at least the cloud stack an open stack or running the Apache license Which means somebody can take that open source and implement it in a way that you know It's proprietary because they can just copy the stuff and do whatever so Which goes back to Greg comment of feeling comfortable with having those those bits and being able to set up Your stack the way you want it Which is great for the private clouds, but you're right in the public clouds But the actual case really should be that as a from a consumer or customers perspective The applications should be built in such a way that it's somewhat agnostic to whether it's open source or not Okay Chip do you have anything to add to that or I? Think that both both points are very good There's a provider perspective and whether you're talking about an internal IT department or even just a dev team that set up a very small environment All the way up to you know large-scale clouds They there are operator challenges many of those challenges are resolved through the use of open source And and open standards when we think about southbound APIs You know SDN was was was mentioned clearly. There's a lot of activity in that space But very little industry consensus. I would say maybe some is forming around open flow as a sub component so operators have a lot of challenges number one and The the other perspective is also very important is that user perspective? So you know the actual end user who's deploying the VMs who's who's trying to Probably do a couple of things right first there They're trying to quickly get access to the infrastructure that they need Regardless of the container style that they're working with And then two and we still really have not solved this as an industry Enabled you know easy and in true portability Between maybe regions of a particularly large provider local environments As well as just alternate alternate public providers, so To the end user the the bits that make up the service should mean very little But to the providers themselves it should mean a ton And everybody kind of meets at the at the middle with the APIs that are made available Okay So I agree with his comments and my comment was coming from you know the the user's perspective but on the provider's perspective I think open source makes a huge and The the evidence of that is the momentum that we have with open source itself, right? People are finding so we could list all the advantages open source and those apply in the cloud space, and that's why cloud Particularly open source cloud is going to win Okay, that's one to that Yeah, is anybody against open cloud on the platform on the panel if you want to make an argument Anybody now, okay good So let's talk a little bit about Shift gears again, and let's talk a little bit about hypervisors Each platform has support for different hypervisors And have different approaches to how they support them Does it matter? which hypervisors you support and You know if so going into the future for the open cloud which hypervisor or hypervisors Do you think are going to really matter? You know five years from now Once to start with that I'm happy to take that one to start. I'm sure everybody has an opinion on it You know I'll take a long view first My long view is that hypervisors. I I mean effectively that technology is rapidly being commoditized The realities that if you look at the way VMware Is shifting some of their their commercial focus they realize that too right so We should reach a point very I would say very similar to just simply Linux where knowing that you can get a free well-maintained well-supported operating system or hypervisor is going to be Easy for everyone to do there's going to be very little value that's added in a particular hypervisor now That's a long-range view right The the path to get there is going to take us you know down some uncharted roads and In order to help bring Enterprises providers and end users along this this journey that the industry is taking Supporting multiple hypervisors within the same cloud environment is actually important right? We're at a minimum providing an operator with the choices that are necessary Or the choice that they might they might make right they have operational considerations of cost considerations There there is still some feature difference difference between the hypervisors right now Whether you're talking about specific OS's that are supported or more advanced features now, you know, that's all being abstracted to a certain extent, but as The as we mature I do think that we're going to get to a point where where the hypervisor Battle should really just be kind of limited to maybe one or two freely available options All right Alan you have thoughts on that. I mean You know working with Susie you guys have historically been a big supporter of Zen Also KVM You know, they have the whole theory of the perfect guest. Where do you stand on that? Yeah, I was gonna say so Susie continues to contribute heavily to Zen And by the way we applaud the effort The words in is now set up the new advisory council within the Linux Foundation. I think that's great and the reality is as Chip pointed out the reality is in the short term Particularly in enterprise environments, they've got multiple hypervisors and I guess I would say our challenge is is that We you know Well, they've picked those hypervisors because of the different workloads that they're trying to entertain and based on The characteristics of the hypervisors. They've picked those for best performance or whatever, you know The requirements are our challenge is is really We should be hypervisor agnostic right cloud should be able to perform on whatever hypervisor those those Consumers pick and in the public environment And from a customer perspective it should be you know agnostic Okay I'll challenge that a little bit You know working with one of the projects there is you know always an overhead with supporting You know each hypervisor and you you run into you know Maybe one hypervisor isn't as well loved as the other ones in terms of support Do you think cloud providers should maybe be or it's not okay for them to be opinionated and say you know We're gonna pick these two or something like that So the public cloud providers. Yeah, they're gonna pick one right and they're gonna focus their business on one Based on the customer or set that they have and and by choosing one They'll definitely pick a customer set But I'm just saying from from our open-source project perspective. I think we need to be looking and try to make our Applications and services as agnostic to hypervisors as we can Okay Greg do you have anything to add on this or what are your thoughts? You know, I I think the world of the open-source hypervisor is already Largely agnostic and a matter of taste And I think that you know KBM and Zen are the winners there and I think that they will continue to be Fighting it out for one two for the foreseeable future in the open-source world And those are going to be the basis of every open-source cloud that's built You know vmware is in an interesting position where they want to Continue to prove that there is value in the hypervisor So that they can lock in people who've already chosen that hypervisor, right? One of the interesting things about cloud and one of the things that that you know, we leverage eucalyptus for Is that in our ability to support both the open hypervisors? and vmware We give cloud users an option to abstract that away while they figure out what their future path is and You know the the the the world of cloud makes Workload management different and I don't think organizations understand those differences yet But as they start getting standing up their own clouds scale figuring out how self-service provisioning works in this new world Figuring out, you know workload capacity questions In this new world. I think they're going to naturally lean towards the kind of hypervisor That's all you can eat, right? And I think that's going to be to the ongoing detriment of folks like vmware You know and I think that you know one thing one important thing for us is that KVM and Zen are both first-class citizens in the kernel at this point And you know, we're based off of a rail platform right now. It's what we standardized on and so when Zen Receives that same sort of first-class support, you know, we will sort of inherit that and I think that's going to be the case for a lot of folks Okay, I Think anything else to add on that chip or Allen anything you want to add or I'm not seeing any good All right, so this is an IRC chip. You can actually nod your head and I don't know Okay, so let's let's try another question here I think there's a little less heat behind this one as there was last year We've already talked about opening the APIs, but I don't think we've specifically addressed, you know How crucial are is AWS API compatibility? I think that's you know, that was a big topic last year You know people were arguing that everybody had you know, let's just declare AWS API You know the HTTP of cloud and go from there and of course there were folks in Certain camps that were really offended by that and they didn't like Amazon having to control over that so how how important is AWS API compatibility in reality for your project and then you know Talk a little bit about that how you see that going in the future I'm gonna go ahead and pick on Greg first since his project is obviously opinionated on this topic right You know opinionated I think there's room for a lot of APIs Right, but I think it's absolutely crucial that the AWS API be well served with a free alternative and that is why I'm at Eucalyptus as AWS continues to move forward quickly with the number of services they offer Their APIs are going to continue to accelerate and as is the usage of those APIs, right now There's going to be I think there is a strong independent movement to Use services in a way that are API agnostic right a lot of the services that AWS provides You you can do in other ways and I think that for Users who want to be truly cloud agnostic They will invest the time and energy to figure out how to do things like auto scaling In a way that is independent of an API however, there are a large number of users in AWS who are already making those choices and You know at Eucalyptus, that's you know, it's it's been our strategic goal from the very beginning to provide that alternative to AWS users And in a way it makes our job easier because we don't have to try to innovate around the API itself We simply see the services that people most need next and go implement them, right? So that's why in Eucalyptus 33 which is coming up here soon We've got auto scaling groups and cloud watch and we've got improved tagging and we've got elastic load balancing and all those Sort of next generation features that AWS users are growing accustomed to and we want to make the switching costs to private cloud Back and forth in fact as minimal as we possibly can So for that set of users, I think it's extremely important I would say crucial but that's not going to be all of the users of the cloud and certainly competitors to AWS Ken and should have different views Okay Alan you want to go next? Sure, so, you know AWS EC2 we're talking the fact of the standards here, right? And so having having that support It does make it a lot easier for system administrators to do their work in different environments But we're already seeing Brokery solutions come out that are, you know, with the name to make workloads Be able to move workloads between different interfaces so being, you know The solutions are happening around us I think the second part of it is is we need to how cloud is going to look in five years I think it's going to be very different than it is today and So I'm very much more focused on the future and making sure we can get there and a good example of that is Greg brought up earlier. We've got SDN coming right. We've got to make sure the interfaces work with these new services that are coming online Okay Chip do you have anything to add or? Yeah, absolutely. So Amazon API Support today is absolutely required of all of our projects, right? Defective standard no question there Again kind of looking at a looking at the long range There are some problems with it being a defective standard right now. The problem is that Amazon is is effectively owning that API on their own, right? Now they do a good job of trying to keep it consistent as best they can obviously they've built an ecosystem around it and You know for the same reason why we should all be supporting it They're gonna work on maintaining some level of stability there I think the real the real problem comes in as new services are developed, right? So not necessarily how do you spin up a virtual machine, but More more contextually aware services Amazon being the only If they're the defective standard and then their engineering team is the only team working on that API You they really are ending up leading the industry quite a bit now How long will they be able to do that at what point will will they see you know reasonably skilled competitor that that catches up with them That uses a different API and then you know maybe in 10 years We're talking about a completely different de facto API. I'm not make necessarily making a prediction about Amazon's success or failure You know Jeff obviously obviously knows how to grow a business But but there's some challenges around you know them kind of a closed model there now The other way the way the other way that I look at these API's is that really they're just a manifestation of the basic They should be a manifestation of the basic abstractions that that are being orchestrated underneath And so you don't necessarily need a lot of innovation in the API itself as much as New services that you're going to offer that Amazon might not be offering right so that that's where there'll be a difference And then how those services are actually exposed You know that's not really going to be a novel thing and frankly, you know API's If we're all kind of watching the press API's aren't patentable You know realistically anybody can use API's The questions where do they get to find and how do they evolve right? Yeah crossing fingers, absolutely So kind of a mixed message there right it's a no-brainer right now. It's also the right long-term bet At least in the in the foreseeable future But we should all make sure that we're able to De-couple our services from a specific API implementation and orchestrate based on you know a second or a third or a fourth API Give our users options give the operator's options And we'll see where we go Okay so You know in the long term if if the open cloud Industry doesn't want to see Amazon and control Is it just going to be a? You know 20 different API's or however many you know open clouds there are or you know Is there any way that we can ever have a standard an open standard between the different cloud players that isn't run by Amazon? Well, I mean there are open standards, right? But but then you can kind of argue the level of openness depending on what organization they came from I guess my point was less about the Standard being open and more focused on the you know our projects and how we implement API's so and Also, how do we support the the consumers of the services? So making sure for example that cloud stack support within J clouds or fog Is operable is is critical right because that that really gives a local library that abstracts a lot of the different challenges So I would say that that really being able to support multiple options is the best bet for any project right now There are certainly bodies as well as projects that would love to have their API be kind of canonical as the standard, right? And there's there's going to continue to be a lot of I would say industry argument in this space for at least the next decade Okay Now and I think you have some experience with standards any thoughts So I pretty much agree with his statements there. I mean we've seen a lot of good progress and in some of the standards bodies and But like he said, I think like I said clouds gonna look different in five years So we're still gonna have battles on what those interfaces should look like as we go forward Okay, Greg anything to add on that or yeah, I think a good point that ship made obliquely And part of the eucalyptus focus. It's easy to get lost in an API APIs are massive some corners of those API's are exercised Rigorously and some of them languish with only a handful of users And what tends to represent that is the tool chains that are built up around those API's So when he talks about fog and J clouds Those are those are the standards to which we hold ourselves When we compare our compatibility to AWS At the API level You know and and the nice thing about that is that you know For us, it's a very close line to getting fog working for eucalyptus Because there are only a very small handful of differences where we're different from the AWS API and we can work to minimize those differences And so that gives us a faster time to market to get those tools working But at the same time the existence of those tools as standardized tools on top of the API also allow for common places where Service-level abstraction and interoperability can legitimately happen, right? I think that's one of the the huge values of You know fog for instance is sort of already ubiquitous. I mean it's behind both puppet and chef's cloud provisioner pieces You know so I think that tool approach is going to be key going forward and The more that we can get together and sort of pick the tools that we think are best The more opportunity we have potentially to abstract away the API's underneath those tools Okay I'm gonna cut in with sort of a commercial break for a second and remind folks who have joined a little bit late this is a kind of a preview of the Open cloud panel We're gonna be doing in New York at the end user summit in a couple of weeks If you have questions, you'd like to see us address right now We're working off a list of questions that we prepared before the panel But if you have a question for somebody in the panel or for the whole panel Feel free to add it in the comments and we will try to get to that before our time is up We still have about 20 minutes left So we're gonna move on to another question, but again if you have anything that you would like to ask Please go ahead and add it in the comments Let's talk a little bit about you know the reality I was at DevOps days last week and Talking to a few folks talking to Donnie from Redmump and he mentioned, you know There's a lot of he sees a lot of folks doing DevOps He sees a lot of folks doing cloud, but he does not see those two together a whole lot So there are a lot of people doing cloud is sort of a virtualization to And you know there are a lot of folks that have legacy workloads that are just not cloudy So let's talk a little bit about how to deal with that how your solution deals with that And where we're going to be in a couple of years I'm going to go ahead and start off if it's okay with Alan on this one since you know Obviously Susa has a long history with customers running what we would define as legacy workloads and customers who are looking ahead to You know what what they want to run in five years So a lot of a lot of the work that From putting my Susa how and a lot of the work that we're doing around that area has to do at the tool sets Getting them ready to move into those into the cloud environments so Right there they're using and what I would call an enterprise level OS one that's been certified tested and then secondly the They need the management tools. They need the patch tools So that they can take care of their new environment. You've got to have image creation tools Which we talked a little bit about earlier tools that give them that ability to migrate and We found that's pretty key in Well, and those tools have to fit in with their their business policies and business processes We found that's been a big key Let's go ahead and chip. What do you have to say on this? I know that you have some experience in this in this area Yeah, so so from the the CloudSec projects perspective we fundamentally believe in to workload story, right? There are going to be like what we call legacy applications For 50 years and I know that you know in some circles of the of the cloud industry there are plenty of folks who would say that that's heresy, right? But there are absolutely benefits for private clouds To be able to support a more traditional environment that needs to ensure Virtual machine stability and availability now on the other side of things. There's the there's the new architectures, right? There's the design for failure scale out The types of apps that you would actually enjoy unleashing the Netflix Simeon army on right and Those two workloads styles are are going to be with us for a long time in the private cloud space We need to as projects support them in the provider space I Also, believe that the providers are going to continue to offer two variants of you know, quote cloud services, right? One of them being Really much closer to AWS style and the other being that that legacy style And we're going to use different technologies for those for those different types of workloads underneath the the cloud orchestration software We're going to have different SLAs we're going to need to be able to do things like tearing tearing storage appropriately Automatically adding availability attributes to an environment Using potentially traditional network isolation technologies if there are reasons for that So You know, there was a little long-winded but short version is you know We believe that both workloads are are worthy of getting some of the benefits of full automation And we're working to ensure the cloud stacks of course both Okay And Greg do you have anything? I'm sure that Eucalyptus has kind of a maybe a different take on this given your relationship with the Amazon Not not as different as you might think right part of the in a way We're a bridge to AWS because there are plenty of people who would love to enter the new world Of you know the DevOps way But they are shackled to legacy applications and those legacy applications aren't going away anytime soon And it's much more likely For that class of user to be able to get a legacy application running in some Local cloud that feels a lot like virtualization management as opposed to pushing stuff into the actual cloud Where the rules really are different right one of one of the potential advantages of private cloud is that to some degree You get the best of both worlds So we do think that legacy workloads are going to continue to be important they tend to have different performance characteristics You know we tend to need to be able to customize the configuration of a cloud we put on a customer site To help deal with the different performance characteristics of legacy applications You know legacy application users love our EBS implementation because it means they don't have to figure out how to do instant store and you know Sort of cloudy volume management. They can just shove it all in and you know use a gigantic EBS volume and run that That legacy workload just as plain old virtualized You know and there are challenges to doing that right when you don't design an application for failure Which is the cloudy way it means that you have to guarantee uptime and you have to you know fight to make sure that You have basically you have all of the same Problems you have just dealing with any virtualization solution But at least you get your opportunity to dip your toe in You get an opportunity to learn how cloud is supposed to work And if you have applications that may need to talk to those legacy applications, but not the legacy applications themselves You have the opportunity to sort of develop those and and sort of chart a path towards your future Which is what we see a lot of our customers doing Okay Next question. I want to we've touched on this a little bit, but I want to get a little bit deeper into it Um The importance of sdn everybody has kind of touched on that. I think at one point or another talked about the importance of sdn And also it's in maturity. So I want to ask, you know Where do you see that going in the next few years? What solution or projects are going to be dominant in that area? What problems are yet to be solved just kind of interested in your take on sdn and where you're at with your project and where it's going Um We've uh Kind of wrapped around the panel. I'll start with alan again. If you have anything on the topic alan well, so in regards to sdn Open stack has the quantum module, right? And there's a ton of momentum with that quantum is now an integrated project within open stack With the gracefully release that went out in april Um second part, um, you'll notice uh the Open daylight project has now been launched as a work group of part of the linux foundation um A lot of huge momentum there. I'm I'm very excited and hopeful for the future with that group to on their success So you'll see a lot of synergy. I think between their efforts and our our cloud efforts particularly with plug-ins and and connections into uh into the cloud stacks Okay Chip, what are you, uh, what are your thoughts on sdn and where it's going? Yeah, so Right now The the solutions that are on the market that that are kind of tying themselves to the sdm acronym um Are largely focused on network isolation technologies, right? so Whether whether you're and and controlling that network isolation um Now, you know, open flow being the being simply a wire protocol that That a lot of vendors and hardware hardware vendors as well software companies are are working to use to to take that control plane You know out of the actual forwarding plane It you know, it has a lot of potential I think that I also think that the industry is very Early on with figuring out what software to find networking really needs to go accomplish Scale is a problem that needs to be dealt with But also there's the question of network services and network service composition Which is really a much more interesting area than simply l2 isolation I think open daylight is a it certainly has a lot of vendors involved I'm excited to see where that goes I'm not very intimately involved with it. So I'm I'm not going to you know pass judgment at this point as to its direction As much as it's good to see industry cooperation there and It's also important to me that it that it is looking at the problem much more holistically than just simply You know the switching fabric Questions that that you know kind of the open flow world is focused on Cloud stack itself. I mean just I'll hit that briefly right through cloud stack itself Supports multiple isolation types like I referred to You know, we work with misira. We've got integrations coming in from big switch and mitokura We do traditional vlan isolation You know as well as the the more kind of aws style You know security groups with effectively, you know l3 Isolation between the instances But we also think about services like load balancing and firewalling vpn terminations, etc We think of those services as being just as important as As how you actually get you know switching into the into the instances And so we've got similar plugins there where we you know have abstracted the firewalling constructs and the load balancing constructs And then allow our provider's choice in the physical gear Or the virtual gear that they use to to manage those network services I do see that there's there's going to be a long A very rapid progression away from physical hardware doing a lot of the network services, right? The the cable industry is an example A good friend of mine's chief architect that's one of the major networking companies for cable and mso Um and and we spent some time discussing how network services Running within a infrastructure as a service cloud kind of the convergence of our our two jobs Um is a really hot topic and in those providers Um And I think that's going to continue to accelerate as more and more virtual appliances get deployed As those virtual appliances become more aware of the context within which they're running The the virtual data center for lack of a better term that they're they're supporting As well as the interconnectivity between the various app environments that the the users have Okay So, you know, we've had a pretty good conversation so far. We're down to about nine minutes I answered a lot of general questions about cloud and everything but we haven't had a really good argument yet. So Maybe we can spark one a little bit with uh, let's talk a little bit about licensing, you know Um I'd like for folks to spend a couple minutes on the licensing choice They've made for their project and the community style And how that fits and doesn't even matter in the larger pictures that just you know for that project or is it going to have Um, is it going to matter in the long term picture? Um Now I know a couple folks on the panel are you know, kind of unified on the apache license Um, but uh, hopefully there's enough divergence for at least a little conversation here Who would like to go first on that one? All right, it looks like everybody else is dodging it, right? So, um, open source licensing is uh, is obviously It's very complicated when you think about all the different license flavors that are out there if you boil it down to What I would think is the main difference between the copy lefts Um, you know strong copy left weed copy left and and then the more commercially friendly um licenses Um, we're we're working in a space where companies are involved, right? These are vendors. These are service providers. These are enterprises The the license that we use for our projects should be friendly to those organizations so that they have the the right And the ability to take the code run with it and do whatever they want Working is good, you know in in in a lot of ways Now it also presents some challenges And so, you know as the the communities grow You do need to do a very good job of community management to bring people back together So while you have a very friendly license for for To to make the lawyers happy, you need to double down on your efforts on community management Okay Who would like to go next there? I'll go next So So I agree with chip. I mean a lot of it and and open stack has picked the Apache license And a big part of it is ensuring that We're compatible with the tool sets and and Applications and so forth that are being used in conjunction with open stack. So it's Just adding what he you know was mentioned earlier. It's it's not just about The project itself but making sure we're compatible with all the tool sets that go around with it and that's a big A big consideration And as you also mentioned a part of that it has to do with the Principles of the project itself and in the degrees of openness and Um Those those policies within the different projects that we're talking about here are very similar some of them very slightly but The biggest part is to ensure that we keep the openness and transparency around the projects so that The community can contribute and participate And feel confident that Their contributions will remain open Okay, um greg anything to add or thoughts on what's been said so far uh People who adhere to the Apache license hate freedom Um trolling heart no, uh, it's you know, it's largely a question of business model, right? And I think one of the most The interesting thing to look at in this space Is the history of cloud.com and then it's purchased by citrix, uh, and the change the cloud stack made When you are a smaller company as cloud.com was and you're betting on open source software It's uh much more difficult to justify being a patchy licensed Uh at the very beginning, right? So, uh, I think that's why cloud.com was originally gpl And then when they were purchased by citrix and the decision was made to Uh move into, uh the Apache world I think that connected directly to a different strategy With a larger industry player and needing to play with other larger industry players, right Which is a perfect rationale for citrix making that jump from gpl to a patchy with cloud stack Uh at eucalyptus, we are uh, you know, we have a very clear place in the market And the gpl, uh continues to be More of a net good for us than a net bad, but there are challenges, right? We have You know, we have a number of customers who find it more difficult to contribute code to the core And they we have to be more committed to them And they have to be more committed to us for them to go through the additional headaches of contributing to a gpl project And many of the tools that sit on top of eucalyptus are a patchy licensed for that very reason Uh You know, but it's it's courses for horses. Uh, I think And uh, you know right now the gpl. I think is best for us Okay Um, so we are almost out of time, but I want to give everybody a chance to You know include a couple final thoughts and uh Go from there. So greg do you have anything you want to Close with? Uh, raw raw eucalyptus 3 3 is going to be awesome. It's got lots of uh more aws compatible features dig in Uh, go to eucalyptus eucalyptus.com slash fast start and take it for a spin And when is is that out now or is that soon? No, it's uh, it's going to be sometime in late may or early june Is our best guess at this point put, you know software. So, right? Yeah We are in fact familiar with that. Yeah Uh, speaking of which, uh, we'll go to chip any last thoughts or uh comments Yeah, well since we're taking an opportunity to push the projects. I'll I'll say um reminder for the world the cloud site collaboration conference for north americas coming up in in late june and Also look for announcements about a european conference as well And come join us at cloud stack dot apache.org Okay, thank you chip and alan last word Last word. I got the last word. That's pretty good. So open stack just had its summit. Uh, we just uh Completed that two weeks ago up in portland had over 2600 people attend Uh and participate in the conference huge success huge momentum We just released grizzly, um our seventh release and uh, go check it out. It's awesome stuff And thanks for uh inviting us all today To this event. Thanks joe Okay, uh We'll close. I want to thank everybody for joining greg chip and alan Uh, thanks everybody who you know signed up. This was the first I think linux foundation Google hangout. So we probably had a few glitches, but uh, if you have comments or thoughts leave them in the chat or the comments This should be up as a recording Um Probably in the next day or so. I think they're going to go ahead and look and see if they need to edit anything Or trim the beginning or end We'll be rehashing this with some other folks on the uh end user summit in new york in a couple weeks And uh, we hope that uh, if you're there you will join us Thanks a lot for listening and have a good day. Thanks everyone