 Thank you for joining us today on the OpenStack Thunderdome. Now, for those of you who don't understand why this is a Thunderdome, we have here a cast of very shady OpenStack characters who want you to believe that what they're doing is the best way to do it and to give them your money. So, as I just briefly mentioned, the rules are that they cannot hit each other below the belt. If you do say an F-bomb, the foundation might have something to say about it, but you all have board seats, so that's not down to me. I'm just here to moderate this panel. So, we have Christopher McGown, Chris Kemp, we have Jesse from Bluebox, and then we have Alex Friedland, and we have Randy Byers. So, Jesse is basically the only one that really doesn't, I guess, can't contribute personally code to the foundation, but everyone else here is very, yeah, there's no ATC. I had six reviews, doing my part. What is code, actually? Wow, Jesse, did you outsource the Mirantis for the six reviews? Yes. All right, so. Is that possible? It's all the same, oh yeah, Mirantis code. So long as I don't have to write it, it's possible, yes. All right, so, my first question to this Motley crew is, how is your product distributed and why? And you have to say why one other person on the panel's distribution is shit and why? So, can we all agree that it's Randy's? Sorry, Randy. But Randy is now EMC's. Yeah, it's now EMC's, so. Good luck. So, for the first question, I think I'm gonna pick on Kemp. Well, so, we actually are unique, I think, because we sell OpenStack as a piece of hardware that you plug a rack of servers into that you buy, and they can be Dell, IBM, Cisco, HP, Supermicro, Fujitsu. So, we've done this because OpenStack is frankly very complicated. And Nova has eight or 900 config options you can set when you run it. And if you try to do this yourself, you'll end up having to hire a bunch of people who really know what they're doing, and then they'll need training from Mirantis and consultants from Mirantis. And pretty soon, you have months of work you put into a very custom OpenStack, and then it doesn't work with anything else. And so, what we found is, if you wanna have OpenStack be the center of the universe, and you wanna build your own service provider, there's some great people here that you wanna talk to. If you just wanna turn something on and have it work and be as close to Amazon, where you pull out a credit card and you just start using it, we think we've got the best approach. So why is one of these? Where, Jesse, you gotta wait. Why is one of these? Stop on that. Yes, stop. So why is one of these other people's distribution wrong or shit, and why do you believe that? And then that person will then get the mic to be able to talk about what they really do and defend it and move on from there. Well, I think that knobs are useful if you wanna customize your deployment. And so I think we've got some great software which has some knobs. If you really wanna go all in and you're eBay or PayPal or a telco, you might wanna have hundreds of consultants and engineers working on it, and so we've got some people here that do that. And then Jesse hosts it. And so if you don't wanna own your own hardware and you don't wanna do anything, it's a good model. I don't know what Randy does, other than keynote conferences and go to Asia a lot. So I would say Randy. Well, apparently I have the world's largest retailer with a 22 rack proof of concept on 2,000 cores that's gonna grow to about 60,000 cores in the next several years. So as far as I can tell, what I do is I build the world's best production grade open stack systems that have ever been produced. Okay, fair enough, but. Excuse me. How does it ship? Excuse me, can you guys introduce yourselves? No. I have no idea who works for who. So that would help. Christopher McGown is founder and CTO at Piston. So they have their distribution. And Chris Kemper is with Nebula, their distribution. I believe he likes to be called Chris C. Kemp now. Ah, lovely. And unfortunately the first slide that would have had all the detail was a little bit wonky. It worked on the slide, but when we actually played it, it looked like this. Oh no. Oh yeah? Yeah, kinda messed up. And that's why we didn't actually get to show it. Jesse is a co-founder and CTO of Bluebox, which actually does hosted open stack. And then we have Alex Friedland, co-founder of NCEO of Morantis, which is services, subscription and also training of open stack. And then we have Randy of Cloud Scaling that was acquired by EMC. And you just heard that he's the one that's the only production grade distribution of open stack. And so you were going to, how awesome your stuff was and why someone else's was pants and who was pants. Also how it's delivered? So the way it's delivered is that we do an over the wire installation of the initial boot box. And then that box is the center of the control plane. And it bootstraps all the rest of the boxes basically with Pixie. So it's very similar to the way Nebula basically works except instead of putting our appliance in we bootstrap the first box by hand which then bootstraps the rest of the cloud. Why is yours better than say Pistons? Well, some of this is relative, okay? So I think that Pistons is a solution that's appropriate for certain kinds of things but I'm not going to pick on them today. I'll explain why in a second. And, but why I think that ours is better is that we spent a lot of time trying to not use pieces of OpenStack and methodologies of OpenStack that were fundamentally broken. So for example, we don't use Neutron because it's a flaming piece of crap. And if you use Neutron, you're almost certainly not gonna have a scalable network. So we do something else. We have our own layer three networking model that plugs into Nova networking and it scales very, very well. We've never had a problem with it. It's totally bulletproof. It's very high performance. You get maximum East West performance. And so as far as I know we have one of the few OpenStack distributions that actually has a very high performance network, right? It doesn't use the crazy Nova network single host, multi-host BS that was made by somebody who doesn't understand networking at all. To interject briefly, to speak in Neutron's defense, it's not just that it's a flaming pile of shit. It's that every SDN on the planet is even worse. There is absolutely truth to what McGowan just said. I agree with that. But you don't strictly speaking have to use Neutron with an SDN. And unfortunately, the problem is, is that if you try to do networking as a service, like there's 20, 30 years of networking gear. You're gonna stick that all under a single API and a monolithic architecture. I mean, think about it. That's a fool's errand. But anyway, getting back to it. And then the second thing that we did is that we were the first to build a scale out control plane. So what most everybody else did is they did HA failovers. You had active passive on all the open stack services and your services. And then they did master election systems, which Piston and Nebula do, where you've only got one instance of a service for any time, but when it fails, you can re-instantiate it somewhere else. And we thought that didn't make any sense because then the control plane has to scale up. You have to make bigger boxes out of the control plane because if you run out of oomph on the APIs, that's your only option. So we built active, active, active, active, active. So we've tested it up to seven for this retailer. And we know we can get up to 30 theoretically. And that's pretty awesome because it means that even if Nova or one of the other APIs has crap performance, we get that crap performance times seven, nine, 11, whatever it is. Okay, so it's your turn, Christopher. Oh, I didn't get to say a bad thing. Touché. So I have a bad habit of running people over and I've tried to train myself out of that for the last seven years. So I'm not gonna, I'm gonna pick on the person that I like the most on the panel because I know that they won't like punch me later. So, Alex. I just wanna say that the main problem with the Miranda's distribution, other than the fact that they're a fantastic group of guys, is that the idea that there's zero lock-in is selling snake oil. Because there are pieces of OpenStack that are fundamentally worthless without plugging something in that creates lock-in. So if you get Cinder, you don't get block storage. Okay, yes, you can carve block device out of LVM on a KVM hypervisor. Nobody thinks that's block storage, right? Okay, that's why they're all using Seth, right? So the thing is, is that there's always lock-in in OpenStack and when you market it as there being no lock-in or the zero lock-in pure place solution, you're simply selling your customers bullshit and because they want that thing to exist and they're buying it, it sort of is a little bit misleading. Gosh. I have to respond now, right? Yes, you do. So the beauty of my position here is that I didn't understand the single word that any one of those guys said. Because I have no idea what networking actually means inside and the only thing I know is that OpenStack is good and we figured out this earlier. So we called Randy and said, Randy, do you have a project for us? And that's how we started in this business. Oh, you heard that. It's official now, yes. Randy is the father of, well, in some ways, Mirantis, yes. And so since we never understood what it really was, we just went to customers and said, we will figure it out with you together and we did that with about 135, is the last I could tell. And the distribution we built, we just took the information we learned from those customers and packaged it into a distribution and then we distributed basically for free. And so last I checked, we had 10,000 downloads this year and it's probably not a good distribution because of all the reasons that Randy suggested, but we have probably 20 customers in production with thousands of VMs. I think one was actually a keynote today. And some big telcos have announced that they're, like Ericsson announced that they're gonna use it and are using it to go to all of their telco customers. So I'm not sure how it happened because I'm not technical, but I guess these guys are right. So you can pick on Christopher then. Christopher, why is my bad? I'm used to picking on Josh. I actually have a thicker skin than he does. You do. So let's explain. So Josh McKenzie was co-founder with Christopher Episton and he's now gone to be field CTO at Pivotal Labs and that's why he's not here. So I've heard that you have a wonderful distribution because you have brilliant engineers and you've completely reinvented OpenStack. It's much better now, but it exists only in Episton box. Is that true? Not really. We have really intelligent engineers. So I'm the CTO Episton. Our product is actually a software platform that deploys cloud applications that we just happened to use to deploy OpenStack because that was the first thing we did. We were among the founders of OpenStack. Joshua was there with Chris Kemp at Nebula, the NASA Nebula project before even it was nascent at Rackspace that we were gonna do a thing. I was at Slicehost and when we kicked off the Austin summit in Austin, surprisingly, OpenStack isn't really good with naming if you haven't noticed. We were there. And we deploy our product via the internet. We download an image. You install it on a USB stick. You install that. It becomes a boot node very similar to Randy's where that ends up being the node that discovers other nodes automatically and then deploys via netboot, via pixie, hardened Linux distribution. And where we go different is not that we use master election to elect a single point. We use master election and our orchestration engine that is not in OpenStack to deploy all of the services everywhere. So we have a converged model where storage and compute and networking are all on the same hosts. And in so doing, we master elect only critical services. So things like the database need to be critical to the cloud. There needs to be one of them or there needs to be a cluster of them that deals with replication and insight. I have a question. Yes. If an attacker breaches one of the VMs and gets access to the underlying storage or breaches through the APIs and get access to underlying storage, does that mean that they can read the data of all of the VMs and the OpenStack database and the messaging cues? Not currently. We're using C groups to avoid that. If they reach all the way into the actual host metal and they're actually able to see the stuff data stored, does that mean that they can see all of the data? If they can see all of the data, if they get to the point where they can see all of the data, yes, they can see all of the data. Right, so the hyperconverged is effectively, you've squashed the control plane and the data plane together, so there's no separation. So if somebody wants to draw a line around it, put like a firewall between it, they can't do that, right? If I walk into your data center and walk out with your controller server, can I see the data? No, you would not be able to see any of the object storage data, you would not be able to see any of the block storage data, you would not be able to see any of the VMs because the control plane's in a physically separate rack. And it's isolated in the network. So we're doing software firewalling between the two networks, we prevent all customers, we have actually a VLAN segregation for the customer workloads, but if the customer or an attacker were to break out onto the bare metal, they would be able to access the things that they could access. So I'm enjoying this discussion. There's this whole book called the Opens Tax Security Guide, which we wrote and everything that it recommends you do, we've done, including everything these guys are talking about. In fact, when you have hardware, you can actually take advantage of the TPM support on the motherboards of the servers. We actually have a hardware chip that generates random numbers so that encryption actually works in a cloud the way it should, and you can do all sorts of things with key management, storing encryption keys on the hardware. If you take an approach where you plug it in, you turn it on and it works, you can make all these decisions and you don't have to have all these debates. Frankly, it's really important at this stage of the market where Opens Tax is so complicated. So we also have TPM support. We are actually shipping that in production. There was this small telecommunications company. I actually wasn't at the keynote so I have no idea if he actually spoke, but Marcus was gone, they're actually running TPM with Mount Wilson. All right, boring, boring, boring, my turn. Wait, wait, wait, do I have to say that your product is bad? Because I actually have no idea what your fucking product is. Oh, perfect, well let me educate you. Let me educate you on the right way to consume Opens Tax. So, Blue Box delivers private cloud as a service. That means each customer gets a single tenant Opens Tax installation that is deployed on Blue Box hardware in our data centers. It allows us to deploy the implementation today in three business days. By the end of the year, we should be within an hour. We handle all of the operations of the data center of the hardware footprint of Opens Tax itself, leaving our users to benefit from working with Opens Tax, not on Opens Tax. So, my good friend, Chris C. Kemp here, suggested that if you want to be like Amazon, you should use his product. Except the entire point of being like Amazon is that you're not buying a proprietary piece of hardware and locking yourself into something on premise. We're able to deliver private cloud that just works in a data center without hardware that you have to deal with without a proprietary box. So, Blue Box is like all of the downsides of public cloud with all the downsides of Opens Tax. No, it's all the positives of public cloud with all the positives of Opens Tax. And I don't know about you, Jesse, but I personally do have a credit card with a $100,000 credit limit, so I can just... Oh, perfect. Perfect, you should be buying his boxes all day long. Okay, wait, wait, wait. So, this leads on very nicely to who is your target customer? I'm gonna start there too. So, there are like 100 customers, the Fortune 100, that are perfect for Randy and for Alex. There are, I don't know who buys these things, but for everybody else in the marketplace, you've got Blue Box Cloud. We're private cloud for SMEs in the middle market. It's for those, again, who want the benefits of private cloud. You want data sovereignty, who want control of the platform, who want control of cost, but who do want those benefits of public cloud, OPEX, elasticity, time to market, open APIs. And so, we found that this was the best model to deliver a product that really was targeted towards that middle market customer base. We're selling to enterprises that are trying to transform themselves from being traditional IT into web and cloud developers and also to service providers who are focusing on that sort of market internal app development. And we're a private cloud vendor, not a public cloud vendor. So, some of the concerns from a security perspective, because they're building apps internally, aren't yet a problem for our customers. And Chris, Keb? We're really focused on Fortune 1000, but not the top 50. So, we're focused on companies that are probably using a lot of Amazon web services. So, our customers are some of the largest, the largest biotech companies in the world, the largest movie studios, the largest entertainment and web properties. Almost all the national labs use our systems. NASA JPL, these are all production, like paid customers. And so, they're folks that are not at this event. Our customers don't come to these events because they don't care about OpenStack, the details, they don't care about the implementation. They just want to have a private cloud and they want it to be reliable, secure, and they don't want to hire a single person to build it, manage it, or operate it. They just want it to be an appliance. So, I'll piggyback of the piston story. So, we sell to customers who actually transform themselves. The trying part will have to remove. So, as a result, there are kind of two tiers. The one are the upper tier of those who are actually doing it. So, we have the top 10 of the top 150 telcos. We have top 10 of the top 100 enterprises. We have top 10 of the top 50 web 2.0 companies and kind of goes across the board. And then, we also have a lot of customers who are doing it yourself for types. And a lot of those are just interested in OpenStack. They go, excuse me, they download our distro and they just work with it and we give them free support. And they call it and say, we actually love it and how much is it? And they'll go, so much and great, here's a PO. So, we kind of, you know, go for it. To interject, that actually isn't DIY, it's DI5KR. That's do it with 5,000 Russians? Nah, it'd be nice. Yeah, but no, the 5,000 Russians is the top 10 there. That's where they go. The DIY is actually, you do it yourself to the point where no Russians are involved, except on the support with an accent. But that works very well because we measure it every time with the customer satisfaction index and whatever and it's actually quite high even with an accent. But there we're measured by how many Russians were not involved in selling a PO and we're doing quite well there. I have an extra one for you, Randy. How are things going to be changing now that you're part of EMC with your target customer? They're not changing with the target customer. The delivery model will change, the target customer hasn't changed. And, you know, how many people have heard of Pets vs. Cattle? That's sort of cloud mean. Okay, great. So we like to sell to enterprises that understand that they want to get a cattle cloud, that they want that Amazon style experience because they're adopting DevOps and they're working on next generation cloud native applications. And if they're really focused on trying to make their data center cheaper or get rid of VMware and have a lower cost VMware, that's not really a good fit for us. Because what we're trying to do is we're trying to be the guys who deliver, you know, the water, you know, the plumbing inside your house or the electricity. We just want you to turn on the tap and for it to come out and as much as you need to use and then you don't really think about it. You think, you know, more about the applications that are running on top of it. That's really our focus. And, you know, EMC is really interesting. You know, if you had told me like a year ago, hey, you're going to wind up being part of EMC, I would have been like, no fucking way. But it's turned. How about two months ago? Two months ago, it was starting to change. But that, we were talking a lot to them a lot more then. And the thing is, is that what's been very clear is that they really believe in the world is changing. If you look at, we've got a product deck that we show our customers and I've got source data from EMC and they've actually been using for about a year that shows that the net new applications, the more cloud native applications are growing at 10x the rate of the legacy applications. And, you know, that, I love that. You know, that's where I want to be, right? I don't want to fight on the hill with VMware because they own that hill. I'm just going to get tore up going up. But I want to fight on a new hill where I can be king. You know, Amazon's king in public, but nobody's really king in private. And so I generally think that's what OpenStack should be doing. That's where we focus and that's where EMC wants us to focus because EMC still, you know, VMware's part of the Federation still has a place, you know, and is there and we want to continue to make them successful but we think they're good for one thing and we think that OpenStack running on EMC gear is good for another thing. Okay, so that brings us to the next one. Then I'll start with you, Randy. Is OpenStack's velocity a help or a hindrance? Obviously it's helped you with the company being acquired but is it a help or a hindrance for your customers? The height velocity or the code velocity? Pick one. The height velocity is very helpful and continues to be helpful. I'm not sure that the code velocity is, it seems to be decreasing pretty dramatically, especially in the core projects and we're seeing it be slowing down, innovation rate slowing down. I think that we are sort of jammed up because we are under the illusion that we're gonna fix certain very broken parts like I named Neutron earlier. I'm gonna try not to name any more so I don't get nasty emails and phone calls from PTLs. But we need a- There's 22 of them now so you- If I can figure out who it is when they call me. So I think that the velocity of the code is in some ways it's slowing down is actually starting to be a help but that's only because I think people's eyes are opening. I don't know if people probably weren't here for the board meeting yesterday but in case you missed it, the technical committee came to the board and they said we finally get that there should be competitive projects. Like there can be more than one block storage solution, more than one object, more than one compute maybe even and we want your help to figure out how to make that a reality in the community and that's been a pet peeve of mine for a while because what happens is somebody implements a very broken solution and nobody else can create an alternative to it because it's not the blessed special version and sometimes if you're a good startup or you're a good software development team you build something, you realize you built it wrong and you just want to throw it all away, start again, take all the learning because the learning matters, not the goddamn code. I do not know what it is about developers who are so attached to the code, like code is easily rewritten. What's most important is architecture and the learning that you have that actually makes the system work. Do you think that the foundation is going to be able to represent even more innovation or more contributions that are coming in? Yeah, I mean, I think if we have a monolithic system where there's only one project in each bucket compute object block and all of those have to be integrated together tightly every six months, then that fundamentally falls over when you're nine, 10, 11, 25, 30 projects, right? I mean, it was good at two, it's a terrible idea now. If we act more like the Apache Software Foundation and we have a whole bunch of projects that are all interrelated that can be put together in various ways and there are groupings that we test and validate on some kind of cycle, then it's going to make a lot more sense and each of those teams can operate at different speeds. Right now we operate at one speed altogether and it's very tough. Technically we operate at one speed and then one of these things is not like the other speed. Swift refuses thus far to adhere to the every six months release cycle and it's actually been very good for Swift but for OpenStack as a cohesive unit, it does a lot of its things its own way and refuses to join the community. Yeah, but that cohesive unit is going away. Yes. That's what the TC just said, so. Yeah. Well, so let me. While at the same time, still enshrining Swift as the paragon of what everything should be doing. I don't think so. No, no, that's a bad. So let me add my two cents because we took the baton from Chris and Nebula who were a huge authors of OpenStack originally but now of this esteemed panel. Mirantis has actually moved as a number three contributor. We had 92 people contributing to OpenStack in the latest in June release. And if you look at Stackforge, we're by far number one with like 150 people and all of the innovation and some of the scandals that we've talked about actually got started by who here knows what rally is, project rally. Quite a number of hands. So we started rally because we figured that performance of OpenStack was not something that was up to the par. And also it was very, very difficult to convince people to fix problems in multiple projects at the same time. So we started rally as a project to kind of drive that. And as a result, then you could have, you know, built a use case that shows performance across the board and you could diagnose it to seven patches in three different projects. And you can do them as bugs and fix them as bugs without necessarily having to coordinate that. So that became extremely popular. Lots of people are using it. And when we try to incubate it, it got stuck with it's not your agenda, it's mine and I'm not gonna let you. And that's what caused this whole incarnation. I mean, that consternation. And that's why we're changing the governance. But going back to the original project question, I think the speed of innovation inside OpenStack and this code velocity is actually unbelievably fast. I happen to disagree with Randy here. Slowing down. You get to easily believe that. Slowing down. Maybe, but it depends how you measure it. I mean, there is a lot of feature innovation and there is a huge movement of OpenStack now into things that it hasn't been conceived to do. It goes away from just being IIS. And OpenStack is becoming a full stack slowly and the movement is starting up the stack with projects around it into the operational areas and the like. So not to disagree there, but OpenStack has always toyed with becoming a pass. Like at the very first summit, there was a guy, Eric Day, who was an employee of Rackspace who had built a queue as a service project and couldn't get people to get involved yet because it wasn't ready. So OpenStack has never been, oh, it's just the IIS. It has been we toy with the idea of becoming a platform as a service. It was originally conceived as being a platform as a service at NASA Nebula. And the fact that projects are proliferating in such a way that, wow, that's really hard to say. You want to jump in? All right. I want to just violently disagree with all of you and especially Randy. Safe harbor. I talked to Jesse. I must be doing something right. How many of you guys get the emails from Amazon about all the new services that they're offering, all the new Amazon AWS stuff, right? I get those. They're already a platform as a service. Yes, they're already a whole bunch of things and OpenStack is not. And so it really frustrates me when we talk about how we need three or four different competitive object stores or compute engines or when we can't even come close to keeping up with the innovation of Amazon. Amazon has figured this out. They have one platform, one system that they deploy at extreme scale. No, that's not true, actually. Chris, Chris. They have a bunch of platforms. Chris Brown, who was on my advisory board for four years, was lead developer for EC2. Out of everybody here, I have both insight into how Amazon works. And the way that Amazon works is that there are a bunch of independent teams that work on each of the different projects. Many times these projects are competitive with each other. Anybody remember SimpleDB, which was replaced by DynamoDB, right? And you can store your objects in DynamoDB if you really want to and it's based off of SSD. So actually, there's a high level overlap and there's a huge amount of innovation from Amazon and Google, because all the different project teams actually all innovate in different, they're not in lockstep, they all go at different rates and they're all doing their own things and they're very independent. So mostly coupled system. And so in aggregate, they get more throughput. You're missing my point. Millions of Amazon customers all use the same DynamoDB. They use the same S3, they use the same EC2. There might be different compute clusters around the world. Every OpenStack customer builds their own highly bespoke OpenStack cloud with a whole bunch of different decisions about the hardware they run it on. And that's great for a consulting business. I mean, having competing projects doesn't necessarily make that problem worse. Well, wait a minute though. So this is from an outsider who's not on the board or anything else. Do you know what I see? I see a lot of boys, and I know that they're go-coders too. I'm not disagreeing, but I see a lot of arguing about, my project is better and why, and most of the people who are contributing these codes and actually trying to make all these features have no ops experience at all. They've never run it. They've never run it and most of the people who are sitting in this room want to be able to run this stuff. Well, you guys treat it as a science project and as a frat house. People here actually have businesses to run on it. So, which of you actually solved that problem? So, you buy a box, you plug it in, it works. Or you buy ours as a service and it works. I mean, look, Amazon has 138 services last time I counted. OpenStack has what, 22, and official projects, right? And what did we hear at the keynotes yesterday? We heard over and over and over, stability, stability, stability. So, we've got this problem. We can't keep up, we presently can't keep up with Amazon's innovation, yet the core of the project is being rotting to some extent from a stability perspective because of these integrated releases. It's an interesting challenge. The other piece here that's fascinating is you've got sort of this marketing machine that is these releases and so every six months this new release drops and that means that every six months, customers will come and they'll say, are we running the latest thing? Because we read about it. When in reality, the latest thing may not have bits or pieces that you actually need in the environment. And so you've got this interesting duality between tracking that latest thing and all of us need to take that latest code and integrate it and make sure it works with whatever product we're delivering. But the benefit of whatever is in that release may not even be necessary. So, it's quite the six month release schedule is quite the challenge and it'll be interesting to see the way SWIFT does it if we can move to that model and we have competing projects. I think that will allow people that operate OpenStack to pick the best project that actually works, put the flag and the weight of each of our engineering teams behind that particular project and theoretically get more like Amazon in the way that they develop internally and thus hopefully get closer to the number of services that Amazon has. I also think we've got a little bit of identity crisis. Like, PaaS in OpenStack is the worst idea I can possibly imagine. We've got Cloud Foundry for PaaS. Let's focus on making a stable platform that something like Cloud Foundry can operate on. And PaaS is a particular one because you're talking about something that's designed to do a multi-cloud abstraction. And so, this actually- We had a boxing match on that before, right? We did, which was fun. We're still surviving. The good thing is that actually this whole thing is leading very well into the next section because we talk about the flexibility and the complexity because there's so many different projects and they're all competing and everything else, right? So, what you had mentioned earlier was you guys have dealt with a lot of the customers with the early Godfather of OpenStack Cloud Scaling over there. To help you with looking at customers and their operational problems and things like that. And to Jesse's point, six-month projects, let's look at, let's talk about Xerox. They spoke at Santa Clara last year when we had the OpenStack for the Enterprise forum. And they would, up on stage, loads and loads and loads of nodes, but they were very happy running on Folsom. Now, there's a lot of us in this room who would not want to run Folsom in a production environment, but you had Xerox who did. So, okay, they're running in every other. So, but the question is, there are some people that don't want to move up with those releases. So, what happens when it goes out of life? How do you know when to choose and what has helped with driving your decision for your distribution? For us? Well, first of all, just to give people an idea, today an average install that just does, standard customer takes under a day. I mean, in a normal environment, you have to do documentation and then things and training and all that, but OpenStack got to the point, speaking of, it's four years old and a normal customer on heterogeneous environment can get it up in one day and sometimes they can do it themselves. And the beauty of this is we don't want to be opinionated. I think the challenge that some of the early players in OpenStack ecosystem is they thought that they knew better than customers what customers wanted. And ultimately, we don't have a good idea of what the usage patterns are for OpenStack today. Going back, we kind of figured this out, but we have no idea how OpenStack is gonna be used and why going forward because ultimately, it's becoming a commoditized operating system for the new transition of a cloud and it will become a totally ubiquitous solution that can become an embedded solution for appliances, it can become a driver for somebody's loads in a different, as a service model and there are only so many people who can do what Amazon is doing and Google is doing for themselves so there needs to be an alternative that will drive all of that. So what we said is we're gonna listen to customers, we're gonna create a configurable option that even a not very sophisticated customer can use and then we're gonna embed it to people who are just gonna pull it through for whatever applications. And then eventually, we will make sure it can be upgraded, but if you don't want to upgrade it, you won't. That's life, right? And some people just not gonna upgrade, but then the danger you have if people don't upgrade to the latest version is eventually the stuff is end of life and support of it is gonna be a problem. So we have plenty of customers who kind of went that route and built franking clouds and it's working fine. But the problem with the franking cloud is that the cost of supporting a franking cloud is just gonna increase over time, right? And so if they wanna have the financial equation of supporting their own franking clouds, well, more power to them, but that's not where the business model is going. It's like a good business model though. Not really. For the 5,000 Russians? You know, we certainly couldn't raise the money we have raised if that would have been the thing because that doesn't scale, right? And the only reason we're able to raise money and continue to do this is because there is scale in the business model we're going after and the market is becoming vast. And if you ask my opinion as to where this is gonna go, I'll tell you, I have no idea because what we're learning every day by talking to customers is they have thought of ways of using OpenStack that I haven't envisioned even a month ago. And by the way, they downloaded my stuff and they configured it somehow and they told me what they did. And the marketing folks over there are like, oh my God, we have to build a use case. We had no ideas possible. So that's where I think it's interesting about this market. So there are tons of customers like that, yet there's a whole nother set of customers that say I just want the benefits of a cloud infrastructure with the security and compliance that comes with private cloud. And so what I really like about this panel, quite frankly, is we've got such a diverse set of options of how you can consume OpenStack, which is unique, it's unique to this technology offering. And so we've got something that works from whomever is looking to purchase it and that's really important. I think I'll say I once said that OpenStack was like the Linux of the cloud and no one runs Linux, people buy Macs, right? 98% of the computers run Windows, for God's sake. I mean, I think it's a powerful platform. A lot of people power a lot of things with Linux and a lot of people will build really amazing things with OpenStack. But I think if you want a cloud computer, if you want to really democratize this technology and have every company, every enterprise, it's gotta get really simple. It's gotta be simple enough for people here in Europe to sell it and install it and use it. And you've gotta go into work in the morning and log in to your email, which is gonna be a SaaS application and then log into a cloud and build things and design things and prototype things and render things and sequence genomes or whatever you do with it. And I kind of agree with Chris Kump here. I'm surprised to say, I was like, wow, we agree with each other. I'm actually, yeah. I kind of disagree with Alex. I think that the OpenStack distributions, the OpenStack products, we should be extremely, extremely opinionated. The fact that we're not opinionated has led to a proliferation of all of these projects, a proliferation of all of these competing drivers in the projects, none of whom have any sort of like mutual, they're overly complex. They don't share similar capabilities. You get an SDN in Neutron that does one thing and another that does another and they don't implement the basic, like I want an IP address or I want a port on this network. And very similarly, though not as bad for Cinder, I would actually go so far as to say we should throw Zen out of Nova, which is kind of heretical since Rackspace runs Zen, but they're the people who are building it. They shouldn't exist. You wanted to add something before I move to the next one? Yeah, I mean, actually there was a whole bunch of stuff queued up there. I'm gonna try to just pick one response. Do people remember IPsec and IPsec VPNs in the late 90s? Yes, absolutely. You remember how everybody took the standard and implemented it and then none of their shit worked together? Yeah. All right, and still sometimes doesn't. That is an example of why having the same software and having the same standards doesn't actually necessarily get you anywhere. What's really important is to test behavior and to be able to know that you've got the same set of features, functions and capabilities. That's why Defcore and RefStack and TepisTest are so important. If you have that, then whether Swift is implemented one way or another way doesn't fucking matter because you can test that both the implementations do the same basic thing. And once you do that, then you can have guarantees that every OpenStack cloud is not a snowflake. Now this gets to a fundamental problem, which is when people wanna DIY or when they're building their products, whether any of us up here are right or wrong, they make choices about the architecture and those choices fundamentally impact the behavior. So I'll give you some examples. If you turn on a VM on Amazon web services, you automatically get a public IP address. If you turn on an OpenStack, you do not. You have to turn on IP auto assignment. So if in your distribution or product, whatever you chose to turn down by default, you act like Amazon and you're more interoperable with them. If you don't, then you aren't. And that's fine. It's not about whether you are or not. Please don't open the Amazon can of worms on me. The point is, is that all of those choices we make since OpenStack can really be configured to be anything is what gets us in trouble. And we don't spend enough time talking about the architectural best practices, the right way to put things together. What should the baseline set of features be in block storage and object and compute and so on that actually matter? Do we need live migration or not? What's the use case for it? All of those things are missing. Instead, everybody kind of does it their own way. And then that's the thing that leads to there being no interoperability, to there being no place to, these things just not making sense and not having enough. But at the same token, that sort of opinionated thing gets us panels like this is why all of you are here. Like each and every one of you is actually here to listen to us yell at each other. And so this is going to be a yes and no answer. So we can take some questions before we boot it out the door. I will also get kicked out at this point. So is OpenStack boring? This is going to be awkward because Joshua McKenzie says yes. I say absolutely no. And it should be. And it's a problem that it isn't. I agree. Yeah, no. Unfortunately no. No, but it should be. Is it a solved problem, Randy? No, not even close. One day it will get boring and there's going to be a multi, multi, multi billion dollar industry. And all of us here are actually building it up. So that's a lot of fun. I hope it's never boring because I think that means we've stopped innovating. Is it a solved problem, Jesse? No. You can buy Nebula today, but OpenStack is a mess. You can buy Piston OpenStack today, but OpenStack as a whole is a mess. We're shipping IceHouse. We probably won't ship Juno for six months because there has never been an OpenStack release that has worked out of the box. And when it can, it will be. Any questions from the floor for our very cheerful panel who might want to punch each other in a few minutes? Actually drinks are on Randy at the Hyatt Bar. And the rest of us will be at the Meridian. I want to add one other quick thing just before we get to the final. So I'm actually leading a new effort called the Application Ecosystem Working Group with Tim Bell in the user committee. And one of the things we're trying to do now that we have a lot of EMC and Mirantis and Blue Box and Piston and Nebula Clouds out there, people are starting to build stuff on them. They're starting to build applications on them. We heard the keynotes. They're getting deployed in enterprises where people are trying to take passes. So we're actually having a session on Thursday. If you're interested in building an application ecosystem on OpenStack and if you're interested in interoperability between all the different products from the folks on the stage here, please come join us. It's on Thursday afternoon. It's the Application Ecosystem Work. It's a 90 minute working session where we're gonna have a lot of people there working on it. I'm gonna get a last one here then too. So I just wanna point out that the whole statement about Linux, like it doesn't ring true, right? Because the vast majority of servers in production are running Linux, right? So whether it's on your desktop or not doesn't make sense. But if you were to include desktops, then I think you should probably include handsets and Android as Linux and it's shipping, I don't know, a couple hundred million units probably every quarter. So if you added up the net amount of Linux out there it probably outweighs Mac and Windows put together ultimately, especially if you also look at ARM embedded devices. Linux had a benevolent dictator though. Yeah. The OpenStack Foundation doesn't have one. Yeah, that, we, yeah. You talked Linux, so I had to get in there. This feels more like the war between the unices almost before POSIX was invented, not so much Linux. And I'm not old enough to- We're all benevolent, but no dictators now. So thank you very much to our panel. We can, I'm sure we'll continue this on Twitter or some other form of medium. But yes, please come up. Yes. Yeah, yeah, I have a question. Okay, now that all the big boys like IBM are busy buying up the little startups, where do you see it going? What's gonna happen to all that innovation that we just spent the last four years building? Well, my answer is watch us, right? Because we just, you know, the shameless plug, but the talk of a few months ago was, will there be somebody who can stand up on this market but the big boys are jumping on? Will there be somebody who is a standalone who will be able to play and challenge the big boys? And a couple of weeks ago, we announced a hundred million dollar financing. And the message there was that it's possible for a small guy to be a standalone and there are people who believe that it's possible to stand against the big guys. And remember the reason OpenStack came about in the first place. I mean, it is a way for customers with heterogeneous environments to create an even playing field and lack of dependency from the big players. And that being said, a small player, a pure play OpenStack player is the one who can create that level playing field and allow to get some of the profit margin from the infrastructure stack over the long term. And that's the level of innovation that will enable all the innovation that's happening in the ecosystem. And I think that's what we need to start focusing on is how we enable quick and easy innovation for all the players who are not incumbents. Because ultimately that's what customers are looking for. That's will end up destroying the cost and will enable the exponential scale. And I think that's- Cut it off. Dude, I'm not done yet. No, look, liquidity drives investment. Liquidity drives investment. And so you're gonna, you no longer will see new distributions, but you'll see new entrants into the marketplace. You look at companies like StackStorm, you look at companies like Platform9. There are people in the space that are doing new different things. I think it's a wonderful sign for the industry. All I know is that the average enterprise is gonna have a very hard time consuming DIY OpenStack. I'm not talking about the LeanFord guys who are doing it now. I'm talking about the average guys who have a hard time running their sand. Whether it's Chris's model, any of these folks model up there, I don't know, but your average enterprise has to consume products, not science projects, and that is 100% certain. Yeah, and to your question though, it's a fair question. I mean, a hundred million dollars is impressive. We've raised a lot of money as well from some world-class investors, but we're all very small companies in the scheme of $100 billion market cap companies, except for Randy. Except for that, except for Randy. What exactly does a VP technologist do? It's a fair question. We're very early on in this, and I think there's still a lot of really big companies that really have to figure this out, and that might involve partnering with companies that are here on stage, or some really bold moves. We've already seen a few in the last couple of months. You sort of stole my thing. So I guess I'm gonna change it. Alex is actually buying the drink, so I had completely forgotten that you had just announced your round. So congratulations, and now you're on. How much of the hundred million is committed? How much of the hundred million's committed? How much of the hundred million's committed to buying a strings, and also committed? All right, we gotta go, guys, we gotta go. How'd you guys? How'd you guys? Big hug, big hug. Thank you.