 All right. Welcome to Is OpenStack's Future Still in the Cloud. I'm Matt Joyce. To my right is Jesse Proudman and Kenneth Wee. Hi. So this all started as basically a Twitter conversation that kind of devolved into somebody saying we should propose this as a talk. And we did. And apparently, some people voted for it. So we weren't the only ones interested in the conversation. So that's where this whole fiasco originated. I guess we'll get started now. And we'll start with defining some common terminology. Yeah, so I brought the stuff. So actually, Matt, do you want to talk a little bit about what actually started your discussion? Just to give you a little bit of background. If I can remember. I think we got into a larger, wide-ranging discussion over what the future of OpenStack was, where it was headed. And there was conversations about whether or not it may be coming more monolithic and less of an asynchronous elastic cloud and more something headed towards VMware-style cloud compute. And there was a lot of back and forth conversation about that. And we all had our own independent opinions. Right. And so I think one of the things we want to do is we want to have a fairly free-flowing discussion about between the three of us, because we've been involved in OpenStack for a while. Matt, in fact, was on the NASA team that actually started, helped start OpenStack. And one of the things we wanted to address was this idea that, in this section, is that when I talk to people about OpenStack, I'll talk about cloud, I think one of the problems is that I can't get two people to agree on what that means. And so what happens is two people say they want OpenStack to be a cloud platform, and they are actually meeting two fairly different things. And so I thought it would be important for us to set the table for the discussion by defining some of our terms. What actually are the different meanings for cloud and for virtualization and the cloud native? And I think that'll help frame the discussion about where is OpenStack is going. So I guess we can just kind of free-flow it. What comes to mind when you guys think about, when someone says, hey, I want a cloud. So when I think of cloud, NIST in the US is the naming kind of standards body that does a lot of the definitions for the US government. And they've got a great definition that I like to use kind of as the standard when I'm out talking with customers. And essentially, I'm going to totally botch it. Normally, I put it up on the screen. But the message is that it's about infrastructure available on demand. And that's it. That's their definition. It doesn't include all these additional services. It's really about getting infrastructure. When I'm out in the field now talking about cloud, I pitch it as an experience. And I think that's what people have become accustomed to. It's an experience. It's an API. And it's a service level agreement between you and whatever the provider you're getting those resources from is. And I think that's what it's become. And that definition seems to resonate with customers that we're speaking with and prospects that we're speaking with today. I can tell you, the NIST definition came out actually around the time that OpenStack was being developed at NASA. And I remember we were told to disregard it when it first came out, which I thought was pretty funny. In regards to that, I agree mostly with what we told to disregard it. Because we were actually facing a different policy requirements set coming in through FISMA and a couple of other NASA-specific policy requirements. And they hadn't figured out how to frame the NIST requirements in relation to those independent requirements. It's government. They have a lot of different policy and procedures. So we had a group of people working policy who basically said disregard this for now. We'll come back to it later. Like many things in government, sometimes when a policy is too complex or new, they just kind of say, we'll circle back to this later. In regards to whether or not cloud is just as a service or something to that effect, I've always been a fan of the puppy's versus cattle approach, the idea that clouds are ephemeral. I think that's a big component of what cloud is, the desire for the states of machines to be destroyable, that everything can be transient, if you will. And I think that's something that maybe a lot of folks don't believe in as much today. So I think you can argue, you may though, that for a lot of people, cloud is basically AWS. And what AWS has defined as cloud, it's what we think of, right? So if you take that model, it includes the Fremont stuff. But it also includes things like, I don't want share infrastructure. I assume the infrastructure underneath me is going to be fragile and things will break. And all the application needs to handle how fails occur, which is entirely different, right? Then I think what some people think cloud is. I've talked to customers that think cloud should be something that helps you run Oracle. And fails over when something happens, but you get some self-service. Those are the same customers that often think that cloud is just an economic model. That I can move something to a cheaper platform. I can move my existing legacy workload to a cheaper platform and be better off. I can save more money. And that's not the reality. So I think what's happened is actually, I think, I don't know how many of you guys would agree with me, but I think that's actually two operating definitions of a cloud that's happening in the open stack space. One is that kind of framerolastic cloud that basically, when you want to define what it is, you go look at AWS. And then the other cloud definition is basically somebody who's taken their virtualization environment and cloud watched it and called it a cloud so that they can tell the CEO they implemented, CTO they implemented a cloud. And that's more that they just should know, I'm just going to run, I'm going to use a bunch of VMs and automate getting them up and running. So I think those two things that are kind of in operation. So when we talk about cloud, I think people should keep that in mind. That's actually two working definitions. And I think one of the things we'll talk about later, it's in some cases they mesh well together. In other cases, they're actually in diametric opposition to one another. And the question is, can open stack possibly be do both and be successful? So I think the next one is, let's define a little bit about, I think people understand what public cloud is, right? It's stuff you don't own, you rent. I think private clouds kind of gone through some morefaces about exactly what that means. So obviously, Jesse, you guys do a private cloud and maybe in a different way. Yes, this is one that I think actually may have been part of the discussion that got us arguing on Twitter. There's a big debate between what is public cloud and what is private cloud. And in the open stack world, private cloud often is assumed to be on-premises software. And my opinion of the definition is that public cloud and private cloud differ by tendency. So a public cloud has shared tendency with other people not related to my business or my entity. Private cloud has single tendency. My business and its users of that cloud, belong only to that cloud, that my data will sit only next to data from other users of my business. And that goes against, I think oftentimes, what is pitched and sold in the open stack space. What do you think about the side there? Can you be a public cloud and not be large? Is that such a thing as a small public cloud? Sure, I've seen a couple. I remember Green Cloud who recently grew too big and actually became a software company that selling their structure out of Iceland was a fairly small public cloud operating out of Iceland. They were fairly successful and they actually started selling the software that they ran their cloud off of as a distributed product. I actually kind of like them. Also, if you look at Scaleway in France, they're another semi-small looking cloud. I think if you are a hosting provider and able to offer your hosting stuff as a service through a simple API and guarantee at least some minimal level of cloud capability, then you're a cloud. So they're a small public cloud. China is a great example of that. There's a bunch of public cloud open stack providers in China. But again, I think it's a tendency model. It's a shared environment. Yeah, a special shout out to United Stack, very clean interface. So before we go on to the next one, let's just talk about, I want to make sure you understand what is cloud native? Because you're starting to hear that trying to thrown out a lot, especially when it involves containers. So what, and AWS has always talked about running cloud native apps. What is cloud native apps mean? And how does applied open stack? This goes back to your definition of cloud being like Amazon. So cloud native applications are those that are designed for a cloud like environment where you don't have state, you can't necessarily rely on ephemeral storage where things can be lost or destroyed. And you're building resiliency into the application itself, not relying on resiliency at the infrastructure layer. Yeah, when it comes right down to it, if you've ever used AWS and you have a problem, AWS's response is generally kill the instance and recreate it. If your application's not able to support that sort of operational workflow, you're not cloud native. That's kind of where it starts. So that's, again, I'll get argue that's a very different type of workload than you would run in a virtualization environment that you're calling a cloud, right? Which, and I think Matt, the next section we're going to talk a bit about is what kind of clouds are we actually seeing with open stack? Well, what is it, what the community wants around what open stacks delivers? Yeah, all right, so this question is, what is the vision for open stack? How does that match customer expectations? I think personally this has changed over time. I think this is kind of where this whole conversation started. If you saw Termini's open stack is doomed talk last year. It was very interesting to see Termini's opinion. He was one of the original creators of Nova, him and Vish. And what their original goal was with Nova is now completely different than what Nova has become. I think as open stacks gained adoption, as people have gotten involved, the community has driven open stack in a direction of the community wanted to drive. And I think that's a wonderful thing. The question is, what is that today? And where is it headed? Well, and so I just, do you want to? I think one thing I would kind of bring up is what this different visions, is that actually hindering open stack from being a cloud platform? So a good example is I was an industry a long time. And if you look at Cinder, when it was visually conceived, it was supposed to be like elastic block storage in AWS. Very simple, right? And actually not supposed to be used very much relative to ephemeral storage. If you look at Cinder now, Cinder has very little, I would say it's way beyond what the original vision is. And it's now become more like a traditional enterprise storage system, right? Or that's the vision is going towards it. So you have things like consistency groups and replication, I would argue if you start doing that, you actually, we're building Cinder to such a point where it actually cannot support, it's not now longer gonna be ideal for cloud native applications. Yeah, I'd second that with Neutron. The Neutron requirements, what Neutron brings to the table, none of that's necessary in an asynchronous elastic cloud. That's all specific isolation requirements that start coming in with PCI compliance, with isolation necessity, with high availability tolerances. All of that stuff is not what you would see in elastic cloud. It's very specific to building in these traditional enterprise style networks. So I actually disagree with that a bit. I mean, I think you look at what OpenStack, who's contributing to OpenStack, where's that funding coming from for the engineers that are working on the projects and the realities that's coming from large storage vendors or hardware vendors or network vendors. But those vendors aren't just making things up, they aren't saying, hey, we're just gonna add consistency groups because we think people will like them. By far and large, a lot of those requirements are coming from end user customers who say, I've got a PCI based application, I wanna run it on an OpenStack based cloud, I need network segregation to pass the audits. And that's how the features get added into the implementation. I think the point I was trying to make in that regard is not that that isn't happening, it's that there's two groups now, two distinct groups. You have the people using Nova Network and the people using Neutron and they have fundamentally different workflows, which has resulted in the need for two different projects. So I think that drives back to Ken's point about there being a divergence between different customers in OpenStack. Yeah, I mean, I'm not advocating this, but I wonder if we're getting to the point where we actually need to have almost two OpenStacks. One for cloud native workloads and one for traditional workloads. And I'm saying that just to draw the contrast, I don't necessarily agree that's the right way to go, but if you look at where things are headed, so I'm gonna say something that'll probably piss off some people, right? I think one thing is just because customers want it, does that mean that should always be what's implemented? Right, it's kind of that, you guys have heard the analogy, probably only, I think it's an American analogy. Should we give people automobiles or faster horses? Customers want faster horses, but maybe they need to get an automobile because we need to push, help push things forward. So where do we draw that balance? Number two, I agree with you that a lot of vendors, Jesse, a lot of vendors coming into the project in some ways is good because there's a big ecosystem. The problem is what if most of the vendors who are involved actually don't know how to do cloud native, and therefore what they're building is actually not able to do cloud native, and by including all of those implementation details in OpenStack, we've now created a platform that can outscale elastically and never will, unless we somehow, you know, my friend John Griffith, who used to be the center of detail, one of the things he's argued for is take all the drivers out of Cinder, come keep it outside of OpenStack because by putting it into Cinder, you basically, you turn Cinder into this, this project is only suitable for traditional applications. I think what's interesting about the OpenStack project and being open source is that as an operator, as a package, or as a user of OpenStack, you can select which pieces of the code you take from the project and actually use and operate. So just because all these pieces are there, doesn't mean you actually have to use them, and I think that's different than traditional enterprise software. When you buy VMware, you get what's in VMware, whether you want it or not, and maybe you can turn it off with a feature flag, but it's there. With OpenStack, you actually have the ability to have some say in what you're selecting, what you're packaging, what you're using. I agree. I think this ties back to Defcore, however, in some respects. We're trying to identify what OpenStack is from just a purely compliant, different implementation perspective. As a customer, if you're building workloads for OpenStack, you wanna make sure they work across many different OpenStacks. How are you gonna do that in a world where you have one half of OpenStack, the hyperscale guys using Nova Network, and the smaller, small business and enterprise deployments using Neutron? How do you do that with Cinder with different volume deployments? How do you do that with these different mix and matches? It becomes very difficult. Well, you've gotta agree on core primitives, which is what that project is trying to do, and again, everybody to agree that those are the primitives that will make up OpenStack. I agree. I wonder if maybe there is, as Ken alluded to, a diversion occurring where you might end up with two core primitives. I don't know. So, I guess this ties into our next question. Who's paying for and using OpenStack, and what do they really want? So we see this a lot. We're selling OpenStack as a service. The customers that we're engaged with are those who have legacy data center installations. They have existing workloads sitting somewhere. They're trying to figure out what their next generation applications will be. They want those next generation applications to be cloud native, but they need to be able to talk to and tie into the installations and the data that already sits in their data centers. So OpenStack becomes a way for them to have a platform, a cloud, a private cloud, to build those next generation technologies to get out of the history of legacy application development to do something new on-premises with their existing data or in a private capacity in a hosted sense. And so it's a pretty broad spectrum. We see this in healthcare. We see this in banking. We see this in government customers. But at the end of the day, it's very simple for brand new companies to go and build something in a public cloud because it's brand new. You don't have resident data. You don't have all these systems you're trying to tie into. It's much more difficult for an existing organization to do that. That's where we see OpenStack being the most successful. Yeah, I agree. From what I've seen, the number one driving factor for adoption of OpenStack, at least as I've seen it in customers is taking over VMware license fees and getting them out of the picture. OpenStack's cheap compared. So I actually disagree with that statement because I think in that model, when you're just trying to take out VMware, you're expecting the platform to operate like VMware and that's a failure, right? Where there's heads nodding in the room, everybody, many people have had that experience either of trying to do that and recognizing it doesn't work or of thinking about it and kind of doing your homework and recognizing it doesn't work. Right. Sorry, go ahead. I sort of agree with you, except I think that more, I think that trying to replace VMware is actually in the top two or three reasons why people are looking at OpenStack, which means either people are going to wake up and realize that's not what OpenStack is designed for and not do that, or more likely what's gonna happen is there's gonna be this growing group of people in the OpenStack community who's gonna go, you know what, I still, I want it to be free VMware. I don't care about this. For now, I don't care about the cloud native stuff. I don't need an AWS in my data center. What I want is a free version of VMware and I'm gonna push all the developers to write code to allow me to do fail, automatic failover, do everything that VMware can do, but have it be open source. And that's gonna create problems, right, because that's not what the original intent of OpenStack is, but that's likely where we're headed, whether people like it or not. Hot failover was never in the initial design requirements for OpenStack and now it's a much sought after feature. That is not ephemeral. It's very nature, it goes against what OpenStack initially was intended to be in an asynchronous elastic format, but customers want it. This is what customers are asking for and so it'll be built. So Matt, do you wanna talk about, you keep bringing up this idea of this is not ephemeral. So why is ephemeral important for cloud native? Why couldn't you build an elastic scalable cloud using and have hot failover as a feature? I mean, it gets back to the puppy's argument. You know, you have to be able to take a shotgun to your data center and just start taking out machines and nothing falls down. Resiliency is key. When you look at Netflix, one of the greatest things they ever gave us was the idea of cast monkey, the idea that your environment just keeps getting hit all the time. And if you can build a resilient environment, then you don't really have a problem. I can tell you from personally experience with my current employer, our primary need is to ensure that no matter what, our customers can always transact. They can always talk to each other. If we're down for any reason, if AWS goes down or our cloud goes down or something else goes down, it's maybe not our fault. We had an issue, an outage in our first couple of weeks operating that was related to BGP broadcast. Somebody falsely broadcast a bad route. You have to be able to avoid that. If you can't do that, you lose. I mean, your whole company can go out of business. So for people to build resilient applications, the idea behind ephemeral was to enforce the idea that everything is ephemeral, which it really is at the end of the day. Nothing is too big to fail in technology. So I think, again, that's where we're gonna start getting some problems, right? I think sometimes we fail to realize in the community, when you make certain design choices, you also inherit certain design limits that comes with those choices, right? I think a lot of people in the community, they want everything that VMware offers, they want an open stack, but they also want it to be like, eventually be like AWS, they want both, right? And the reality is, architecturally, when you make the choice to be, to do shared infrastructure, so you can do fail, infrastructure failure, you've made the choice that you're not gonna be scalable, right? And people don't seem to recognize that. And to be honest, I'm not sure if all the vendors recognize that. And so they just kind of built open stack the way they've always built things with VMware and then expect that, and then they wonder why it's not gonna be a, people complain that it's not gonna be a scalable cloud. Actually, this is a kind of off topic, but I did kind of wanna bring it up. I brought it up earlier with a friend of mine. There are three things from operations perspective with open stack that I think I've never seen addressed, except maybe by Jesse's team, which is open stack is almost impossible to install easily. It's almost impossible to scale easily, and it's almost impossible to upgrade easily. And I think those are three operational workflows that open stack has never done well at. And I think that, when you're talking about the scalability, I think a part of it, a big part of that is, the enterprise doesn't care how hard it is to install. A lot of the customers build their own use cases because they have to fit into very complex systems. The reason it doesn't scale well is because a lot of people don't really care that much about scalability, although they should. And the last one, I don't know. I'm curious of your thoughts on that matter. You know, I think listening to those comments, at the end of the day, part of this comes down to, what are customers actually using this environment for, and do they need to have complete resiliency in the environment? So, you've got a transaction based website that's really key. I've got a form that takes reservations for the conference room. Like does it, if it goes down for two hours, that's not the end of the world. There are classes of applications that have evolved over the years, and certain classes don't need to be that, I've got a whole talk tomorrow or on Thursday about you are not hyperscale, that these design patterns that we talk about, like they're great design patterns, and many applications should be written with those in mind, but at the end of the day, are we adding too much complexity or so much complexity by following those patterns that we make the environments unmanageable and maintainable? And so you get into this balance that ultimately does an open stack cloud need to scale to 250,000 hypervisors. How many organizations are actually gonna run 250,000 hypervisors? How many are just gonna run 50 or 100? And so the design decisions may be being impacted by the bulk of implementations and installations just being small or just needing certain features or capabilities and the struggle between where I want to be and where I think the market is headed versus what do I actually need? How can I keep it as simple as possible today? So at the end of the day, does that mean we're gonna end up with, open stack will be a cloud that can do cloud native but only for 50 nodes, which means so basically open stack will have 10% of the total market because it's gonna be niche. That could happen, right? Maybe that's okay. Or you get folks like Intel who are now joining in the foundation to say, look, we actually want to change this. So we want to bring our engineering expertise to the table to actually fix the scalability issues. I don't know. Although this kind of responds right there, that's kind of the answer. How does the community respond to those desires Intel coming in as a great example of that? I think I'll jump this ahead to the next one. All right, do those, I'm not sure which one of us added this slide, but do those desires conflict with traditional cloud implementations? It depends on what you mean by traditional cloud. Yeah. I don't know. We'll go to the next one. This one's more fun. Do open stack and VMware ultimately collide in the marketplace? This was where we got into a big argument I think during the Twitter campaign. I say yes. I say that eventually open stack and VMware are inevitably going to collide and end up fighting a duel to the death. And I think we'll win. Well, I think the reality is that the marketplace is converging on a single solution. So does VMware and open stack collide? Well, do they go to where the market is headed? I think you see things happening in VMware that indicates that's the direction VMware is taking. Certainly open stack is attempting to be the default private cloud platform of choice or the default cloud platform of choice, open source cloud platform of choice. And so that's the same goal. Everybody's skating to the same park. And so there's absolutely inevitable collision. I think the more interesting question is, does open stack come back around and try to take out VMware's existing business? And that's one that I think there's all this debate is why we're up here. So I think it's gonna collide because the hardware vendors need it to collide. And I mean by that, it's if open stack grows in adoption, but if it grows in adoption using white boxes, because you don't need any resilient infrastructure who loses, it's basically gonna be your big storage and networking vendors, right? What they, if open stack's gonna grow to, let's say VMware owns 80% of the market now, right? And open stack got the low percentage. Let's say open stack grows to 40% and VMware shrinks. If those existing open stack implementations are mostly white boxes, that's not good for hardware vendors. Hardware vendors need to be able to say, no matter who wins, we win. And the best way to ensure that happens is to make sure that open stack and has the same requirements that VMware does, which means resilient infrastructure running monolithic applications where the application can handle its own failure. So. That does tie into the operational requirements though. When you talk about deploying open stack as an operator, you run into a situation where it's like, well, what equipment's gonna work with my deployment? Dell, HP, these guys come out of the gate and say, yes, we can certify. Now with Defcore, they can literally go out and start certifying their equipment to say it runs this, this, and this. We have reference architectures this, this, and this. That's what a hardware vendor, that's why you go to Dell or HP as opposed to buying directly from the box manufacturer themselves, is because they do that sort of clean up. They say, here's reference infrastructure that we've tested. I think that's gonna be a selling point, a huge selling point. And that does mirror what VMware tells you. VMware can tell you, these boxes work with us. The rest, untested. Yeah, but if you look at AWS or Google, I mean, obviously they had to build their own, or they work with specific servers, but the key is they just need servers. They don't need all the bells and whistles. They don't need to have, they don't require storage or ways that can do full replication. They don't need, I mean, there's just a number, and networking's the same thing, or any hardware, but they don't need all the bells and whistles underneath the infrastructure. You know, there's also another important one, which is the reason Linux is huge is not because of enterprise adoption, it's because it started being huge in colleges and small areas where sys admins got started when people had time to learn. OpenStack is open source. The ability to deploy this on 20 boxes sitting in a college lab is huge because it means kids get involved. They get incredibly skilled early on in their careers, and then that carries through as they get older and older, they know these solutions, they know they work, and they wanna continue to see them grow. That's how Linux got big. That's how OpenStack could get big, but it needs to be able to still deploy in those 20 machine node infrastructures that have no money. So let me ask this question. So I'm being a very negative one today. I actually think it's okay if OpenStack basically becomes an automated infrastructure. I'm okay with OpenStack not becoming this competitor AWS. In fact, my company actually does a pretty good business helping OpenStack, running OpenStack in very traditional environments. The question I have, I think, that we haven't touched on is given the trajectory where the project is today, can it and should it maintain, try to be both? Should OpenStack be for every cloud platform for every single use case? Because I think that's one of the complaints people have is trying to be everything to everyone. Yeah, you can't be everything for everyone. Everybody knows that you have to focus and be good at one or two things. I think ultimately the market is headed to a place where cloud native applications are the future. Whether that sits in a public cloud or that sits in a private cloud and whether that public cloud runs OpenStack, I think is up for debate. But there's a transitional lag there and so there's revenue that's being spent on VMware today and there's gonna be revenue that's spent on VMware for the next 15, 20 years. And so the question is, can the businesses involved in this space capture enough revenue, focused on solely cloud native implementations to sustain that business model? Or do they have to go and default to these VMware-based implementations to that free VMware, which is a misnomer, but that's the question I think is to be answered. I think there's enough revenue in the cloud native space to support the industry. I think there's enough businesses that are making that transition and they're making that transition fast enough and at an ever-increasing rate that we'll see that transition here very quickly. And that's what we're betting on. So I don't think we need to diverge and support all these high-availability features, but that's our belief, my belief. Yeah, and when we do that, we take away resources from other innovations. So I think we're actually stuck in this place right now. If you look, there is a lot of blueprints out there that add more AWS-type services, but there's a whole lot of blueprints out there that basically, they don't even mask it, they go, we want HA, we want VMotion, and we want DRS in open-stack running KBM, right? So what's the cost of trying to do both? I think the driving force behind the adoption of the elastic design is actually gonna be in the use cases. Hadoop is one of the primary driving forces of elastic design deployment today. I think Mesos is following up as a secondary. I think as we go and the tools develop for making use of software, hardware as a service, I think when that occurs, those tools are gonna drive it more than anything else. Once people start using those tools, people are gonna twiddle with hardware as an infrastructure as a service directly. That's not gonna build. It's when that next layer starts to build out and starts being usable. So that's just my thoughts. You wanna go to questions? Yeah. All right. So we'll just shoot questions out to the audience for right now. How's that sound? All right. Anyone have a question? You can raise your hand. I'll go to the microphone. Anyone? All right. So the question basically boils down to, do you wanna go after cloud native if there's so much more that's not cloud native in the marketplace today? Yeah. So I'm a big believer if it's not broke, don't fix it. And that's what we see. People have an implementation. It's running, it's working on VMware. To go make that migration to a different platform takes so much time, energy, and effort that if there isn't some enormous gain that justifies that expense, they're not gonna do it. And if you compromise the platform to try to get it ready to be able to take those workloads yet they never arrive, now you've got, it's a lose-lose situation. Versus if you focus on those next generation technologies and you are the de facto platform where those land, you're capturing that future workload that I think might actually expand faster than we think. Here's what concerns me is I used to work on a small piece of software called Opsware. And I'm sure all of about three of you in the room remember Opsware, but it was probably the progenitor of cloud. Where is it today? HP still owns it. It still has customers. But what it did is it became very, very enterprise software, very expensive, very hard to deploy. And the problem is it's a community that exists in OpenStack today. You can see it in the commits are moving heavily towards enterprise. How are we going to, when the time, when that point of diminishing returns is achieved, where suddenly going after cloud native is the way to go, how do we stop the momentum of that community? Will the community swing back or will we spiral into non-existence or benign retirement? I don't know. It could take a while. Because of the effort that it was to untangle those tool sets out of their applications, like mission critical, revenue generating applications, it just wasn't worth it. And I think we're going to see the same sort of thing when you talk about the VMware OpenStack fight. Is it worth it to the customer and your point exactly? At least there are not for the driver. Yeah, I'll be honest. I don't see many customers trying to replatform applications from traditional cloud native. And the ones that do it, I haven't seen a lot of success, to be honest. So I think there are two potential risks of trying to go after both traditional and the cloud native at the same time. One is what I said earlier. You have to make design choices, right? If you're gonna make a choice about supporting certain applications, you have to know that it may hinder your ability to support new applications. So how do you balance that? I'm not sure there's a good way to do that. Number two, if we devote a lot of resources trying to support traditional apps, you know, build an HA and all that, instead of trying to build up our cloud native capabilities, the reality is there is starting to be a movement of people who are saying, for cloud native, let's just skip OpenStack completely, right? Because they're stuck trying to do traditional apps. Let's just go straight containers and container management systems and skip OpenStack completely. And I think there's a risk if we divide our attention between those two types of clouds, we may find ourselves get caught in the middle where we don't do either quite particularly well. And basically VM where it continues to own the traditional space. Kubernetes and Mesos and Docker own the cloud native space and OpenStack becomes this very niche player in this very small market that would actually try to use it to do both. It's a big fear. Yeah. All right. I would ask you this, where are all the other public clouds? We were expecting there to be a marketplace of public clouds by now and the reality is, is there's AWS, maybe GCE in terms of the large players and then there's a smattering of small vendors that have come and gone for the most part. Maybe Rackspace, but Azure. Yeah, but very niche use case. I mean, the reality is, is where is that marketplace? SaaS scares me from that respect. You now have a whole bunch of data that's relying on a single vendor. What if that vendor goes under? What if they have a huge problem? The other thing is I've worked through a bunch of large enterprises and do you know some of the largest development shops in the world are not software vendors? It is actually banks. I talked to one, like a top three bank and they've got, I think, 100,000 homegrown applications that they have to support. That's not going on SaaS, right? So there's always gonna be a need for some infrastructure, infrastructure as a service or pass to run these things. The question is gonna be where they're gonna run it in public, private and on which platform? We're out of time, so thanks for joining us today and I appreciate you being here this week. Cheers all.