 This is Dave Vellante, and this is Silicon Angles live production of the VTUG Winter Warmer. We're here at Gillette Stadium, home of the New England Patriots. Ken Wee is here, along with Cody Bunch. These gentlemen are with Rackspace. They can geek out deeply if you like. You can tweet me questions if you want. We can talk about industry trends, but gentlemen, welcome to theCUBE. Thanks Dave. So you guys were doing a keynote this morning. I was bopping in and out. They call them keynotes, but they're really not keynotes. They start the day and they separate you out. So you had to sort of run around. I got my morning workout in, but Ken, why don't we start with you? Maybe you can summarize what you guys talked about in the keynote and what the reaction was from the audience. Sure, I think the focus of our keynote is basically to talk with current VMware administrators who are curious about what OpenStack is. They've heard a lot about it. They've heard things about it potentially being an alternative to VMware or a partner to VMware, but they're not sure what it is. So our keynote was really to say, here's what OpenStack is. And if you're a VMware admin, here's what you need to know about OpenStack to make that transition. To either using OpenStack instead or using OpenStack alongside of VMware. So we'll get into some of that, but I mean, there's a perception out there. Certainly there was initially a perception within the community that, oh, here's VMware. They're going to come in and maybe throw a wrench in it and fork OpenStack. And VMware said, no, no, no, no. Here's the NYSERA code and software defined networking, which is kind of a no-brainer for them to do that, to try to get adoption up. Some of the core code, obviously, they're not going to give to OpenStack. So this is sort of an interesting dynamic. In your view, a question is in your view, are practitioners even aware of all the dynamics that are going on there? Is that just like inside baseball and politics that is just noise? Or is that a real concern in the community, the purity of OpenStack? Yeah, so Cody, you talked to our community a lot so you can probably share some of that. You want to take that one? Yeah. I don't want to touch that with a 10-foot pole. It's a mixed answer. Being that my work at Rackspace, I've touched on our partner program and there is a need for enterprise vendors or the non-pure kind of stuff into OpenStack to give it the more robust, the more enterprise grade type features. The flip side of that is, yes, there's some contention that comes in anytime you have a VMware or an EMC or some of the quote-unquote old guard sniffing around an open source project. Well, okay, but do you feel, well, let me ask you, Ken, is OpenStack ready for prime time? I mean, it's been written yes, it's been written no. What's the state of OpenStack? I'm sure you get that question a lot. Yeah, a lot. I would say OpenStack is ready for prime time. I would caveat that by saying, if you want something that runs out of the box completely and you don't have to do anything around it, OpenStack's probably not quite there yet. I would argue VMware's not quite there either. Who is there? So one of the things I often talk about with customers is differentiating between what we call OpenStack the project and then the products that are built using the OpenStack project code. So the project itself, it can be a bit raw doesn't necessarily have all the pieces today that you would want in a full deployment. But a lot of vendors like RackSpace we work for but also like Red Hat and even some extent VMware are starting to package things, take that raw project open source code and they are productizing it and wrapping other tools around it to make it more production ready. So that last point, one of the points you made about you'd argue maybe VMware's not ready for out of the box either and I don't want to make this about OpenStack versus VMware. We can maybe talk about that maybe not but my point is we're talking here about building so-called clouds and we can sort of all agree that the paradigm put forth by Amazon web services of cloud and self-service and pay as you go and granular services and automation, all that stuff that we generally think about as cloud is really the objective. I would totally agree that you can't just go buy off the shelf VMware and have that up and running. You can't even do that with Amazon. I mean I know from experience we run our crowd chat platform on Amazon and it took a couple months at least of a lapse time to get ready to go. So okay, so that's cool but there are differences, right? I mean in terms of maturity. I mean VMware's been around a long time. So the idea if I understand it is the community's going to bring those capabilities in. You've got people doing block storage, you've got people doing networking and so forth and so is that pace of contribution picking up? Are you getting that a virtuous cycle effect? Is that in place now or is there a lot longer to go? I don't know what you think of that. I see it, I see more and more contribution coming all the time. If you look through the keynote slides from the last several summits and the number of contributors from various areas and so on and the amount of contributions in terms of lines of code and quality, they've gone up for every OpenStack release so far. And then I look for IceHouse to be rather outstanding in that regard. Okay, so can you give us a little more detail on IceHouse, like what to expect? I mean at a high level. I wish I could. I don't have a great answer for you there, I'm sorry. I think one to keep an eye on. So if you look at where OpenStack was, it was very, and it still isn't just logic-scent developer-driven. Yeah, sure. A lot of momentum in the developer community, right? While also in terms of who is involved in contributing to OpenStack, we're a lot of times individual developers. What you're seeing more and more are kind of established companies who know about operationalizing a data center, like folks like Red Hat, IBM, Rackspace, who are now contributing more and more code. And I think what you're going to see as a result is people saying, hey, for the past 20 years, this is what we learned about how to operationalize in this infrastructure. Let's take that and put that into code and build that into OpenStack. So one of the things you want to look for in IceHouse is a project called TripleO, which is called OpenStack on OpenStack. That's where the TripleO comes from. And it's basically a set of features that allow you to more easily deploy and to manage the platform itself. So those types of contributions, you're seeing more and more from these established vendors who know about operations. Now, Cody, you wrote the cookbook right on OpenStack, the OpenStack Cloud cookbook. I was one of two authors. I sort of forced Kevin into the update, so. So what are the ingredients? Maybe we start there and... So a lot of patience, a little Linux's admin knowledge, and then build from there. Ingredients in what context, though? Like ingredients to make the book, ingredients to make an OpenStack. Yeah, the ingredients to make an OpenStack in the cloud. So OpenStack is a set of loosely coupled projects. And so you pick and choose what you want to deploy in your cloud or so. Or if you're deploying from an established, where Ken draws the line, OpenStack the project versus OpenStack the product. So certain vendors have an opinionated way of deploying OpenStack. You may take Keystone and deploy it in a certain way. You may take Nova and deploy it with a certain hypervisor underneath. VMware's VOVA is actually VMware's opinionated take on OpenStack, which uses ESXi and vSphere under the hood. Whereas the rack space approach uses either Ubuntu or CentOS and KVM under the hood. So I think the key there for me, and having read the book is a great book, by the way, if you want to learn OpenStack. It's the key to me there, it's the focus on automation, the idea. And this is applicable to not just kind of the operators, but the directors and managers. What we're trying to get across with OpenStack and cloud computing is that it's the only way to scale out IT these days is to automate the process. And I think his Cody's book kind of, that's the large part I focused. Let's automate deploying OpenStack and then bring automation into OpenStack itself in the way to deploy applications. So I want to talk about that, but so just a plug for the book. So it's the OpenStack cloud cookbook. Cloud computing cookbook, right? OpenStack cloud computing cookbook. And it's Cody Bunch at all. It's Cody Bunch and Kevin Jackson. Okay, now you talk about automation, Ken. I was in one of the sessions I was in this morning. The question from the practitioner was the vendor community is in here pushing automation, but I'm not sure I want to go there. I was somewhat surprised to hear that in this world of cloud and AWS and OpenStack, hyper scale where these organizations are highly automated, it seems like you can't scale your business without being automated. My question is, are the practitioners ready? Yeah, so my personal take on this, I think sometimes we don't do a good job in the vendor community of selling what automation is about, right? I think sometimes I talk to people and they think automation means you basically want to take away my job, right? And that's not what automation is. The way I think about automation is you're taking a repeated process and simplifying it and making it basically error free. And the reason for that is not because you want to replace jobs because every business says, you know what, I want to bet the farm on X number of projects, right? In the old days before it was automation because I needed, every step had to be done manually. I could only do 10 projects a year. And if four of them generated revenue, I had a great year. If I could automate that process to make it simple and faster, now I can do 50 projects in the same amount of time, using the same amount of resources. And the risk for each one of these little bets is much less. Right. Now if 10 of those projects succeed in making revenue, my percentage of success is lower but my total revenue intake is much greater for the same amount of expenditure. So that message is going to resonate great with certainly with a business audience. And I would think, you know, any CIO forward thinking or not, I would think the CFO would love that message. But it's surprising to me in my sense is it hasn't trickled down to the practitioner level. And maybe we're not doing a good enough job in the cube. Maybe the vendor community, as you said. But there still seems to be that resistance. But I feel like we're almost at this tipping point where it's inevitable because you're not going to be able to scale your business without that level of automation. Is that a fair assertion? That sounds about right. So we were at re-invent. I want to bring Amazon web services into the discussion because they're sort of the mental model now for the cloud that everybody's sort of chasing. And so, and they've been very forceful now in the last year or so with their marketing. We were at re-invent and Jerry Chen had just come back from Hong Kong. And we said, Jerry, give us the summarization of Hong Kong, how would you compare it to AWS? And I thought he had a great line. I wonder if you guys would come and he said, OpenStack, I feel like, is everything to everybody. All things to all people. Whereas Amazon, he said, is trying to be one thing to all people. Do you think that's a fair assertion? And what does that mean to you? That's a good job. I mean, that's the first time I'm hearing that. I'm going to need a second or two to process. Yeah, I mean, it was the first time I had heard it too. And I said, okay, well, all things to all people. That means, well, it's got a big community. Everybody's participating. That's a good thing. That means it's going to be applied, it means a huge TAM, it's going to be applied in a lot of places, it's going to solve a lot of problems, but it also means it's going to take longer to bake this cake. Whereas Amazon is like, okay, here's the nail, boom. So again, AWS is the hammer. I would caution you to say, I don't know of comparing AWS to the OpenStack project. It's the best comparison. Yeah, because it's apples and oranges. I think it's more appable to compare, let's say, AWS to the, for example, the Rackspace public cloud, because that is OpenStack, but it's the productization of the OpenStack project. So as a project, yes, we can be all things to all people, but when you productize, as Cody mentioned, that's a vendor's very opinionated view of what pieces or what elements of that project should be in the product itself. Then, in that sense, we are becoming one thing to all people. That, and I think that's very helpful, because my analysis was somewhat superficial. So now, thinking about the outcomes of the OpenStack products that are being developed, I think the vision is that these will be interoperable. Is that correct? If you follow some kind of cookbook, is that correct? These clouds will actually interoperate. There are several projects underway within the community to establish what that baseline is, to establish what running an OpenStack core is and what core represents. And then to, in order to say that you are running a public OpenStack, you have to meet certain compatibility requirements. So, and that is, because it is a community-driven set of projects, all of that is still being defined as we speak. Right, and I think one thing to keep in mind, too, is even as all these various OpenStack-based products come out, the code itself doesn't change. That's one of the agreements we have within the, all the member foundation is, I'm taking the OpenStack code, I'm not changing that code, unless I'm contributing it back, right? What's different is, a vendor may say, I'm going to use this deployment tool, right? Chef versus puppet. Or they may say, I'm going to use this monitoring tool or this billing tool to enhance what the core project can bring to the table. But at the end of the day, since the underlying code itself is the same, if I'm running a compute on one OpenStack cloud, that same compute resource should be able to run on another OpenStack cloud because the code for that is the same. So portions of the products and the clouds will be interoperable and potentially if the companies adhere very strictly to the definition, it'll be interoperable. Do you feel like that's critical for adoption and uptake and market penetration? That interoperable vision is met or is that not so important? I think it's hugely important. It's, especially when you talk about, like OpenStack as a project and as separate individual products, we need better words for that because it's a little tongue-twisty. And fighting a, not fighting, but living in the same world as an AWS who's already gigantic and has become the de facto standard, interoperability even between the two. So OpenStack has an AWS set of compatibility things. It's going to be essential for survival of either or, right? Because I would agree. Because, I mean, certainly that was VMware strategy for a while when they were trying to push the sort of homogeneity of VMware across private and public into the hybrids. But I think we can agree that strategy didn't work and part of that was it wasn't going to work anyway, but then OpenStack comes along and says, oh, that's a better approach. OpenSource is a much, much better approach. And then you have Amazon, which is, as you say, they're already, I don't know, three, four billion dollars in AWS revenue this year so they become the de facto standard and they move very fast. So, but the enterprise is looking for an alternative. Every market, even Ketchup has alternatives, right? So you need multiple choices. Choices without choice, there's no innovation. So it seems like that interoperability pieces is critical and expands the TAM. I want to ask you guys about the Randy Bias question. He came out and said, OpenStack community should adopt the AWS API. A lot of people said, yeah, that's good. He's off clap. Others said, well, wait a minute. Then it's basically Amazon driving the direction. I presume you guys fall into the latter camp. Is that fair or do you say, hey, let the community decide? There's, well, so being that OpenStack is a community driven project, if the community has enough interest in it, then it will come to be, right? There will be the code contributions to back that up. That's right. There's always going to be value in some level of compatibility between the two. If you don't have a basic set of provisioning APIs that are compatible or so across the two, you won't have the ability to experiment with workloads in the public cloud and migrate them in or vice versa, right? Or it makes the development of tooling that is multi-cloud aware much more complex. Yeah, so that's good. I would suspect then ultimately it's going to happen. My last question is leadership. My partner, John Furrier, said, OpenStack needs leadership. I mean, you got Rackspace, you got Dell, you got IBM now coming in in a big way, you got HP coming in, many, many, many others, VMware but I don't see VMware as being the leader. Is that fair, does there need to emerge a singular leader of OpenStack or are there enough big hefty cooks in the kitchen? Yeah, I don't know, I think we're early, so some of the things that OpenStack Foundation's doing in terms of how they run the project, it's fairly new even for the open source world. So I think with learning, one of the things I always talk about comparing OpenStack with Linux is, you know, one of the differences, Linux was basically running without any vendor involvement for 10 years, right? And then when it started gaining traction, that's when the vendors came in. Obviously, OpenStack's different as the vendors are in almost from the beginning. So we're kind of in some new territory in that sense. I think, I don't necessarily think we need a single leader. I think what we need are leaders who are good at managing collaboration or bringing about collaboration. I think what we need are leaders, on the vendor side we need people who can say, yeah, I'm in it, not only because I want to push my interests in my company, certainly they're free to do that and they should, but that we also want to help drive the adoption of OpenStack, the project. And I think we can do that and we can kind of get around some of these. Well, certainly you guys, you know, basically handing control to the back to the community was a huge move in the early stages. You got some tailwinds, right? I mean, IBM has a great track record in open source. HP, you know, a very open company in general. So there's a lot of real juice behind OpenStacks. We're huge fans, obviously, we were at the OpenStack Summit in Portland. We plan to be at Atlanta if we can get the invite. So if you've got any influence in the community, we'd appreciate that. But gentlemen, thanks very much, Cody and Ken, for coming on theCUBE and good luck with the project and we'll be watching. Okay, thank you very much. Thank you. Right there, everybody, we'll be right back. This is theCUBE. We're at the VTUG Winter Warmer Live from Gillette Stadium, we'll be right back.