 We have a fun format for you guys today. We'll let the guys introduce themselves and then we'll go through a few questions that we came up with. I'll start out by apologizing that my dear friend Jesse Prodman cannot make it today. He's not feeling well and he had a sick child that he had to rush home to as well. So he isn't here, but we have maybe even better a replacement. So Mark will introduce himself in a second. I also want to let you guys know after our kind of predetermined questions, we will take questions from you guys. So with that, why don't I start with Ken? Why don't you introduce yourself first? I'm Ken Hoi. I work in EMC's cloud solutions team and my focus is basically helping EMC build out their open stack solution strategy. Mark? Hey, I'm Mark Van Oppen and I work with Blue Box in Seattle and I'm tasked with helping our legacy customers move to Blue Box Cloud and get them successfully onboarded over the following months. Great. And I'm Amar Kapadia and hopefully if our branding has worked, you should all know I'm from Mirantes. I'm responsible for product marketing. And I'm Lisa Marine Amfi. I am with HP's cloud team. I run the open stack solutions marketing and I also run a lot of the community activities. I run the user group in the SF Bay area and I just wrote a book on open stack. You can download it for free from hppress.com. So lots of stuff. We all work very closely with open stack. Most of us work upstream, I would say, with open stack as well. So when Jesse and I got together, of course, at a bar in Seattle to figure out the format of this and the questions, of course they were also written on a, it wasn't a cocktail napkin. It was a coaster, but just as well, still official, coasters count. So we came up with five myths of open stack. You know, a little leeway here, but we figured we would use that as a starting point to start our conversation, we'll call it. And then maybe shoot some holes in these myths or maybe you guys will agree that they are myths. So I will start with the first one, which we thought would be nice and fun. The open stack is the same as VMware. This is myth number one. And maybe one of the questions is should open stack add more features to be more like VMware? So why don't we start with Marantis on that one? Okay, so let me first start with sort of the dramatic answer and then we can drill down. So the dramatic answer is VMware and open stack are obviously not the same. Everybody knows that. And the difference in one word is tickets, right? If you look at what's the main problem VMware was solving, it's workload deployment onto one machine, right? Consolidating it onto one machine. And if you look at open stack, if you had to boil it down to just one benefit, in my mind it's IT as a service, which ultimately leads to IT as a code. So going back to the ticket example, if you are in the VMware world, we find that most customers, their processes are still manual, still use tickets, takes anywhere from two to 26 weeks to get their machines. They're committed for four to five years. And on the other side, it's self-service. From my perspective and from the interactions with our customers, the perception is that open stack is a replacement for VMware and is mature and is comparable. It's something that is of the same mold. We have to educate our customers often that this is a community-backed technology. This is something that is not a product delivered by a single entity in a single company. It's coming from a variety of sources and it's being pushed and developed by thousands of contributors. And fundamentally that makes for a different experience and it's still in its infancy. Comparing it to a technology that's been in production at scale for years is an unfair comparison and not something that is really charitable to open stack. It's not a fair playing field. How many of you here are on the audience looking to deploy open stack in place of a VMware environment or looking into doing that? Only a few. I've actually been quite fond of saying since the beginning of this year that 2015 will be the year of failed open stack deployments. The folks who raised their hands, unfortunately a lot of the fault will be you. Because at the end of the day the problem we're trying to deploy open stack in place of VMware has nothing to do with the maturity level of open stack actually. It's basically taking something that was never designed to run workloads of VMware where it runs and say I'm going to shove that workload in anyway. It's kind of like taking, it would be like me taking my daughter's bike and saying I'm going to do NASCAR racing with it. Because that's what you're basically doing. Open stack is designed and it's always been designed to run AWS type workloads, what they call cloud native. It was never designed to run Oracle. It was never designed to be highly resilient. So by you trying to shove an application that needs high infrastructure resiliency in the open stack, you're basically setting yourself up to fail. And that's what I'm seeing today. I'm actually seeing a lot of failed deployments from enterprises that insist that they want to try to run, use open stack to just run all of their current VMware apps. I would also like to say though, I think 2015 will also be the year of successful open stack deployments. Some of those. Right? Come on, we have to go there. There are successful open stack deployments today. As we know, large, large production environment. But not running, not trying to replace VMware, all of VMware, right? That was the caveat you had. But you know, it is interesting. I just came out of a meeting with one of our large customers this morning who, they're a service provider and they are actually trying to do exactly that. Right? But they do need the resiliency and they do need the, you know, the high availability and all of those things. But I think the customers that we talked to, I think, just going to back up a little bit from the answers I heard, you know, cloud is not virtualization, right? And there's still a lot of customers that we talked to that kind of have this myth. So I think we need to start there when we talk to a lot of customers and educate customers cloud is not virtualization. It's a lot more than that. And I think when people want to start deploying applications and doing really interesting things, you know, taking more advantage of the hardware, taking more advantage of the environment that those applications are running in, you know, I think this is where OpenStack is really going to start kicking butt. So can I disagree with Ken? And it was supposed to be disagreeing, that's right. Yes, you can check it out. The follow-up point to what I said earlier, which was that these are two different technologies, means that they can actually work well together. So I think 2015 will also be an year where a lot of people cloudify their vSphere environment using OpenStack. So I think they'll work well, and if you have what EMC calls, you guys call it Generation 2.5 and 3 applications. If you have 2.5 Generation 2.5 applications which are not cloud-native, keep running it on vSphere and run, use OpenStack to cloudify it. And if you have Generation 3, feel free to use different hypervisors like KVM. That's the power of OpenStack, right? Choice. Yeah, so I actually would agree with you. It's just that when I talk to customers who want to go to OpenStack and say they want to replace VMware, they're not looking to run vSphere. They're looking to not pay licensing on EXX. They want to use KVM, and that's where the problem lies, right? So I used to be at Wackspace, and on the OpenStack team, I spent half my time talking to customers, talking to customers that I would be using OpenStack because I didn't want them to have a bad experience trying to use OpenStack and try to help them understand where there's a good fit and where there isn't a good fit. And would you consider the best path forward to be proper education of the customers on the use case and best fit for OpenStack in comparison? I mean... I think we need to educate customers better. I do think things are getting a little complicated because I also... What I've seen since the last few summits is as more enterprises get into OpenStack, there is, I think at this point, almost an unstoppable momentum to say whatever VMware has as features to run platform 2 or legacy apps, we're going to put it into KVM and OpenStack. And right now the momentum... I'm not sure there's any way to stop that momentum. Not even sure we want to stop the momentum. But once that gets going in a few years, this might all become... We may all be running everything we have on OpenStack anyway because we've built all those features. Yeah, and it's not just features people are looking for. They're looking for stability. They're looking for ease of use. And obviously, today things are a little bit complicated, but as more ease of use comes into OpenStack, I think that'll help a lot. Okay, so next question. My timer here, by the way, so if you guys let me know. Don't worry, they turn off the lights. Is that how it happens? Shut off your mic when I'm blinking. Okay, and apparently my necklace was too loud for one of those type of mics, but this has the added benefit of, you know, if I need to clonk anybody over my head. All right. So next myth, OpenStack is a product. Well, I don't know if we can call these myths, but or maybe we could also just talk about what the best approach to productizing OpenStack would be because there's a lot of vendors here. There's a lot of OpenStack distros. I'm sure you guys have one each in the audience and a couple on stage here. So why don't we start with... Actually, you want to take that one, Mark? Sure. So BlueBox took the approach of trying to make a digestible implementation of OpenStack and productize private cloud as a service. And in our model, the first thing we brought to market was hosted private cloud as a service. So your cloud truly single tendency on dedicated hardware in our data center. So we would manage and implement a running deployment of OpenStack and dedicate it to your environment all the way down to the hardware level. The only thing shared is the top of rack networking gear. You could have physical firewalls in front of it, and that whole model was in the pursuit of working with OpenStack, not on OpenStack. Don't force yourself to develop an expertise in something that's not your core business. So that was kind of the approach to helping people get the most value out of OpenStack without having to stray from what their core business is focused on, whatever application that may be. But I guess one of the questions is what actually defines a product, right? And I think there are many ways to define a product. I would say one of the ways, though, right, especially in the enterprise space, is product is something that someone provides support for. So if you look at the OpenStack project, who provides the support? No one single vendor. It's actually a group of people. But no one at the end of the day owns that support for that. If you're wanting OpenStack stable release in your environment, no one's responsible outside yourself for making sure that product works with every piece of gear that you have. So to productize something in one way to look at that is to someone a distribution vendor says, I'll take the OpenStack code, I'll package it up, test it, make sure it works with a list of gear, and we'll provide support for it all the way through. So in that sense, then OpenStack, the OpenStack project is not a product until a distribution vendor makes it into a product. And I'm also so fond of saying, if you're out there running OpenStack yourself, the code from stable release or from trunk, and then you're saying, well, I don't have a product because we're just running that from stable release, you have a product, you created the product, you've effectively become a software vendor for your own company. And you have a mad response for support and lifecycle of that product. I think I'll add to that. That's actually a great answer. So again, let's explore what's a product, right? In my mind, a product is something that comprehensively meets the requirements of the user. And we see three types of users, cloud architects, IT architects, whose main job is to deploy OpenStack, and that needs to be made really easy. There are, even though you can say OpenStack is unopinionated, you ultimately do have to make choices in terms of what hardware do I use, how do I configure my databases, how do I configure RabbitMQ, et cetera, et cetera, all the middleware. So ease of deployment for the cloud architect. For the cloud operator, it's how easy is it to manage at scale, right? Is it resilient? Does it really work? Can I make changes, updates? The previous session was an upgrade, right? Things of that sort. And for the developer, it's how easily can I bring my workloads onto OpenStack. And yesterday and the day before was a lot of discussion on sort of the app catalog. So I think those are the three things I completely agree with Ken. Large customers don't have to go to a product vendor. They can do it themselves and productize it along these three vectors and support themselves. Others may want to consider third-party vendors for distributions and support. Yeah, I wouldn't say just because it's not supported, it's not a product. There's lots of products out there. There's lots of products out there. There's lots of bad products. Lots of different types of products, but I think we get to ask that question a lot, too. Like, why would you do your own distro? Okay, so I just really quickly show of hands here. When's the last time you guys went to linux.org and downloaded your own version of Linux that you run, but you run Linux, right? So you wouldn't really necessarily do that with OpenStack.org. So I'm a little bit surprised that we get that question so much. But I think people just don't think about it like that. But I'm still waiting for someone to, you know, answer. So why would you go to linux.org and download that version? There are some people that might want to do that and they'd have good reasons for that, but our enterprise customers are generally not amongst them. Yeah, exactly. Early stages is very different, and that's where we were, and now we're not so early stages anymore. Release 11, right? So next myth or fact or something we're going to talk about. OpenStack is free. I just want to see a show of hands. Who thinks OpenStack is free? I don't think we're going to have to debate this one much, but Mark, take that anywhere you want. Okay. Again, the barrier to entry to deploying OpenStack is not the initial licensing fees, obviously. It is the staggering learning curve it takes to successfully operate it, whatever distribution you're using. And the whole concept of getting this free software and attempting to run it and expecting it not to have a ripple effect of long-term support needs or long-term issues is the myth I think we're really going for here. We're really trying to talk about. And what is the best way to gain value out of OpenStack without incurring a huge technical debt? What it takes to operate this platform? So, again, that goes back to the varying schools of thought. Do you go with a product that is a defined distro from a company that's willing to support it long-term, or do you go with somebody who will operate or run a vanilla version of OpenStack for you? And what is the best way to price and package or consume this product that is free in some form or not so free in another? Part of the problem is that you still need humans to run technology. So you're either going to pay for it. You're either going to pay to the humans who are upfront productizing things. So you're paying a vendor to do that, or you're paying your own people, however many engineering analysts need to actually productize OpenStack for you. But either way, you're paying somewhere along the way. It's a matter of is it CapEx or is it Apex? That's exactly what we're seeing. And this ties into the previous question, is OpenStack a product? If it were an open-source product, it would be free, but it's an open-source project. So if you choose to do it yourself, then, like Ken said, you need an engineering team that's working on OpenStack, pulling those bits in, configuring it, using your own CI CD pipeline, or you work with a vendor. So either way, you have to pay your engineers or a distribution. Okay, and we do find that our customers are willing, particularly, again, that the customer I was speaking with this morning who does want to move away from VMware for cost reasons, but is also very willing to pay for the stability and the high availability and then the six nines and things like that. So security, another thing people are pretty willing to pay for because the cost of not having it is pretty high. Okay, number four. Everyone should follow trunk. I can take it. There are three approaches here in terms of following the trunk, and I'm interpreting it as how close you are to trunk. There may be other ways to interpret the question. You could be at the bleeding edge, every update that comes out, you consume it. You could be at the other extreme where you're skipping releases and we have customers who are still on Grizzly and Havana and have skipped, you know, Icehouse and debating about Juno. And then you have people who are every six months, they stay in cadence with OpenStack releases and they upgrade and that's the distance they keep from the trunk. And it really depends on the business, right? If OpenStack is a business differentiator, so we are not talking about the agility and applications on top of OpenStack. If OpenStack fundamentally is a differentiator for your business, then by all means, stay at the bleeding edge and take the risk of, you know, issues that may come up and have the tooling processes and the people to consume it. If on the other hand, you are in a heavy compliance type business where certifying different versions of OpenStack is a big burden, then feel free to skip. But frankly, I think most people we are finding are somewhere in the middle. I agree with that almost entirely, but I think it also can be interpreted based on the use case. Are you running production workloads? Are you running dev tests? Are you using this as a sandbox environment in some form? And that would fundamentally impact how much risk you're OK with and the bleeding edge inherently has more risk. It just doesn't have the legs and the amount of testing behind it. So you could be running multiple instances of OpenStack and you could be upgrading one ahead of the other to watch that happen. But our customers sometimes have stayed on an older release because they're not comfortable taking the outage of doing the upgrade until it's been vetted for a few more months. Yeah, one thing I'd like to try to clear up too is I talk to a lot of people and they seem to get confused between trunk versus stable release. When they say trunk, they really mean stable release. So when OpenStack, when the project releases every six months, we're releasing essentially a snapshot of the code at a given time that we think is stable, so that's stable release. They're always iterating and fixing bugs and doing things like that. So what most distribution vendors do is when they roll out a distribution, it's based on that stable release. They're not typically then changing that release every day based on new code that's in trunk. So that's one thing. If you are a customer that wants to stay in trunk, try to keep up the trunk. So when I was at Rackspace, our public cloud always actually tried to be within two weeks of trunk. Most of the time, they didn't get there. Probably within a few months. But even to try to even get close to that, you would need to have a... I'll use the buzz word dev ops type of structure in place where you can do continuous integration that you have to be able to keep doing automated testing. To be honest, most enterprise customers I know don't have that in place. They typically take months just to certify a piece of firmware for their storage array. So for those customers, there's no possibility that they could stay close to trunk. I think we definitely have two types of customers and most of us have two different distros. A community version that does stay very close to trunk and there's definitely a community of people that appreciate that but our larger enterprise customers appreciate the more stability. They don't want the stability. They're okay even being a whole cycle behind is what we're finding for that one too. Okay, last question before we open it up to you guys. This isn't really a... This isn't really a myth. But Jesse, I mentioned we do this in a bar, right? Really late at night. So if I'm reading my cocktail napkin slash coaster correctly, the last thing was open stack works exclamation point. But I think actually we don't have to debate that. We know open stack works. So I suppose it depends on what we mean by that. We obviously, there's very large open stack production applications and huge websites like Walmart.com that are all running on open stack and PayPal and so many others that we've heard at this conference give wonderful testimonials. So we know open stack works. We know there's a lot of activity out there. So I guess if there's another side to that question, do you guys want to take a stab at it? Being happy to take it for swing. I think the core of that question is again going back to the amount of effort it takes to get started and the technical debt and the learning curve it takes to successfully run open stack at scale. It is inherently a little challenging. You are going to learn things. You are going to have to invest heavily in making it operate and making it work. And I work with a team of engineers who are constantly learning new sort of best practices of how to run our dozens of customers' private instances of open stack and constantly finding new use cases and new issues and if you were to do that running only one cloud and only one yourself just the pace of the education and sort of self understanding of how to operate your cloud would be slower. And it's just, I think the question really is about the learning curve it takes to successfully operate a project-based piece of software versus a product-based piece of software. So I can take a cut at it. So I have a friend and his definition of works is very simple. If it's tested, it works. If it has not been tested, it doesn't work. So the way I interpret this question is it goes back to the product point again is you have to make a certain set of choices on your hardware. What storage are you going to use? What networking strategy? What servers are you going to use? What middleware? How are you going to configure all that middleware with your databases? And that combination, has that been tested for HA, for security, for performance, for scale, functional testing, negative testing. And if the answer to all of these questions is yes, then it works. If the answer is no, then using my friend's definition, no. So, and that, again, the burden of testing either goes to the user if they use open source bits or to a distribution vendor like Mirantis if you choose to use a distribution. So I'll just use an analogy. The question is, is it open sector software that works? The analogy would be, if it just worked, it would be a Mac. If you're trying to run it off of a trunk, you're trying to do Ubuntu desktop, well, not, oh, Fedora desktop, sorry. If you're trying to run it off of a stable release, but mainly if you're trying to run it from a distribution vendor, it's probably like the Windows XP machine. A little bit of tuning, but mostly it works. Okay, so as promised, I think we have a few more minutes to open it up to you guys. If you can make your way to the one microphone in the middle, that would be great. If you can't, we will do our best to repeat the question that you asked so everyone can hear it. Question from my friend in the front row. Okay, so the question, so we've seen the numbers from eBay, Walmart, the numbers, but they have stated, reported that they've achieved positive ROI from implementing OpenStack. And I believe the question is, where is the tipping point to get there, if you're going to... And you want to know before you do that when you're going to achieve your ROI. Okay, Amar, you want to take that? Yeah, so that's actually a really good question. And whenever I hear the term super user, I cringe a little bit, because that means users are ruled out, are not included in that group, right? So actually, we have customers who are realizing benefits of OpenStack at as little as 15 nodes. And these nodes include OpenStack controllers. They include storage nodes and compute nodes. So at a very small scale, if your goal is to sort of get app developer agility and cost savings in terms of IT efforts, manual labor, manual work, you can get that at a very small scale. If you are trying to get cost savings over, say, AWS on a sustained basis, again. So the scale that are not... You don't have to be a super user is my point. I think there's some risk in answering this question without a clear understanding of how you calculate a return on investment. Because it's inappropriate to really say that there is a clear function or a clear equation for somebody to evaluate when they would gain a return or be able to appropriately decide whether or not they want to invest in OpenStack because the capital expense is one side, the operational expense is another. CapEx is something that's relatively straightforward to calculate. Operational expense is astonishingly complicated. So I mean, these large companies might be getting a return on investment. They might be seeing some additional utility by running OpenStack at scale and achieving what they have. But how they got to that conclusion is a staggering number of assumptions on how they calculated that return. So it would take an evaluation of exactly what kind of IT capabilities your individual company has and then decide how would you best consume this technology that is available and how would you best get the pieces of it that are most effective for your use case. Basically, my answer is I don't really have anything to point at as a tipping point or we don't have enough data to be able to say when you can make an educated guess because it is so wildly different depending on the organization. And how much of it is it going to be running in a public cloud versus a private cloud and are you going to be running a pass layer and building an application at the top and what does your whole cloud environment look like? So every cloud environment from what I can tell from the customers we've talked to is wildly different. It's tough to just blanket answer that question. I would say don't get discouraged if the scale is small, I think it's fine. You should consider OpenStack. I mean if the scale is three nodes then of course it doesn't make sense but if you are 15, 20 nodes feel free. I think it will work. Take the free version. Even at a small scale there are competing ways to consume the product. Do you go with a hosted private cloud or do you go with a distro on your own hardware? Do you take a path that is capital expense or operational expense, even at three nodes? Because it's a very different equation, a very different conversation and I mean obviously on one end of it is the Blue Box product where it's 100% operational expense in a least private tenant or private implementation and single tenant implementation in our data center but there's steps all the way along the way to buying a license and buying the hardware and taking space and building it and running it yourself. So I mean it's a hard slider to identify. Analysts are trying to answer this question too. Was it 451 that just produced a report and one of their takeaways was do you have an army of engineers who actually are qualified on OpenStack to build this stuff or are you going to have to go train people or get those people or hire those people? So there's a lot of different things that go into these costs but that is a good report if you want to read one. On that very topic. First of all I just want to say thank you for tackling something tough and thanks for agreeing not to agree. Appreciate that. If you had to describe clients that are most readily adopting OpenStack and if you had to give them sort of a personality type could you describe that for a second? Well when I was at Rackspace I think the overwhelming demographic of the people who adopted OpenStack were tended to be startups. People who are not afraid of... Again this is a couple of years ago people who weren't afraid to take on a new technology and had a lot of engineering people who were willing to kind of get under the hood a little bit if they need to. I think that's starting to change a little bit but I think like you pointed out there's still some engineering that... you need to still have folks who have a lot of technical know-how so I think the companies that have done well are the companies that have technical groups that aren't completely siloed that have a fairly... what I call T-shaped people basically there are people who know storage, networking and computer maybe a wide range of technical skills but maybe have one domain area where they are better than others you need a bunch of those T-shaped people they are successful as opposed to the guy who goes I know how to create a line and that's all I really know how to do I think those people don't do very well all those companies. In general I would agree that the typical consumer is somebody who is comfortable with some risk not enough risk to go it alone and try to build it entirely themselves like it may have been two or three years ago it's now... OpenStack is now becoming enough of a known quantity enough of a relied upon technology that okay this is something this is something that we can bring with a more comfortable level of risk but again the customers in the unifying trade is that they are okay with a project based product. So let me take a cut at that so the customers we are seeing most successful with OpenStack are willing to undergo what I in my mind I call a quadruple transformation so the transformation is organizational so American Express earlier presented today and Justin talked about the org at length so first of all there has to be willingness to put together a cross-functional org team cloud team, cross-functional cloud team that's going to work on this. The second transformation is apps going from 2.5 or non-cloud-native to cloud-native. The third one is willingness to adopt a DevOps type mindset going from water scrum fall to sort of true CI CD and the fourth is willingness to take risk on the infrastructure side from traditional IT to OpenStack which is open source and a cloud-based approach. Hi guys, so being that OpenStack has achieved a base level of maturity in the marketplace in your conversations with customers do you still find that there's some confusion in the market between whether OpenStack provides a control plane or a data plane and do you feel that they have any confusion about whether their choices impact capital expense, operational expense planning and budget in their projects? You sounded excited to answer this one. I can go. I think absolutely we see tremendous confusion in fact the first question that you teed up difference between virtualization and cloud people are confused I think that 6,500 people here get it but when we go outside the boundaries of this summit I think there's a lot of confusion in what is OpenStack why should I use it what benefit does it provide me how is it different than virtualization what is an overlay network etc. If I'd say that the 6,500 people here get it we've had a lot of confusion here and I've heard a lot of different definitions of things and we spent a lot of time defending OpenStack you think everyone's here at the conference they're all believers but I don't know that I would necessarily go that far yet but I think we will get there I think it's going to be in a few years the thing that we'd ask why are you not doing this I think we will get there the need for automation we call it the new style of IT but just really getting away from that more traditional way of computing your third point the CI CD stuff and the DevOps stuff that's massive the change of your business model the change of how you do your accounting it's just something that's going to have to happen you're not really going to have a choice but that'll happen it'll be a little painful when you're doing when you're making that transformation but companies will figure out how to do it and they'll get there and maybe companies who are brand new and they're going in here from the beginning have a little bit of an advantage but the large enterprise companies will get there and we see it working CERN has been on it for years and there's many examples out there of people who have sort of bit the bullet did it early and it's working I think I have I'm having a lot less of the open stack is not a hypervisor discussion I used to have a lot of that I don't have that so much anymore I think the issue we still have to deal with is basically Conway's law in action right people you know which is kind of the way you develop software perhaps it kind of matches your organizational structure most people's organizational structure doesn't align itself to a self service elastic on demand type of platform to serve developers so when you don't change the organization structure and try to adapt open stack then you know I've got customers they're like I like open stack but can you tell me how I can set it up in such a way that when a developer wants a VM I can get I can approve it first and get three other people to approve it and as long as they can get into two days they'll be okay so obviously that's not an optimal use of a cloud platform okay did I see my friend in the back giving us a signal okay well then I definitely want to thank Amar and Mark and Ken and I'm Lisa and I want to thank you guys this will be up on YouTube within the hour if you want to like revisit it or tell your friends I'm told and thank you and enjoy the rest of your summit thank you