 Okay. Thanks everyone for joining. My name is Aizmahir Mohammed and we've got a panel here of distinguished guests talk about how to select an open stack distribution that's right for you. I'm going to do the introductions because otherwise it will take forever just to get through the panel. So I've got Nick Barsett from Red Hat. I've got Sandit Singh from Piston. I've got Ronan Kaufman from Maranthus. Seth Fox from Selenia. Justin Shepard from Rack Space and Mark Williams from Red Hat. And our goal today, if you guys get tired and hungry, is to make this really like a fight between the distros. But hopefully what we're going to do is be more educational about how to select the distro for you and tap into, I'd say, my guess is that there's 20 years of open stack experience here that we can actually give you a lot of guidance around how we got here. But before we get into the distros, I wanted to start with Mark and Seth because these guys deal with customers of all types, ones that choose distros and don't choose distros. Just start with which customers should not use an open stack distro because I don't think this is a foregone conclusion they will. Mark? Customers that don't know what their workload is should not even start down this path. That's the number one kind of experience and most common experience unfortunately with customers that they come to us. So Red Hat is a systems integrator. We are a trusted advisor to help them find the right solution for their problem. If you don't know what your problem is that you're trying to solve with open stack, you shouldn't go start building a cloud because you can't make the informed decisions about which distribution to pick and which of the six million configuration options you should make to make this work for you. I think Mark's absolutely right. If you're not sure what you're going to do, then you've got to figure that out first for sure. We do have, Selenia is also a trusted advisor in the space and work with customers from choosing a distro down through even DevOps and process migration as well. So determining what that plan is, we have had a customer that came to us and they did not want to use a distro. They had a specific skill set in-house. They were entirely an open source shop and did everything themselves. They used lots of other open source products that are packaged that way with support and maintenance and they chose not to do that. They had very strong skills in house to be able to do that and they wanted to commit to the project. But primarily our recommendations with customers is let's find a distribution that you can work with, especially in the enterprise space and work with them to help pick the distribution that's going to meet their specific needs for their workloads. All right. I want to get a show of hands. Who in the audience has already chosen an open stack distribution? Okay, great. And who's still in the process of evaluating? All right. And then who not even on the journey yet is really still researching? All right. Okay, so good. So we've got an even split. So I don't want to make this like a, I want to tune it for the audience. So I want to open it up to the distro partners, right? How about you guys, right? Are there customers that have come to you and say, yeah, you know what? You guys are not a fit for our distro. Yeah. Well, the question is what's a distro, right? In the terms that everybody think about the Linux model that you download set of bits, you deploy them really easy and then you call somebody to support you. And open stack, you know, for many use cases, just not the right maturity level to be at that point. And so when you look at distro, you look at somebody to partner with you to come in to help you deploy open stack, provide the bits, but provides much more than that. So there are very few that could maintain their own open stack across the board. And you know, when you get to a certain scale, who will help you at that point? So I think choosing a distro or working with somebody who has a distro down the line is always something you need to look at, like the early days of Linux, start on your own. But at some point, you want to deal with your business and not fixing Nova schedule issues. Yeah, I think that's key. I think what I've seen is around support, right? You know, not all of us have a DevOps team that you can leverage. Not of us. Our core condom's competency is open stack. It's running your business. And so there are time, they reach the point of time when you've already decided, you've already understood and you just want somebody else to go deal with that, right? Because you have to focus on something else. But want to get more opinions here. The other thing I'll just add to what was already been said is you need to look within the organization and see what kind of talent, what kind of people you have. If you have really large teams of infrastructure specialists, open source geeks who really like to go and do this and build the infrastructure for you, you probably don't need a distro. So that's a decision and that's a tension that needs to be also put. So I think a distro needs to offer more than just open stack. Open stack is a layer above many things. And if you are expecting full service from a provider, you need to have people that are able to help you all the way down, all the way down to all the function that are needed within Linux to make open stack operational. And you need more than that. You need an ecosystem because below the software there is metal. And this metal, you need to make sure that it is operational. And you need even more than that. You need an ecosystem with partners for what is below, but for what is above. And I think the key aspect is that it's basically five things you're looking for. Somebody that knows open stack, somebody that knows a component underneath open stack that can fix them, that can add functionality to them when needed. Somebody that has a hardware ecosystem and an ecosystem of partners that can deliver all the functions around open stack. So I used to work with Oracle before and that's exactly what we were saying then. Yeah. All right, let's move on. Let's get into some details here. I'm going to ask Justin first. Just give a quick overview. I arbitrarily chose 120 seconds to talk about the distro for your company, the version, reference architect, junior attributes. What would you say to a customer that just came to you and said, hey, tell me about, you know, Rackspace 10? Yeah, absolutely. I mean, to touch on some of the things. So we do, we have a kilo coming out. I'm not kilo coming out. We just have kilo right this second. But just a little space. Can you put this one back? Yeah, sure. No, that's all right. It's all right. So current version, our big thing is being your operating partner. And so while there is technology underneath that, we're really looking to be that operating partner for you to run your cloud for you, so that you're able to kind of look at your resources inside your business and figure out what you can use for the cloud journey and put them where they make the most sense. So operating a cloud doesn't often fall into making a lot of sense for you. You want your teams doing the transformative work on the applications, be able to migrate those workloads into cloud-enabled platforms. And so we'd like you to be able to spend your time there and not have to worry underneath. So that's really where we sit in. And yes, we have our OpenStack bits as well, and we're able to offer SLAs on top of that. But fundamentally, it's around that operating partner. Yeah. So you guys use, I know you guys use Ansible. That's the automation. Yeah, so it's the OpenStack Ansible Deployments and Stackforge project, which there's been a couple of talks around that, and that's really our deployment package. We put that out there and created a community much like fuel around it to get traction and lots of people contribute to it. And so that's really our platform, but we're able to run that cloud for you. And then reference architecture, controllers running active, active, active. Yeah, so we do a three-node control plane that we use, Galera MariaDB for WSRAP replication. We use a clustered rabbit. We do HA through load balancing of all the stateless APIs. We've got compute nodes and center nodes and all the normal reference architecture that goes on to the side of that. But that three-node control plane is really where we're able to spend a lot of the time to make sure that OpenStack stays up and is stable for you. Okay. Anything else? Okay. Well, let's move on to Ronin to talk about Maranthus OpenStack. Anything you want to highlight this unique that's... Well, we try to make OpenStack a very simple thing. Easy to install and operate at scale. It starts from the deployer, then it continues to how you deploy it, how you operate it at scale, the very rigorous testing at a large scale. Because, you know, we have a lot of customers that are 15-node clouds. You can pretty much get by with whatever you have. When you get to 100, 200, 300, and beyond, it's a different game. So Maranthus tries to really focus on those high-end requirements, large deployments. And the other big thing about Maranthus is that we don't try to tie you to a single stack, top to bottom. We're actually exactly the opposite. We try to give you some freedom of choice as the pure play approach. And it's harder to do because it's much easier to lock you into a specific set of things, but it's much harder to get out of that down the line. So Maranthus invests a ton in making sure that you can operate with every, almost, network choice that you have operating system and also give you the choice of pass, you know, if it's, you know, Cloud Foundry or any other things. And we would love to support OpenShift as well, if RedHead will agree to that. So we are all about giving choice and making sure it's easy to operate, easy to install. And that's what our customer loves. That's why they come in the door. Sandeep, how about you talk about Piston? So Piston, because of our heritage and the team that we had over the last three, four years, built this awesome piece of software that made it very easy to deploy OpenStack on commodity bare metal. Right? So recently what we did was we took that and called it Cloud OS. And because other frameworks and services also need this capability, we expanded to Kubernetes, Docker, Hadoop, and in Spark, essentially, we are, I know this is an overused term, but I'll still say it, the operating system for the data center, essentially, making it very easy and simple to deploy all these frameworks on commodity bare metal. Now, when it comes to OpenStack distribution, we fundamentally believe until now what we've tried to do with that distribution is provide a curated version of OpenStack because our customers are really people that are looking for that easy button. A simple way and also that do not want too much customization, right? So those are our customers and we've built a product to cater to that kind of need. Nick, how about you? So we have a distribution that is, first of all, all about the choices, choices in the component with which you're going to be able to integrate with, whether they are at the network level, at the storage level, at the hardware level. But we also have a distribution that is trying to listen to the requirements of our customer. And this is a very key point. We make OpenStack evolve very quickly and we invest a lot based on the requirement that our customers are giving us. For example, we now support three different HA models. To fit the needs of the different typical use case we're finding on the market. We are also defining reference architectures with specific hardware vendor to fit the market that they are trying to address. We are also defining OpenStack or our OpenStack distribution in its way, it's not only deploying OpenStack but caring about OpenStack throughout its life cycle, including managing updates and upgrades, including providing the tool the operator needs to operate it, debug it, verify its performance. And this is a vision that we have. We should be delivering something that is complete yet pluggable. Pluggable because people can decide to use such tool and not this one. And this is a level of freedom that we provide. Yeah, Seth and Mark, what's the reality on the ground? What are you hearing from customers around the distros and how they're choosing? Yeah, so one of the things that I wanted to add is there's a ton of choices when you look at the distributions, right? And then, and Solania works with just about everybody up here, right? We have joint customers all over the place. But one of the things that doesn't tend to get factored in when you're making this decision is something that Justin mentioned is sort of the operating model, right? Maybe you want, maybe operating a cloud isn't your business. You don't want to be in that business. There's choices for that as well. So it's sort of a critical factor in something to think about. Then maybe you don't want to just put down the bits and install it and manage it yourself. You need somebody to come in and do that from the outside and those choices for that in the marketplace as well. And it's something that we see a lot of our customers that don't quite think about that because they haven't sort of had that option with a lot of different software packages. But that's really a reality with OpenStack. Yeah, I've, many years ago, about four years ago at my previous company, Zynga, I had to make a decision between Eucalyptus and cloud.com. Those were the only two things that same at that time. Feature parity, and you'll see that with all, these are all OpenStack based distributions. The differentiator for me, because I knew I needed to move quickly and scale, was that the engineering talent that I could get access to was the way I made my decision. And so that's what I educate customers on is the ability, because you're all hearing about, OpenStack still has a ton of problems. And you need somebody that's competent to help you solve those or navigate around those or take you down a well-traveled responsible path to prevent you from hurting yourself. So that story that the distribution kind of brings to you as to how they've prevented and how they recommend you deploy as well as the engineering talent that you can get access to through your POC and validate that you're getting the right support down the road. Yeah, so in terms of distros, there are many choices out there. I think there's like three X more choices that are not in the room sitting in front of you today. And then I think Seth brought up, like there's also different ways to consume a distro. You could have like private cloud as a service. I think there's companies like, I was confused, is it blue? Blue box. Blue box, thank you, up in Seattle. Meta cloud as well. Meta cloud, right? So where they will either host your servers for you. I think Rantis Express is sort of another way to consume Rantis. So there's different options there. So I don't want you to leave and say, oh, look, I gotta go put this on my bare metal in my data center. There are other options, but the goal here is to really have you come up with your checklist of what you need. And then hopefully we're gonna go through here and then you say, ah, right, that's the one that resonates with me. I'm gonna go talk to that vendor after the session is done, right? Can I just? Yeah, go ahead. Because you brought up a good point about engineering support and things as such, right? The other thing to look at is to just expand on that point is whether the software that you're getting or the distribution you're getting is catering to all that you need that you don't need more services on it, right? So you need to make a decision as to are you a customer that is gonna require a lot of services? And so you can get a distro that gets you customized service based on your needs or if you're a customer who knows pretty much what they want, they want bare, I shouldn't call it bare minimum, but they want something that is, gets most of your job done and you don't need additional services on it and that the software is gonna provide you. So you'll probably be somewhere in between. So you can decide where you're tending more towards and that can also help you get the right distribution vendor. Okay, so let's move on here and let's see what we've got next here. And by the way, please, I'm gonna go, this is a starter in terms of questions. We'd love to hear from you because that's really what we're here for, but I wanna go through a couple more things here that I think are probably broad-based that applies to a lot of people. So key considerations, right? If you were to, someone came up to you and said, hey, I'm deciding on a distro, right? What are the things you look at? Top to bottom use case applications, bottom to top infrastructure and other. So I'm gonna pick Justin because he's been quiet and then go to the rest of the panel. Yeah, there's a lot of that whenever they're coming in, right? So if you're kind of coming in with Greenfield, that tends to go a little easier, although the legacy of migration is really where the meat is. Everyone's got 1,000 apps and 10 of them are the Greenfield applications. So they got 990, they have to figure out how to move over. That helps flavor whenever you're looking at what kind of a distro. One might have a different hypervisor technology that tends to suit you. You may be needing to look at that for how cloud-ready are those and how big of an overhaul are you gonna be, which is gonna be part of the professional services package that those partners are gonna be able to provide for you as well in helping you go down that journey or do they have people that can come in and help you do application modernization or are you kind of stuck holding the bag yourself? I tend to think that the operating partner pieces, another one, so is it a do-it-yourself or are you looking to build internal knowledge on that? And not to say that you shouldn't be building internal open-stack knowledge, you actually should, but are you looking to found your own operations team internally or are you looking to kind of bring that out to someone else, because it doesn't put your core competencies or it's too big of a lift to bring that in? And those tend to flavor where you might go for your distribution choices. Team, yeah. And anybody else on the panel? Key considerations? Workloads, that's sort of where we start with most of our customers is what are the workloads that are gonna be running on this infrastructure? That tends to drive not just distro selection, but physical infrastructure, the server infrastructure, the network infrastructure. You know, are you doing a big data application on top of open-stack? Certainly that's gonna change your storage requirements and everything from your block and your object storage are gonna be factors for that for sure, as well as your compute resources. So that will drive your physical environment to a degree that you obviously don't wanna be building something that doesn't work for most of your workloads, but take a look around the enterprise and get an assessment of what's the 80-20, right? What's gonna get you 80% coverage? Maybe you're or maybe you're building a dedicated cloud for a specific workload. Take that into consideration while you're building out your infrastructure, the sort of a blessing and a curse, there's a lot of options in open-stack, right? Because of that, you can sort of, you have to really navigate carefully and make sure you land in the right place. I'll add onto that, that I'd also ask yourself the question, what is your IT strategy with cloudifying what you're doing? Kind of the sample of the audience sounded like most people are very early in that process, at least on the private cloud side. So what is your intent? Are you intending to build something that kind of preserves a lot of your technology investments today and add some automation capabilities that would depend more on customizations and those farther-reaching features that are going to be, you might be alone in using some of those, relatively alone. That's a dangerous place to be to do it as your first attempt. Or are you on the other side of the spectrum, which is I wanna build kind of the new two-dotto way to deliver infrastructure and force my customers to change how they consume it. I far more recommend the latter because the tendency historically for IT is to be the heroes, to provide that HA bulletproof infrastructure and that does not scale and not to scale in terms of quantity, but scale in terms of the rate of change that you want to be bringing to your environment or to your customers. So I try to steer customers towards the new end of the spectrum so that they have a faster on-ramp then once they've learned that, then they can begin to crawl into the customizations but they should really try to keep things simple early. Yeah, so from the landscape of customer, we see four main use cases. And we always start with the use case, what are you trying to solve the business from? We've been in the business of trying to talk about plumbing first but that doesn't work out usually. You have to really understand what the customer is after. Four main use cases are like the Cloud DevOps Cloud, like Paz environment. It's the IT as a service, the VMware replacement that you talk about, NFV and big data, but big data don't just mean how to do but any large scale out applications that just digest a lot of data and has to work at scale. And most of the use cases that we've seen, the customer problems fall into those categories. Now the bigger problem that we've seen is that in most cases, it's a big cultural change for the organization. They just have to do things differently and it's not a technical issue sometimes. You have to educate, help explain how this works in the new world. And the resistance that you get most often is not a technical, it's like, well, but we used to do these things and there needs to be a VM that does that. Well, one of the things that we do a lot as part of the engagement and talking to the customers is understanding those barriers because those are the things that are gonna make you successful and unsuccessful. If there is a buy-in for management to do it or it's just a local initiative, which is great, but may not scale at that point. So I think that the two things that you need to look at right up front is what is the use case and we have to like templatize those use cases. What do you do in this case? What do you do in that case? And then go down to the details to your choice of components rather than start from, I wanna use this type of networking or storage and then make your way up and then see how we help by educating, by working with the customer to get them to where he wants to be. Oftentimes I see, just to your point, I see large teams, large organizations with huge networking teams and storage teams and compute teams and then at that point, it's a lot more the cultural and organizational conversation than more of the technical conversation because if you're talking about a hyperconverged commodity hardware infrastructure, well, you have these three large teams who's gonna manage it, who's gonna be the one that will take care of it. It's not a switch that you turn on and suddenly it will be a flat organization, right? So those are usually the hard, and as vendors, you'll just stuck in a perpetual park and as consumers of this technology, you'll see that things are not moving beyond where you wanted this new technology within your organization to move. So that becomes an important thing to take note and to your point earlier, the best way to address something like this is have a Tiger team that looks at a Greenfield 2.0 initiative and addresses, this is one of the ways that can be done, that addresses this new requirement, a Greenfield workload with this lean team that goes ahead and tries this. Make sure the team includes the customer who has the workload. So one more quick survey, how many people are from the infrastructure group in their organization? How many people are from the development group in their organization? We've got a good mix, that's actually good. Yeah, and so that's what you think, so, you know. Okay, who's from the business side of the organization? Okay. Nick, you were gonna say something. Yeah, coming from a service company, I can only agree with what has been said, focus on your business objective, but do not forget what your constraints are because each company leaves its own set of regulations, own set of constraints, choices that have been made in the past. How to convert an organization is as complex as the organization is big, so always start small. And one thing I really like to use as an approach is what I call the contamination approach, or leading by example. Find a small team of individual that go across the organization that are going to build a successful example, a small one. And then build up on that because success calls for success. Yeah, and yeah, absolutely, absolutely. So there are microphones here, it seems like we've got questions, let's go. So thank you. So for most of us here in infrastructure, OpenStack is a foundational technology which a ton of other stuff needs to be built on. And the fact is if you can get OpenStack to disappear completely and be invisible to the applications, that is probably your ultimate goal for your business. But being a foundational technology as such, what are some of the things that your companies have done to address the applications? An example of that could be the NFV platforms that are coming out being an easy use case. What are some of the things, concrete things that you've done to add value in that space? So I think if you've seen the keynote yesterday, so Morantis is really heavily invested in HEAT, Morano, and the application catalog. And what about half of our upstream team, Sahara Big Data, is focused on is the higher layer of the problem. Not giving you applications, but allowing you, once you decided here's my workload, we make it super easy and for, but we, I mean, we make it as a community project, everybody on any distribution can use it to deploy it in a repeatable way and give you much more control. So using infrastructure guy could come to your application and say, okay, let's moronize, you know, this application offer them as a catalog and then users can consume them. That is key. So we've got all the infrastructure, that's great. Now we have to create, we have created the layer to make everything or anything as a service and offer to your users. And that is becoming far less dependent on the OpenStack release cycle. It's up to you. Yeah, so I wanna, you know, just pause there because I think in terms that we talked about, you know, sort of mode two apps, I heard NFV, I think Hadoop, you know, Big Data is gonna be another one, Platform as a Service, another one that I see. Anything else that you guys would loop into the, yeah, you know what, these are the kind of workloads that we're seeing people put on that's not homegrown. You know, we've got, you know, folks that are transforming what used to be delivered as bare metal, Communications as a Service and now they're doing that virtually. So I think there's a lot of things that people are doing because OpenStack in a cost is disruptive, it's more agile, it's very automated. So the principles are there. I think for NFV, it's still the book still being written on that, like I think you ask 10 people, you get 10 different answers, while with I think Platform as a Service, look, it's generally, it's either Cloud Foundry or OpenShift, I don't really hear any other ones. So it's consulting to that point. When you talk about Hadoop, it is Hadoop and you're deciding which, you know, whether it's MapR or Cloud Air or whoever you're gonna use, right, so NFV, I can't quite say is there yet, right? Maybe in some environments it is, but it is the platform that a lot of vendors are choosing to build their NFV solution. So, okay, yeah, yeah, yeah, there's an opinion, an opinion, definitely an opinion, an opinion, absolutely. So if I can comment on the NFV, the problem of NFV is that it's a multi-faceted problem. There is the requirement from the telecommunication operators with whom we are working directly, trying to address their requirements, and often these are very, very sensitive requirements. There is a requirement of the network equipment vendors, the people that are trying to sell NFV solution, and they have another set of requirements, and then there is the requirement of the application or VNF that runs on top and the orchestration of those on top. So you cannot only address the problematic of NFV from any one of these three aspects, you've got to work with the ecosystem completely so that you can build a solution. And our approach to that is, hey, let's not make yet another version of OpenStack, let's make sure that our OpenStack distribution includes all the requirements from these three aspects because a lot of these requirements we are finding again in other types of enterprises later on. In fact, the requirements for the very fast throughput on the networking side, the number of packets per second, are requirements that you're going to find if you want to use OpenStack in any kind of high-frequency trading or other things like that. So we really enrich one distribution to make sure that it answers this problem correctly. Now, OpenStack clearly is what I would call the bottom layer of cloud. It's the enabler of the other layers. And for a long time people were saying, yes, pass, sass on these three layers. Hey, guess what, we found another one. There is the microservice layer, the container layer that sits very well on top of OpenStack. And the pass is now an orchestration layer and a definition layer for this container layer. And enabling this work all together is really what we are after. And this is not work only for NFV, this is work that is benefiting the whole industry. Yep. All right, any other questions from the audience here? I saw some. Yeah, so yeah, so the question is, right now, they're just something to quote, a lot of options. You're buying really a solution that has all these moving parts. Are we gonna have a future where it's, you know, the Home Depot or whatever, easy button that you're going to use for the future? Yeah. Yeah. Yeah, so the question is, you know, right now they're just something to quote, a lot of options, you're buying really a solution that you plug into. Do you want to take that, anybody? Yes. Yeah, go ahead, go ahead. So yeah, we definitely see that OpenStack right now is a solution that we have to work with the customer, at least initially, to bring it to the point that it's repeatable and scalable and then the customer can grow on his own and have a lower touch. For a large deployment, it's really hard unless you have the skills and you're right. We absolutely see and work towards the point that it is as easy as Linux or as easy or as hard as Linux is. And you know, there is a deployer, there is monitoring tool, operational tool, patching, upgrade, everything is seamless. So our hundreds of engineers are focused on upstream and on making it a product to the point that it's lowering the barrier for everybody with average IT skills to be able to operate it. We believe that it's gonna happen much faster than Linux just because everybody have seen the process, everybody could predict the next step. And that's something that we already see customers getting there and we see OpenStack getting there in a matter of a year or 18 months. Yeah, and I wanna interject, like I think if I'm not mistaken, Justin, maybe you know this, I think the first distro that came out was maybe Rackspace Alamo, like maybe two years ago. Yeah, we had one about three years ago. Yeah, so a couple years ago, installing OpenStack was the problem, right? We're beyond that. Like now I think we're getting to the next word of detail where you are asking how big of a cloud you're building, what kind of applications you're using, what kind of infrastructure you have. It is very true that you still need, you still need somebody to answer those questions. It did not a small, medium, large, blue, and then just push the button, right? So we're not there yet. So I would, I would not totally agree that we're completely beyond easy install and, right? Oh, come on. You know, I've been in the OpenStack business for, since about three, four years now, right? You know, I've tried to do them. And so there's the promise and there's the reality, right? The, and therefore piston stands on this right now is this, right? That we build this cloud OS, you know, operating system platform to make it very easy and simple to install OpenStack. And the OpenStack distribution that we have right now is a curated distribution just because we know that there are customers out there that are looking for that easy button, right? And they don't want all the bleeding edge features and functionalities that's coming off from the latest, you know, trunk. And those are the customers that we, that we doesn't know it really well. And so that's one point. The other point of running everything on top of OpenStack, we had this telco customer last year that wanted to, on the same cluster, wanted to run this analytics application and a big data application on the same cluster. And they started, we started working with them and they, in their benchmark testing, they were running the big data Hadoop cluster on top of OpenStack. And they saw that there was 15% penalty in doing so. And so they had to, they still did OpenStack using our technology, but they came back to us and said, you know what, if you had a similar thing for Hadoop, independent of OpenStack, that would have been really awesome. And they still went ahead and built that big data cluster to three months to do that. But that got us thinking. And that is the reason why last year we worked on expanding beyond OpenStack in addition and independent to OpenStack if customers want to deploy this directly on bare metal. So we've got a queue of folks asking questions. Go ahead, sir. Those are with American Airlines. To actually get to some meat here, some of the things that I've built to my own scorecard to try to select a distribution, which we're trying to solve. One of the things was the idea of Apple Store versus Google Play. The fact, some of the distributions have the ability to say, hey, I have a controlled garden where I've vetted these things before people are exposed to them. Others say, anyone can post stuff up here. And if you look at what's happened with the flashlight app for most apps, it turned into malware. And that's the most common platform for someone to exploit malware because everyone wanted a flashlight. So that's one of the things I saw as a key distribution. I'm surprised you guys didn't point that out, is as a company that wants to select one, one of the things I am expecting is the ability to have more of an Apple type of world where I have some pre-qualification of the things that are easy to add to your environment because you guys on the consultant side of the distributions is that you have fuel things. You have juju things. You have, I forgot what Red Hat calls the stuff they got from Inovance. But yeah, like the Forman crowbar things. So in there, there's stuff that they already pre-canned for those things to be used and having some idea that this has had someone look at it so I don't have to hire people to go code dive into these little add-on things is a, for me, one of the critical distribution differentiators I'm looking at. That happens today. I know as an ISV we go through some certification programs with the district partners. So that happens for us today. It is advertised. It is clear you do get a mark. But maybe that's one thing we should take as a more important for people to sort of be able to see up front, right, up front. But yeah, that's done today and I think maybe a key message to take. And the foundation itself is actually working on a program to do that, to certify. Somebody wants to build a piece of software that certifies a run on OpenStack. They can get a stamp directly from the foundation that says same way the district players do. They get the OpenStack powered. All those different logos that are being expanded over time. So more of that's coming for sure, like that. Hi, so I come from a company that we have a DQS environment that our developers create our applications on. It mimics our production environment. So Cisco EMC, F5, and VMware. We're getting hit and a lot of pressure to begin to automate and orchestrate our systems so our developers can quickly spin up environments, test out their apps, debug their apps, spin them back down and just keep rolling. So my question is from both a distro and an integrator, how much, recent investment, so we don't want to rip it all out, how big of a pain is it to integrate with existing systems? Is that a major undertaking? For example, I've hit some of the boost and I'm still confused on VMware if I have to use their variant if I want to integrate with vCenter or if I can use other distros. Is that a major undertaking? What's your experience been in that area? This is where your due diligence really needs to dive deep because when you hear in an OpenStack release note that, oh, this particular proprietary storage device is supported by this new release of these new features, what you often discover is that is in complete support compared to what you might be doing directly with device today. And that's where that kind of money pit of customizations ad nauseam might take you away from what you might want to do alternatively is provide a new environment upon which a seed of how to do development differently that uses more utilitarian components. I think back to cloud scaling was a great scale out but it was very simple rudimentary cloud offering that forced the consumer of that infrastructure to change how they did their business. So there's a lot of people that haven't traveled enough down those paths to know how far reaching those promises of integration across those proprietary platforms can really go. So one comment I would made is that this is a perfect example of cultural shift that needs to happen. You're saying, I got this EMC, I got all these proprietary pieces that are connected and got their storage team, network team and still I want this cloud thing. My recommendation to you would be let's start over and think what is the best thing for you to provide for your developers that would make them faster and more efficient with or without the pieces you have because you're coming to this problem from, I've got all these gear, all these legacy stuff and I want to keep it but I want to keep OpenStack. You know, maybe you should not go to OpenStack if you have not made a conscious decision that maybe this is not what we want to do and maybe it's suitable for part of your business, maybe it's suitable for large part of your business but this is a discussion that we would have showing you examples of other people who did that and what are the pros and cons? So we're at the end of our session. I want to thank Red Hat, Piston, Maranthus, Selenia, Rackspace and Redap for sharing their notes here. Obviously please come visit their booth. Our Plumgrid also is a partner so we can definitely talk on behalf of them relative to the networking side. Hopefully you found this educational. We'll spend time here after a bit but hope you guys have a good summit and hopefully we'll chat more. All right, thank you very much. Thank you. Thanks guys.