 Good afternoon, everyone. Thank you all for coming. So, we are going to talk about open stack consumption models and came up with a catchy phrase, good, bad, and the ugly. So, no labels, no judgment. But thank you all for coming. So, I'm going to be moderating this panel today. I figured it's easier to walk around. So, if you have any questions, I can be the micro-runner as well. My name is Ashish Nadkarni. I'm an analyst with IDC. I've been covering open stack for over four years now. So, I've sort of started at the Atlanta summit and this is my sixth summit, I think. So, anyway, thank you again. Either grab something to eat or this is standing between you and lunch. Hopefully, we'll keep this interesting enough. So, when you go to lunch, it'll be worth the wait. All right. So, with that, let me introduce, we have a fascinating panel of folks today. So, let me introduce them. Do you want to go through and introduce yourselves? Sure. My name is V.S. Joshi. I am from this company, Dell EMC. I'm in the emerging technologies team at Dell EMC. And prior to Dell EMC, I had my own startup. And yes, I have had experience with the public cloud and things like that. But currently, I'm with Dell EMC and I'll be talking about open stack consumption models. Great. Thank you. I'm not James Page, as per the description. I'm Mark Baker. James was unable to make it, sadly. So, I'm the open stack product manager at Canonical. Also branded. You'll see three of us branded. So, and I also sit on the open stack board. So, I'm our representative on the board. And I sit on the product working group and a couple of other things too. So, very good. Hi, everyone. Kamish Pamaraju with Marantis. Branded as well. We're all branded. So, long time in the community, about six years, this is my 10th consecutive summit. And being with Marantis for about two years, I run marketing and technology alliances there. And prior to that, I was with Dell. So, very familiar with all the Dell open stack solutions prior to that as well. Thank you, guys. And I'm your unbranded moderator. So, I'm going to make this interactive. So, questions anytime during the panel are welcome. I have some questions here just to get the conversation started. I'd like to keep this conversational. So, if you feel that you need to ask a question, don't wait till the end. You know, let's have a conversation. The folks at the back, if you guys want to move up in the front, I think the room is a little too big for us, but move up if you want. All right. So, yes, as the, as Dell EMC being the newest kid on the block, if they say that, or if there are a lot to say that, why don't you sort of kick this off by giving us a lay of the land as how you saw it or how EMC saw it as it walked into this field. Okay. So, I mean, so first of all, we're talking about the private consumption models or the private cloud consumption models as far as open stack is concerned. Now, at a very high level, the way to look at it is that there are a couple of models. One, the most hands off model is that of a managed cloud service provider. That's the most hands off approach. Yeah. And in that hands off approach, there is somebody else that is creating the cloud that is somebody else managing the cloud, supporting the cloud. And you as consumers, you essentially have just what can be called as a domain operator at your end that is managing the creating the users, creating the quotas and managing the cost and the relationship between the cloud service provider and your employees and things like that. So, that is the most hands off approach, managed cloud. We would like to say that immediately after that is the turnkey system model or the appliance model. And in the appliance model, essentially, yes, you do have the domain operator. And you also have a very low skilled cloud operators. Yeah. And then I would say the third model would be the distribution model, the distro model from Red Hat and from Canonical. Again, let them speak about it. But I think that there is where you might need in addition to having the domain operator, the cloud operator, you also need a cloud architect. And the final is the do it yourself model where essentially you need the whole thing. Plus, you also need the engineering support and those kind of things. Again, all these functions that I talk about, like domain operator, cloud operator, cloud architect, and the engineering support, all these things can be done by one person also. But again, I just want to put them in these various buckets or so. So I think that I would say at a very high level just to get the discussion started, I would say those are the four models and I'd add a fifth, actually, of course, which is public cloud. So it's very indeed, you know, for early Opus Stack and still today, a great deal of people consuming Opus Stack services through public clouds, whether it's Rackspace, OVH, or whoever. So it's not obviously a non premises, but it's another model of consumption. I was just talking about the private cloud model. Yes, absolutely. Yes. So why should anyone even bother about consuming anything other than the public cloud? You know, I mean, I'm being controversial in the sense that I believe that the the software. So our CMO Boris Rensky has been has famously said about a month ago, he wrote a blog saying that infrastructure software is dead. Nobody wants to consume software at at large scale anymore. It's it's the the model that VS was talking about at the end of the day, you want the Amazon like experience, whether it is private public, it doesn't matter. At the end of the day, it's the user that that's having that experience, it needs to be seamless. So we can talk more about it. But I wanted to start with that kind of a starting point. I think that that's really a challenge of operations, though. So it's not that you don't want to consume software. You want to absolutely use software. It's just that operating large complex technical projects like open stack can be complex. Whilst the cost of acquisition, because it's open source software can be very low. The cost of operations can be can be high. And it's that that people are looking to try and remove that cost or at least minimize that cost. Yeah, that's an excellent segment or so thank you for the introduction, folks. It's a great segue into our next sort of question is into the types of customers that would be naturally, you know, inclined to go with one or the other. And so in your experience, what kinds of customers come to you or or you are able to, you know, sort of appeal to them your your solution. So come in. So some very large open stack users, you know, with, I'd say, more than 5000 nodes. And we have done cost models. We've done cost models for DIY for distributions and for manage services. And you know, some of the largest telcos in the world started off with DIY. Because they find, you know, that at their scale, with hundreds of data centers and tens of thousands of nodes, having an in house team with the expertise and and all the, you know, source code access and all that stuff actually works for them. Over time, though, what ended up happening, I'll give you an example. I can't name customers, but one of our customers ended up what we've fondly called Frankenstein clouds. So they ended up doing, you know, they had 100 data centers and every data center had a different cloud. One was running Liberty. Another one was running kilo. Another one was running something else. And all the versions were all over the place. And they ran into this maintenance nightmare, if you will, right? So then they said, look, we're spending way too much time on maintaining these different clouds. How do we get this out of this Frankenstein cloud mode and kind of have a standardized, you know, software that's kind of distributed and working everywhere? So large customers start out that way. They're thinking they can do it. But ultimately, they need standards and standard software that can be deployed across the board. So that's one example I just wanted to throw out. This I think, I mean, it follows most many technologies. Many technologies follow the same path, right? Where at the beginning of that project, the early adopters are doing a lot of the heavy lifting, the engineering themselves, creating very bespoke environments. And then it goes through a very typical life cycle over time, where it becomes more productized, the kind of early majority start coming into and companies, distributions ourselves and others come in and start to productize that, all the way through to full kind of utility commodity. An open stack is on the same journey. Linux follow the same journey, database technologies follow the same journey and open stack is on the same journey too. So a lot of the super users and we love them, Walmart, AT&T and all these kind of people that are using open stack today, they were the people that were taking the arrows. It's the people further down the line that get the corners. I think this is very, very fascinating. It's fascinating to see the age-old technology adoption life cycle of innovators, the early majority, the early adopters, early majority, late majority and legards. And we are at that stage, open stack is six years old. And yes, we have come to that, as Jeffrey Moore calls it, the chasm, right? And we are at that stage of crossing the chasm as such. And this is where I feel that, yes, the people who are enthusiasts, technology enthusiasts and things like that, yes, they have tried these things, they have taken the arrows and things like that, they have learned from their experience and things like that. And now it is for companies like ours, maybe IBM, HP, Dell, to essentially take this technology and make it more adaptable for the masses, for the early majority and the late majority. I think we are a very interesting phase of this whole open stack journey. And at six years old, I do feel that, yes, we are at that whole, the chasm thing right now at the point. So I'd like to ask a question of the audience, how many people have open stack today deployed? And how many of you have it in production? Wow. And so I think for the folks who don't have open stack, I think what would be the one thing that you would want to tell them that they are here at the summit? What would they be interested in knowing from you as a sort of provider of an open stack solution? Mark, do you want to go first? Sure, sure. So having been involved in open stack since day one, we recognize that there's no one size fits all. So whilst we produce an open stack distribution, extremely popular distribution, it's not necessarily the fit for everybody. So we worked with public cloud providers to build that public cloud infrastructure based on open stack that end users can consume. We also have a fully managed service, for example, BoopStack, Build, Operate Transfer Stack we've had for a couple of years. And that is a model where we will manage the cloud but then hand the cloud over basically give the keys to the car as it were to the users once they're good. And that was initially launched actually to overcome the skills gap problem, right? This was one of the issues. You know, I guess everybody that's running open stack here is probably be hiring. And it's overcome that skills gap. We can build standard cloud up, we can manage it, we get it running, but when the users feel comfortable to take it over themselves, they can do that. And we have customers that operate across all of that spectrum, including some very large customers, doing several thousand nodes that we are managing to a to an agreed SLA. So we see across the broad spectrum. So the question is, what would you want folks? Okay, so for all the people, you know, I think if in case you get a chance, see the video recording of yesterday's session, there was a session called broken stack. And it was in the evening and it was they were talking about people who have started to implement open stack and they took three use cases and how they failed in that particular thing. And again, they were just trying to impart the lessons that they have learned. So if in case you get a chance, do see that open the broken stack session from yesterday. Today morning, there was a session and in that session, the person clearly articulated what was the difference of going for Amazon cloud versus private open stack cloud and the cost differences they have done the entire they took a configuration for a particular configuration. If they would go with AWS, what would be the cost and if they would go with private open stack cloud, what would be the cost and the I'm now a surprise to see the difference in numbers open stack private cloud was literally one fourth the cost of AWS. So again, yes, open stack, definitely go for open stack. But at the same time, remember, there are a lot of people who have had these experiences. So I strongly believe that yes, taking advantage of players like Mirantis and Canonical and Dell is absolutely essential, I would say for again, if you if you are looking for a tremendous amount of customization and things like that, and that is the core of your operation, that is the core of your business, then I do understand the do it yourself approach. But if that is not the case, I would say that you know, taking advantage of these vendors who are essentially adding that extra muscle. And you know, you don't have to do it by yourself. If that's what I would say, that's a great point. And Kamish, what would you tell your prospects? So the biggest problem with OpenStack is not deployment anymore. So that problem is solved. Initially, it was all about, oh, it's very complex, I can't get it up and running. Building is not an issue anymore. The problem is operations, as he pointed out earlier. How do you operate? So what do I mean by operations? Things like upgrades, updates, you know, getting your patches done, your security standard stuff that you guys are used to in a VMware environment, or a Microsoft environment, and there's tooling available for that. Now in OpenStack, it's not quite there. How do you monitor all of your apps? How do you monitor infrastructure? There are tools out there, but you can't really get a holistic operations environment running. So if you're running a thousand node cloud, guess what's going to happen? Every day, every second, something's going down. So how do you manage that? That's the operations piece that I think the community is starting to address now. But that's a challenge you have to keep in mind as you go and start building larger and larger clouds with OpenStack. So we're starting to help that with managed services. So for companies that don't know how to do that, we call it LCM, or Lifecycle Management. So upgrade from one version to another version is an example of that. Things are going down all the time. How do you monitor those things? How do you bring things up? At the end of the day, as an infrastructure operator for your cloud, you have to provide a certain SLA to your end users. So one of the biggest failures that we see with many of our customers is what we call the, we call it the orphan cloud syndrome. Orphan cloud. So these, you know, they start off very enthusiastically. They come to us. We build a cloud. It's maybe 50 nodes. We start off with that. Great. And then after six months, they come back and say, oh, we don't have any tenants. Nobody's coming on board. What's going on? And then it turns out there's an SLA issue. Developers try to use it. It doesn't work. So that problem has to be solved. And it's not just a technology problem. It's also a cultural process problem. Thank you. Any questions in the audience? So while we're talking about the readiness, the operations challenges, I'd like to ask a question of you folks who have had OpenStack deployed, who wants to offer to list out some of the challenges that you've had. Anyone? I'll run the mic for you. You have to raise your hand. Oh, there you are. Thank you for sharing your thoughts. My reading, the main challenge as of today for somebody that is approaching OpenStack for the first time is to decide between the distros or going vanilla. And by choosing a distro, once you have your workload running and going, despite of the keynote that we have with the interoperability, it's like a marriage, meaning you're going to have to revamp your entire network. Some of the services you are able to move, but it's like a marriage. You have to make sure that you're choosing the right partner. And I say that by experience. I won't name collars, rats, or... And we are moving away from one distro because of many issues. And this is a very tough thing to do. Thank you. That's a great insight. And if you don't mind, what kind of business is your forming? I work for a big telco in Brazil. Thank you. So I'd like to throw back the question to the panel. How do you address this challenge with distro? Is that a concern? Is that a question? So it's only one of the big concerns we see with users is around lock-in, right? They want to ensure that they're choosing a technology that is going to or a partner that's going to give them options in the future that they're not going to feel that they are locked into. Standardization, the interrupt demo, for example, is one way to be able to do that. But being able to take a workload and drop that into any cloud, any OpusStack cloud, I should say, irrespective of the distribution, it's more than just a set of common templates, right? There's all sorts of commercial things that need to be in place and support agreements and things like that. To some degree, as Asian Cockroft at AWS asked, I think, at one of the OpusStack Silicon Valley, who wants to avoid lock-in, everyone puts their hand up, who's married, right? And so everybody is prepared to accept a degree of lock-in in their environment. It's just where that dial lies and the amount that you're prepared to kind of stay. So clearly differences lie between distributions. We want to be able to differentiate. You're good at X. We're good at Y. You're good at B. But can the customer, let's say, for example, the customer goes with one particular distro, I mean, I will counter that lock-in argument by saying that, yes, they can move to the other distro. They can move to the other vendor for support. Is that a very easy transfer to make or no? Not really. As he was pointing out, all these distros are different. Underlying distros are the way they're tested, the way they're packaged, the way they're deployed. Varantis has a tool called Fuel. Red Hat has their own and Canonical has their own. They use Juju. We use something else. So once you are in that stack, you're pretty much locked in. Let's face it. I mean, there's no two ways around it. Now, can your workloads run on top? Sure. I mean, that's what the interoperability is all about. I mean, as long as you're keeping your APIs, OpenStack API standard and that's what you're using, in theory, your workloads should be able to migrate them. But if you want to change the distro, believe me, that's going to be a tough one. And be supported. I mean, that's the whole point of a distro. You're getting a distro because you want support for a vendor. And if you want to switch, then you're basically locked in. Now, that being said, at Morantis, we have been very, very focused on being agnostic and as open source as possible. Every other vendors, of course, are also open source. But we have branded ourselves as what we call pure play, meaning we're as close to the trunk as possible and all that. And we keep an open ecosystem of partners that we can integrate with, et cetera. So that being said, if you're using fuel, then you're pretty much locked into fuel. So how you deploy, how you configure, what networking you use underneath, all those things are tying you down. So but once you make those choices, you're locked in. Our value proposition is you have a vast array of choices you can make with Morantis. I think it's understanding the degree of lock-in. So understanding you're making a constant decision, I'm going to go with this vendor or this vendor or this vendor and understand this will be the cost of exit if I want to change. So it's just knowing that, right? Doesn't mean you have to completely avoid it because there's all sorts of other issues like support, as you say, you're dealing with. But recognizing that they exist, just being open source is not the kind of get-out jail-free card that many people may think it is. So just understand the risks. Unless you're doing your DIY throughout, right? And then you can go just trunk and do everything yourself. But again, that has its cons as well, right? When it breaks, it's very hard. When it breaks, you get to keep all the pieces. So, yes, Dell has taken a rather unique or sort of a different approach in the situation. Would you want to talk about the pros and cons of, you know, delivering it as a packaged, fully packaged appliances, in this case, sort of not worrying about the distro, if you will, or is there a challenge to be addressed there? OK, so again, considering the fact that Dell and EMC, legacy EMC, we address the enterprise marketplace as such, right? We are trying to take the technology and trying to make it consumable by a massive amount of customers, by make it widely adoptable and widely used by lots of enterprises as such, yeah? So because of that, I do feel that, yes, when you go, I mean, as compared to distro, again, in a distro also, and please correct me, Karmish and yourself, I do feel that, yes, there is a role for a cloud architect to play in a distro where the person has to decide which hardware, which software, what cloud configuration, what kind of service am I going to provide to my consumers? The storage, whether it is network, whether it is compute or database as a service. So those are the decisions that the customer has to take in case of a distro. Whereas in an appliance model, we don't, we have kind of limited those choices. We are saying, OK, we have a certain point of view. We have gone through all these things and we have put this hardware and this software and this networking and this, we have put all these things together and now you focus only on the applications part of it. And that is where I would like to differ from a distro as such, yeah? But otherwise, again, I do feel more than we competing with each other, we fall in the same bracket as opposed to DIY versus a public cloud, I would say. So the downside of it, so we have done, we had done HAD because we have stopped doing appliances. We had an appliance program at Marantis too. What we found, and again, I don't know, VS, maybe your, your experience is different. What we found is, many of our customers, we go with an appliance. So here it is, all preconfigured, ready to go, plug it in and you're ready to go with your workloads. And invariably, I'd say 99.95% of the time, they'll come back and say, I want to change that. I want this networking, I have some other server there, this storage, use case, that or this or that. Then all of a sudden, you're no longer in the box. Now, now you're doing architecture. You're saying, okay, you want this, let's start with this appliance. We're gonna change this, this and this. And I want it in 10 different data centers with this much scale, then all of a sudden you're back to the distro. So what we found, it is our experience in Mantis, is that wasn't very, it wasn't flying for us. Nobody was buying appliances. At the end of the day, they were buying distros and they were buying our services to go build out a cloud. So that brings up a question and I think UAS, you talked about this earlier. How many people, how many customers when they come to you have that sort of total cost of ownership, mind frame? How many people like think about what is it that I'm trying to do here and is cost one of the main reasons? And if so, how do I go about measuring costs? Is it just the direct CAPEX costs or people costs? That kind of so. So most of the customers who come to us are essentially customers who have tried to do it yourself model. They tried to do it yourself model six months down the line. They have still trying it and things like that. And they have kind of failed as such. And yes, at that point in time, they have said, let's try to explore other opportunities. We have had customers, again a big software conglomerate in India. We have had a big retail giant in the US. They have deployed our appliance in their environment. And yes, it has started working within a week or so. So I think we have had that again. I do understand where Karmesh is coming from and where why he would say that, yes, there are some customized challenges that we will face when it comes to appliance. But yes, we are targeting a specific profile of customers wherein we are able to get into the customer and come up with a pre-packaged, pre-validated stuff. So I think. An appliance, I think, is really, again, it's trying to address that issue of operations. So somebody else has gives you a rigid architecture. Don't deviate from that architecture if you can help it. And the tools and other pieces packaged to do operations. But I think that's one way of addressing it. Another way, you know, open stack open source is very good collaborating between developers or facilitating collaboration between developers to create code. But the thing that it's only now really starting to recognize and certainly it's a flag that we're bearing right now is collaborating on operations, right? So everybody has their own puppet scripts or their own chef scripts or whatever it is. But there is best practice on how to back up an open stack environment, how to upgrade an open stack environment, how to pause, resume, et cetera. And a lot of the stuff that we're doing with Juju and the charms that we have is how do we codify that such that everybody in this room can input into that to be able to share that common best practice. Because in doing so, we're sharing the cost of operations across the entire audience. That's a very key point, actually. I think that is where the challenge is with any open stack cloud you may be building. Ultimately, it's all about orchestration at a higher level, across multiple clouds, across multiple availability zones, across data centers. And once we solve that problem, you don't have to have a specific tool, but it's really all about what are the best practices for ops? And as a community, if we come together and solve that problem, I don't know if there are committees or something, but eventually we need something that'll kind of build those templates if you will, right? And then you can use different tools. You can use to pop it. You can use Juju or whatever. But then you can implement them and run ops because I think that's a key challenge still. And open stack gets compared with Linux. So in this sort of sentiment, how can the open stack community learn from some of the stuff that has happened in the Linux community or even Apache and other places? So I don't buy the argument that open stack is Linux. Linux is to one thing. Yeah, but if you think about it, right? Linux is a single server. You need an admin for that server. You can deploy it and you're done. I mean, here we're talking about large scale clouds. And it's a very different ball game and a very different beast you're dealing with, right? So it's orchestration, it's ops. Of course it's all running on Linux boxes at the end of the day, but it's, you have to look, take one step higher. There's certainly comparison points. So Linux is a collection of very many different packages or technologies that have to be integrated, tested together. They have to be supportable for customers that require that. They have to be robust and resilient. And there are certainly things that the open stack community can learn, continues to learn from that environment. Obviously a lot of us are involved deeply in Linux anyway. So in terms of being able to create a consumable platform for people, but absolutely right, it's additional layers of complexity. People have called the open stack as the operating system of the data center, right? Actually so because that's what it's meant to be, right? You can kind of use it as an operating system, but it's long time, long ways away from there. They've come a long way in the last six months, last six years, but I think we have a longer way to go on the ops side. So any questions from the audience? Anyone? So we have around 10 minutes left and I'd like to switch gears and talk about workloads. And at this summit we have a lot of focus on NFV. Last time it was all about IoT. I'd like to sort of pose the question on what type of workloads do you typically see your customers deploy and why? And we have this discussion around traditional workloads, cloud-enabled workloads, and then cloud-native workloads. And people call them on any given day different names, but you get the idea. So I just wanted to sort of ask you, and yes, maybe we can start with you. You had a startup, you had a bunch of apps that were written cloud-native, if you will. How do you see open stack helping or not helping and the model, the consumption model with these apps? So I think the way we have positioned ourselves is, okay, this is an infrastructure for your cloud-native apps. For whenever it is cloud-native apps, we kind of are going ahead with open stack. Not only that, we also have, we are providing this infrastructure as a service to all the app developers and things like that. In addition to that, the Pivotal Cloud Foundry, the PAS platform is, for the PAS platform also, this neutrino VXLAC, sorry, not supposed to be doing a product mission, but our product can act as an infrastructure as a service for the PAS layer also. So essentially the cloud-native apps, that is the main, that is the biggest workload that we see, that is the biggest focus area for us. And then what about use cases? Any particular, you know, industry specific apps or? No, see the thing is we are, again, we are at a very initial phase of the whole thing and we are still in the stage of trying to find out the right marketplace, the right profile of a customer and things like that. So we launched our product only two months back, so we are in the whole process. Yes, we have lots of deployments all over the place, but we are into that whole process at this point in time. So I'd say successful clouds, certainly in the enterprise or organizational space and we'll put NFB to one side for a second, successful clouds will trend to generality. So it'll be a general purpose cloud that will consume most if not all workloads, right? So we see signs of successful clouds are that they continue to grow and they get more and more workloads and they can be very diverse, web workloads, databases, analytics, whatever. NFB is a slightly different, we have many NFB customers. It's a slightly different use case because they have VNFs, which is fancy telco speak for an app. And, but they're very network centric applications and performance and throughput are very important. We still think there's a very strong argument about having a common layer as the underpinning without sort of tuning, really fine tuning it per VNF because then you're creating these hot spots of complexity. But they're different in their makeup to that sort of general purpose organizational enterprise clouds. I tend to agree with that. I think although OpenStack originally started off as a cloud native platform, there's an interesting story I can share with you. I live in Silicon Valley and I have a lot of friends who start companies. So there's a guy, an old friend of mine who worked at Microsoft Azure and he's a serial entrepreneur. So after he sold his company to Microsoft, he came back and he started a new company and I happened to meet him over coffee a couple of weeks ago and asked, hey, what are you up to now? And he said, hey, I'm building this cloud for legacy workloads. I said, what do you mean? Oh, yeah, all these people soft and SAP and databases, SQL. I said, really? I mean, that's not what the cloud is for. But he said that 80% of the customers he was talking to when he was back in Microsoft wanted to put those workloads on the cloud. But Azure, these guys at Azure said, no, no, no, no, that's not the right place. You know, we're not gonna, so no SLAs for that kind of stuff. So he started this company. So I think OpenStack, just by virtue of all the work that's going on is perfect for that mixed general workload type of environment. You can run cloud native apps. You can run container apps. You can run legacy apps if you want to. Of course, you know, you gotta look at the reliability of the infrastructure, et cetera. But I think it's the way OpenStack, the way it has evolved over the last several years is it's perfect for a general-purpose workload. One of the challenges, I mean, you say many legacy apps will run just fine in an upper stack environment. There we see challenges. There are some technology challenges depending on the app, but actually there's a great deal of licensing or commercial challenges, which is what puts people off. Moving a database, I won't name a database vendor, but moving a database vendor from a single on bare metal machine into a cloud can suddenly get very expensive. So those are considerations that people have to live with. Cool, okay. Any questions? Coming up on the final five minutes, any questions? Oh, sure, yeah. What would you say is the, is there much? Mike coming up, Mike coming up. Hello? Yeah. What is the toughest challenge? Why is it so difficult to operate a do-it-yourself cluster compared to your solutions? So a certain amount of that comes from the community is developing capabilities and features, and a lot of that focus and development has been around how can we make an open stack environment compare well to an Amazon or an Azure or a Google, right? We want to be able to, or even a VMware type of environment, how can we provide those capabilities? It's very feature-driven. You don't really work out what the operational challenges are until people really start operating it themselves for real, right? And that's when you started like, okay, how do I really manage backups? If I need to be able to perform maintenance on a node, how do I really evacuate all of those things in a clean way and do it in an automated way? And so it's a learning journey, right? If you have a vendor, a vendor's, we have product managers and product people that will try and look down this and figure it out. OpenStack, whilst it has a product working group, doesn't have product managers that are saying, are identifying these pockets. Yes, there are companies, all three of the companies up here contributing to OpenStack and working on there, but there's no sort of single person responsible for setting that agenda. I think you have to look at the whole open source movement as such. I mean, this is something I was told by a person who's a leader in the open source. He says that people get into open source, they are very enthusiastic about it, and they jump into it, and they start developing the software and things like that. They get a high of kind of coming up with the software. And yes, they take the software up to 90% of where it has to be. And that is where they get a tremendous amount of satisfaction. The last mile or the last 10% is where they move on to something else. And then it is left for the, and again, when you as consumers of that open source project, when you take that, you are dealt with that remaining 10%. The challenges of that last 10% which was not done by the software developers per se. And this is where the rubber hits the road. That is where you kind of have the challenges. So that's what he said, the operational challenges. Because yes, that thing has not been tested for each and every use case. That thing has not been tested for each and every configuration that you might be having and things like that. So that is where I would say that, and that's why we have Red Hat as a successful company over there, though the open source is there for a long time. And I feel that that is one big aspect of it. And then yes, all the things like, and if you look at what the distros provide is the engineering support, the packaging, the bug fixing, the testing and all those kind of things. They do those things. That's our differentiation, actually. How we differentiate between each other is they have a great way of doing things. We have a great way of doing things. You have a great way of doing things. You as an end user. So I'll give an example. So one of our largest telco customers started off with doing their own stuff, right? Using Trunk. At one point, they had 300 plus developers that were doing, you know, they took code from the Trunk and they deployed it and they ran it. They had all these Frankenstein clouds all over the place. What they found out after about a year was 200 of those developers were fixing bugs in OpenStack Trunk. They were fixing bugs that wasn't adding business value to their applications. So they said, why are we doing this? Why are 200 of our developers fixing things that these distro guys are gonna fix anyway? Because that's their job. Let's focus on what's value add for us and put those developers to better use. So they ended up using a distribution and they freed up all those guys. And the distribution company, of course, is responsible for fixing the bugs and making sure it's supported. So that was their logic, right? From a financial standpoint, from a value add standpoint, they moved from DIY to distribution. Yeah, this is not a new model. People in the 70s, big companies in the 70s used to write their own databases and then they found there was a better way of consuming database technology. Likewise with Linux, it's the same with OpenStack. We have one question here. So I'm working for one of the biggest hosting companies in the world. One of the things we're looking at right now and we kind of foresee it in the future is that a big competition to OpenStack, not today, but maybe one, two, three years down the road would be Kubernetes. I know today there's a lot of talk in this summit that you can run Kubernetes within OpenStack but we kind of see Kubernetes coming in from behind and offering somewhat similar services or alternative running workloads. I was curious how you see that. So you have to, I mean it's like VMs versus containers. At the end of the day, your VMs are not disappearing. Your existing workloads all run on VMs. So you have the whole effort of moving those VMs and contain microservice, creating microservices out of them and then running it on containers. So there's a migration effort involved and cost involved. Just like you would move bare metal workloads to VMs, the same sort of effort. So there's a lot of existing workloads that will continue to run on VMs. There are, I think it's also important to say Kubernetes is very focused around process containers or Docker containers, right? So if you're going to create 12-factor apps and re-architect into microservices and all of those things that the cool kids do, great, that's gonna be an option for you. But a great many applications are not ready to be 12-factor and microservices. You may want to take a VM and stick it in a general-purpose machine container like LXD container and that's gonna be a lot less heavy lifting but whilst lots of cool kids talk about these microservices, you know, the reality is it's still a little way off. And Kubernetes is kind of sort of like OpenStack five years ago, right? I mean, they just started, the foundation was started like six months back. Yeah, they've got some. So give them some time. I mean, it's not like it's ready for production, prime time, large scale clouds yet. I mean, that's the reality of it. So we are almost out of time, couple of things before I hand over to the last question. I believe Dell EMC is doing a raffle and so after this, feel free to pick up our raffle thing and give me a... Winner appliance? Yeah. Yeah, yeah. We got a free appliance. Yeah. Actually, we do have... We do have an appliance as they say. By the way, we do have an OpenStack appliance on the floor of the, and please have a look at it. It's a running appliance that is going on over there. So question. Actually, I was just disagreed with you, Kamash, a little bit. When it comes to going on yourself, going vanilla, totally vanilla, it won't mean that you're gonna be in the wild by yourself. You have the community. Sure, yeah. The fixes come. What you ain't gonna have is somebody to cover your ass, basically. Meaning you're gonna have to be very aware of the challenges and tough to fix stuff by yourself if they are needed. Otherwise, the community will be there. That's for sure. The question you were asking, I think, is kind of one of the key questions in OpenStack right now, is OpenStack a product or is it a group of projects that are turned into products by people like us? And so it's kind of, that's still yet to really play out, I think. So it's not just the code, right? Again, I'll go back to ops. I'll go back to configurations. I mean, you have to still do all that stuff, right? I mean, most distro companies, these guys have juju, we have fuel. So we make it easy for you to kind of get it all up and running. So that's a value add as well. You're right.