 All right, we just got the thumbs up. Are y'all ready for OpenStack? Woo-hoo. Who thinks they're ready? Obviously, if you thought you were ready, you wouldn't be here, right? One person's ready. Sweet. So my name is Nikki Acosta. I'm a Cloud Evangelist. I spent some time a few years at Rackspace, just as OpenStack was being born. Scott came and joined the team as well. Shortly thereafter, we left to a little startup named MetaCloud. We were there for a whopping three months before we were acquired by Cisco. But if you've been in the OpenStack community for a while, you might have heard of us and we're not scary people, so you can always say hi. You're only allowed to tweet good pictures of me, by the way. Don't do that double chin shot. It's terrible. It happens all the time. Do you want to introduce yourself? Well, she did a fantastic job of mostly introducing me. These days at Cisco, director of our market strategy, and so that means I get to spend a lot of time talking to customers and prospective customers and partners with Nikki around the world. So we tried to consolidate what we've learned over the past nearly five years in this space into a talk that we call Are You Ready for OpenStack? We hope you enjoy it. Yeah, I work on that too. So being at MetaCloud, we worked with a lot of web companies that were born on the web, used cloud from the get-go, and now that we're at Cisco, we work with a lot of companies in the enterprise space. And the conversations that you have with stars versus enterprise obviously are vastly different. And so the intent of this presentation was to boil down the key points of conversation and the things that we cover and the objections that we ever come and try to help people get in the mindset of being able to get to a point where they can use cloud correctly. So that was the sort of reasoning behind it. We're going to talk a lot in the context of private cloud. We're also going to talk in the context of this being for the enterprise. So without further ado, we'll start off with some statistics. Spend outside of IT is at 38%. So you think about IT departments in large enterprises, they used to have all their spend there and now they've got bring your own device and they've loosened up a little bit, but that's a big number for IT. IT is losing control over what's happening in the information space within their own enterprises. So that's just something to think about. And that came from Gartner Symposium. 30% of IT spend is on private cloud. That's a huge number, gigantic number. And that's an increasing number we heard from Al Sadowski yesterday in the Ask the Analyst session. And here's the most staggering. The private cloud failure rate is 95%. And there are a lot of reasons why that is, but the two biggest are going to be a failure to change the operational model, a combination of doing too little and failure to change the funding model. So a lot of people kind of still getting their heads around, okay, I'm going to get this private cloud. What do I do with it? How do I operate it? How do I make it work within my enterprise? So let's start with, there's kind of two parts to this. There's the technical aspect, but then there's very much an important piece is the cultural aspect of open stack readiness. So let's start with the technical chops. And those of you, maybe in the US, maybe in Canada, have you guys heard of Jeff Foxworthy? The guy who did, you might be a redneck if. So it's kind of along those styles. So if you're using public cloud, you might be ready for open stack. And the idea here is, we kind of looked at all the customers we've spoken to and tried to put this list together. So if you're using public cloud, Amazon, open stack cloud providers around the world, very likely you've already adopted the tools, you've adopted the mindset, you've adopted the architectures for your applications. That said, we do see plenty of people that just treat it as VMs that they can get on demand and still do it the old way. I call it kind of virtualization on cloud. So this is a usually statement, not a guarantee statement, but if you're adopting public cloud and you're doing it at scale or you're doing anything like that, we see a lot of customers that come to us that started at Amazon and now have moved some or all of their workload back. So if you're using public cloud, you might be ready for open stack. If your apps and your data speak rest. Who speaks rest? Anyone? Two people. Two people or maybe three, four. All right. So if your apps and your data speak rest and look, this is no big surprise. If you've already API enabled the way all your apps and your data components talk to each other, very good chance you're gonna be ready for open stack. This is about distributing. This is about microservices. This is about all the things that separate all your components so that you can properly distribute them, scale them, deploy them and manage them and patch them and upgrade them. This is a path to get there. It's not the be all and end all. Anything to add to that? No. Wow, all right. If your apps need resources, not hardware. You might be ready for open stack. Pet versus cattle. Pet versus cattle. All right. So if your apps need resources, if your apps need resources, not hardware. What do I mean by that? Well, if we look back 10, 20, 30 years in IT, it was always I would either have some hardware that was very specific in my data center and I would say, all right, well I'm gonna make my app work on that or I was gonna build applications, your by platforms and then be really, really specific to IT about exactly what I needed. I need this model number. I need this exact switch. I need this exact configuration. This many Gs of network, right? I need all this stuff. And so in cloud, when you start to think that way properly, you start thinking about the resources those collections of hardware provide to you through your cloud. What are the capabilities I have there as opposed to the actual hardware? So if you're thinking about it in terms of resources, not hardware, you might be ready for open stack. Who thinks about it in terms of resources? Six people. Who thinks about it in terms of hardware? Everyone else. If you want automation, but not virtualization. Say it with me. You might be ready for open stack. All right. So the idea here, it's day three. I'm gonna try to have a little fun. The idea here is that there are plenty of people we talk to that when they think about cloud, they think, hey, this is a replacement for my virtualization stack or maybe I had what I call first gen private cloud where I took virtualization and I just added some self service to it. And so we try to get people to think further, right? The whole idea behind cloud is what you do with it, not what it is built with. Open stack's an amazing set of tools and projects that you can turn into cloud capabilities. But if you're not taking advantage of that, if it's truly just virtualization to you with a shiny layer on top, I would argue why use open stack? Just use virtualization, right? Don't put yourself through the overhead if you're not gonna actually take advantage of it. One of the ways you take advantage of it is by automating, heavily, heavily automating all aspects of your processes so that you can move faster. Docker, Docker, Docker, Docker, Docker, Docker, Docker. It wouldn't be a talk at the open stack summit or any other conference in this industry if we didn't talk about containers. Nikki added a little branding there with the Z. If you're doing containerized things, Docker, Rocket, Kubernetes, you pick your favorite buzzword, Magnum. If you're doing anything container related and you're already thinking about how do I take these little pieces and move them around and deploy them and scale them and connect them and automate them, very likely might be ready for open stack. Again, it kind of goes back to the previous slide. If you're thinking about it still as the container is just a replacement for my virtualization, maybe you don't need open stack. Maybe it's not the right thing for you. Maybe you just need a place to put your containers and all these technologies work great without open stack as well. But if you're thinking about it, I'm automating it, I'm treating it as resources, I'm doing all these things. As these things start to come together, more and more of a chance you might be ready for open stack. And if you're curious about containers, little shameless plug here. I did an OS pod. I run a podcast with a guy named Jeff Dickey from Redapt. We sat down on Monday with Adrian Otto, the PTL for Magnum, and I asked him like the very basic level, okay, explain that to me in easy terms. And he did a really good job. It's about a 30 minute podcast. So if you're curious about that, check it out on OpenStackPod. We have a Twitter handle as well. If you're automating all the things, all the things. All the things. You might be ready for open stack. So we've talked about automation, we've talked about containerization, we've talked about that. Many people just think about automation and we did a DevOps in the enterprise panel yesterday that also got recorded. All these things get recorded so you can find it on the YouTubes afterwards. But one of the questions I asked panelists were in the early days of DevOps, before it was even called DevOps in many cases, it was about automating your infrastructure, your configuration management on your boxes, on your VMs, then getting your infrastructure actually stood up. So here's my stack and I'm gonna define it. I'm gonna have a couple of database servers and some middle tiers and some top. Deploy that for me. Now we're seeing for the past couple of years this real trend to do it at the application layer. Automate your testing, automate all the things. So if this is the model you're moving towards, open stack might be a great solution for you. You can also automate against bare metal, you can automate against public cloud, you can automate against lots of things clearly. But if this is the mindset you're in, if this is where you're headed, you might be ready for open stack. And there may be instances where open stack may not be ready in general. And I think one good example of that is absolutely the Neutron project. I mean there's, depending on the vendor that you choose and how you're implementing Neutron, if you're implementing Neutron, that's one space that I think is still highly variable in terms of enterprise use cases. Just because enterprises come with a lot of networking expertise and old ways of managing things. And so that's one area that I think open stack is making it easier to consume those APIs and to get the expected results. But that might be kind of something that you may hold off on and until you get really good at automation with testing applications and other things is then start to look and get familiar with Neutron and just SDN in general. Yeah, I mean the value of Neutron, SDN really comes from once you automate all the things. When you can deploy an environment to development, test, QA, production all the way through your life cycle that feels exactly the same. And depending on who's your underlying hardware provider, like if it's Cisco, you can actually deploy the same hardware configuration in all those environments with code that you've automated, that becomes really powerful. But until you're automating it, it's almost impossible to get to be the same. And so that's where automation really comes into play. The power of the integrations that open stack has, the power of Neutron, the power of all the things start to come together for you. Automation's the key and it's clearly one of the most hyped things. You can't go into a single session without hearing about automation and DevOps, but it really is kind of the linchpin that ties a lot of this together. If your apps handle failure. You might be ready for open stack. Netflix, we've been hearing the story for many, many, many years, but I think they were one of the first named case studies out there where they said, not only does our app handle failure, when I say app, I don't just mean the piece that streams. I mean, the big global platform that they have that when you log in and you hit play, you know, we all get this, sorry, we can't play your video right now every so often, but it generally just works, even when half the internet traffic is streaming Netflix. And the reason they're able to do that is because they built into their applications the capability to know when things go down. One of the questions we get probably most frequently is, well, today my hardware or my virtualization layer or some other piece of infrastructure handles my failures. My apps don't do that. I rely on the infrastructure. Well, that app might not be ready for open stack. That app might not be ready for cloud. That app might not be ready for automation. It's about picking the right apps or being in the right mindset to say, I recognize that my apps don't do these things today and putting them in open stack is actually going to take me back if you're not just in terms of how resilient they might be, not because open stacks prone to failure, but because your app was not written to be aware. It relies on the hardware, it relies on the virtualization layer that are now extracted from you, right? And so if you're building apps that handle failure themselves, assuming all your hardware is ephemeral and will just go away at some point, you might be ready for open stack. So now we're going to shift, now that we've talked about sort of the technical aspects, we're going to shift and talk about the cultural aspects. And over the last few days, this is something that I think we've all been hearing about quite a bit. We saw the stat earlier about the number of private clouds that fail, and a lot of it is just due to the fact that the processes aren't in place, the operational model is not in place to make it successful. So, yeah, sure. So we'll switch sides here. And if it seems like this is a really polished talk that we've given a thousand times, that's because we just finished these slides about an hour ago. And that's not our SVP in the back, so moving on. Pay no attention to the man in the suit. So automating all the things is very much a technology and culture shift. And what I mean by that is you can adopt open stack, you can have APIs, you can have all of the self-service access that you can possibly dream of. But if you don't have the tools in place around the applications and how you architect those applications and test those applications and deploy those applications, then it's pretty much all for nothing. Part of the beauty of cloud and being able to move faster is in the automation. And it's very much, it's very hard to take traditional teams that have been working with traditional infrastructure on the network and the storage and the compute side and expect them to just kind of know exactly what to do when you give them this cloud to use. And so a lot of times we'll see teams, the most successful teams that we've worked with, they usually start with a project in mind and then target a cloud with that application in mind versus the other way, which is IT goes, builds a cloud and says, hey guys, we have this cloud we want you to use. Here you go, you can take it and run with it. If your goal is fast, then you might be ready for open stack. It's really, really, really difficult to put a price on agility. It's one of those intangible things that you say, okay, well, cloud might make us go faster, but if it makes us go faster, we can get features out to our customers faster, we can scale faster, like what's the actual cost of that? And it's kind of a crystal ball, right? You can't just say, oh, it'll help us be more agile and that's gonna save us X percent. With our customers that start out, either moving workloads or writing, something that they have moved from virtualization or from bare metal over to cloud, they always come back and they tell us how much they're saving or how much more efficient they are, but it's very hard to get that up front. And so we find a lot of customers that we talk to when we're talking to them about agility and their cost driver or their main driver is cost, there's a little bit of kind of a bad lens which to look at cloud. Like if you're looking at cloud as a way to just move faster and get software out faster in the hopes that you're not gonna fall behind, okay, that's good. But if you're looking at purely as a cost saver, may not always be cheaper. In fact, it might be more expensive, but hopefully the idea is you're doing a lot more with it. And one of our favorite quotes was actually from Chris Launey from Disney who was on stage, I wanna say it, the Atlanta summit a few summits ago and he was talking about Disney's relationship with OpenStack and how they've been on this journey for a while and worked with the MetaCloud team. And he said that if you can give your developers enough fast, right, it's not about good, fast or cheap anymore, you give them enough fast, they'll make their own good and cheap. And for them it was all about how fast can we go? They were really good fit early for OpenStack and have been very successful. You could do this one, this is a good one. If the thought of a run book makes you ill. Yes, if the thought of a run book makes you ill, you might be ready for OpenStack. And what I mean by that is that traditional enterprise application management, data management, systems management typically has a run book. You name your servers, it's the old pets and cattle analogy. You take care of all the processes and there's really very often not a lot of automation or if there is automation, you've documented that automation in a run book along with the steps to do it. And so if you're still thinking in this mindset, this is not how you move fast, right? There's a fine line between documenting how I manage my systems and actually documenting the steps to manage them, right? And one is something you can do in an automated way that's documented. The other one is just a mindset of human process and that's not how organizations move fast, that's not how you take advantage of cloud or OpenStack. And so I would argue if that's how you need to run your business, either for regulatory reasons or because you just haven't evolved the culture of your organizations, you might want to consider how much value you're going to get out of OpenStack. And if you'll be one of those stats on that first slide that's not the 5% we were successful, right? If opening a ticket to get resources sounds crazy. You might be ready for OpenStack. So we were talking to a prospective customer a couple of weeks ago and I think our jaws hit the floor a little bit. We were talking about how provisioning and self-service access and setting quotas and all the great things that you get with OpenStack and their question was, well, how do I integrate that into my ticket request system? And I'm like, wow, you're missing the point. That's the whole point of cloud. That's the reason why your developers are using Amazon or another public cloud and you don't know about it is because they don't want to wait to get what they need to do their jobs. So that's the mindset. If you're thinking, oh, well, I'll have my developers log in and they can get the request and then we'll process the request. If you want to do that on a tenant basis, great. But the whole point of cloud is to move fast to use the APIs. And if you're having to submit a ticket to get a virtual machine, then there's probably a deeper issue and that's probably a trust issue more than anything else. If your developers are involved. You might be ready for OpenStack. We talk to a lot of data center teams and IT teams. And it's interesting the questions that IT teams will ask you versus the questions that developers will ask you or application teams will ask you. And we have found that the most successful deployments that happen for our customers are when those teams are in the same room making the decision together. If we're talking to a data center team, they're concerned about the hardware that it's on and the networking components. And they might have some questions about the OpenStack bits and how the storage is configured. But when you're talking to application teams, their needs are so much different than the IT teams. And so if you're really going to build a cloud, which for all intents and purposes is for developers, then you should have your developers involved in your decision making process. Because if you don't and you turn this into an IT PEP project and you build a cloud hoping that somebody's going to use it, then you might fail. There might be that request to have a ticket that you have to enter before you can get access to resources. And so if your developers involve in that decision making process early on, you can get a lot more of the requirements out of the way, and you can come to a solution that I think both sides will be happy with. And for us, we deliver OpenStack as a private cloud solution in your data center as a service. It's a very different kind of model from a lot of the other OpenStack offers that are out there. And for us, our whole thing is we deliver a public cloud experience to your developers privately. So we have to make sure we're checking the boxes with the IT teams. And that is who Cisco traditionally has sold to. So that's where we have our relationships. But as soon as those boxes get checked, yep, this will fit well in our data center, this works. The next conversation is awesome. Let's talk to your developers. Let's make sure that the capabilities this thing is going to provide are the experience they're looking for, are the features they're looking for, can them automate, can let them do all the pieces that they're looking to do that we talked about earlier. It's so critical. If your training budgets have increased, you might be ready for OpenStack. So one thing that we find quite often, as well as we talked to some companies, is that they have that if we build it, they will come. Kind of talked about that a little bit earlier. If you don't have an inkling of what your current skills are and how you're going to get those skills up to speed to operate in a cloud model, then you're going to fail at private cloud. If you're not familiar with automation tools, if you're not familiar with agile development, if IT and developers aren't talking to each other, and both of them are getting the training that they need to make the project successful, it's going to fail. And so we have spent a lot of time, after implementation, training our customers to know what to expect from the API calls, to know what to expect as far as the monitoring that can happen, and what happens when you architect an application and hardware fails, for example. More so than that, the configuration management tooling, you have to have that. If you don't have that skill in-house, it's going to be very, very, very difficult for you to find that skill set. Because that skill set is incredibly high in demand right now, and it's expensive to get. And so we have found a lot of companies that have actually taken the training, they've asked for the training budget, they've taken their teams, they've put them in a room for a week or more, and given them all the training on all the tools that they're going to need. And then they give them time, it's kind of expected, they give them time to kind of play around with these tools and get familiar with them. Without those tools, your cloud is not going to work properly. And to be clear, we're not talking about open stack training. This isn't how to build or run or architect your cloud. This is how to build the apps that will go on the cloud. Because the reason private clouds fail is because no one uses them the way they expected to. And they don't have the training. So as you're picking your vendors and who you're going to work with and which data centers you're going to put this in and what apps you're going to target in parallel, start training your teams on the modern DevOps tools, the automation, change your processes, change the way you audit your applications. All of that training for all the different teams involved is what will make your private cloud successful, your open stack deployment successful in your organizations. A few more slides and then we'll take questions. So get your questions ready. What have we learned? What have we learned? What have we learned? Your mindset matters way more than your platform. Yeah, we used to show a slide that was the LEGO Death Star. If you've ever seen this thing, we've given it away at some conferences, like 7,000 pieces. Most of them are curved, which is really cool, not too many curved LEGOs. And that's what we as IT have been buying for a very long time, are these kind of very put together platforms. Cloud is not that, open stack is not that. It's more a collection of LEGOs that you can do anything with and they're all rectangle for the most part. You can build anything you want. And so that mindset of how do we give our people those building blocks? How do we give them the freedom? How do we give them the training? How do we let them automate? How do we do all these things? That's what's gonna make cloud successful for you and hopefully in turn, that cloud is an open stack powered cloud. But the what it's built with, what version of open stack am I running? How exactly is Nova configured? We've spent all week talking about this as a community here. All of that, you just put it aside until you figure out all the things we talked about that would make you ready for open stack. Because if you can't figure that stuff out, none of the technical bits are gonna matter. And that's the mindset over platform. So take off your developer's handcuffs. No, this is all you. No, please. It's a mind shift that again, web companies get, startups get. These are very small teams that have to move fast and have to scale fast. They let their developers, they enable them to build great things. They enable them to respond to customer demands. We had a customer who was able to roll out a new feature in an hour and a half. Like you don't get to do that if there's so much process baked in in between that, that it takes a week or eight weeks to get the resources that you need to be able to build that function. And so there's a big focus lately on developer productivity. This is where productivity is balanced with take the handcuffs off. You hire smart people for a reason. Trust them, set some guardrails, but trust them. And Adrian from Netflix, who many of you have probably heard speak over the years. He's since left and now he spends his time talking to CIOs and other people and they always say, you know, you built such amazing stuff but Netflix, I don't have those kinds of developers. Like how do you find those people? And he's like, well, actually I found them. They were working for you and I hired them away from you and I got out of their way and they built amazing stuff for me, right? And that's the whole idea. Take off their handcuffs and they'll do cool things for you. That was a Monctoberfest. Last year. Which Monctoberfest is a fantastic conference if you haven't been there, put on by the Red Monk team. Be ready to trade process for speed. Yeah, so that goes back to the run books. That goes back to all the human steps involved in the ticketing system, right? So we're kind of summarizing the things that we've talked about here and that you have to decide. Like everyone talks about how they want to move faster with cloud and innovate faster and do all these things but they're not willing to actually get rid of the 20 years of IT SCAR tissue process that are in the way. And so when we say take off the handcuffs, most of the way you will be able to take off the handcuffs is by taking like 25 steps back from how you run IT and just flat out getting rid of a bunch of process that doesn't make sense anymore. If you can automate, if you can put great QA and testing into a button instead of a six month human process, right? If you can do so much of that, architect your network with the click of a button now with SDN and things like Neutron, do you need all those processes? Do they even make sense anymore, right? Are they from the 80s? Like let's really decide as a company if speed is important to trade off this process and that's how you get there. Your RFP won't change your culture. How many people represent vendors in the audience versus like users? That's awesome by the way. It wasn't too many summits to go, I would have asked that and all the hands would have gone up and now it's just a few hands. We get a lot of RFPs come into us for cloud, for OpenStack, for data center transformation, all of these types of RFPs and almost none of the things we've talked about in this presentation are in there, right? The requests to make sure they can accomplish all the things we've talked about are nowhere to be seen and I have a habit of when I respond to RFPs to add those things in there and check the boxes because at least then they'll think about them, right? And people think I'm gonna put an RFP out, I'm gonna buy a cloud, I'm gonna build it, I'm gonna hire someone, we're gonna light this thing up and everything will be magical but I promise you you won't fall into that small slipper of people that are actually being successful here. Doesn't matter if you pick OpenStack or anything else in the world, I happen to be biased again towards OpenStack but just putting out an RFP isn't gonna change your culture, that's the hard part, that's the journey. Lighting up a cloud, we do it in two weeks from order to production, like that's the easy part, it's the culture that's hard. Your developers aren't looking for self-service, they're looking for cloud. So when we talk to larger companies especially about what they're looking for, again they're focused on a lot of different things, namely they've been hearing that their developers are spending money in a public cloud and they want a way to be able to have those people self-serve their access to resources. So we get developers that love the aspect of self-service but when they go to get this cloud maybe there's not APIs, maybe those APIs are restricted, maybe something's hidden and that's not a good way to operate. I would say at this point we have enough know-how and you've seen enough topics at the OpenStack Summit to know that it's not so much about OpenStack but what people are actually doing with OpenStack and the value of what cloud can provide is the value is coming higher and higher up the stack. And here's an example of that. I did a couple of summits ago, for a few summits in a row I did an OpenStack jobs report and this is from indeed.com, Simply Hired was the other one I pulled from and OpenStack jobs from two years ago have increased, the number of listings have increased by 221%. That is a huge amount of jobs that are available, that are empty right now because there's not enough expertise to go around. You think that's great, you think it's grown fast, awesome. Look what it is for DevOps. DevOps in OpenStack were kind of born at the same time, right? This whole idea of DevOps was basically came around when cloud became available. And so you see the growth for OpenStack expertise but now you're starting to see the demand for DevOps expertise. Not, how are you building a cloud? What are you doing with your cloud? But what are you doing on top of your cloud? What about the apps that you're delivering? How are you automating? These are the factors that are going to make your cloud successful and it's also going to be the factor that drives revenue at the end of the day. One last one for you, there's also Docker containers, because you know, containers. So you're seeing a huge, huge, huge. And I specifically put Docker containers because if you just put Docker, apparently you get like all kinds of port jobs for like seaports and stuff. So I had to put Docker containers on there but you're seeing kind of an explosion that too. And so while OpenStack, there is steady and increasing growth, really what people want to do with it is becoming more important. And that's for any cloud platform, public, private, what have you, the value is kind of moving up the stack. And so in closing, it's not so much are you ready for OpenStack but are you ready with what you can do with OpenStack? It's culture, it is the technology, but it's also figuring out how to bring teams together, how to start thinking differently, how to be innovative without slowing down your progress and other parts of the business. And that's the important part is getting it all to work together and really having executive leadership sponsorship too to make this successful. A lot of people will see the cloud spend go up and they're like, what value are we getting out of this? And if you're not measuring that, the budget's pulled for those types of projects as well. Anything in closing? Questions? No questions, none? It's after lunch, somebody's gotta have a question. Yes, sir. Question. Your big list of stuff, are you ready for OpenStack? That actually seems like a pretty high bar and it feels like not a lot of people would truly be ready for OpenStack. Do you see that and where do you suggest people start? Repeat the question? Yeah, so the question for the recording and everyone else in the room, the list seems like a pretty high bar. There were a bunch of things on the list, many of which most of you probably couldn't check all of them off and that's okay. I think that if there's a few key things on there, prepared to change the process around how you think about IT, prepared to start automating, prepared to focus on fast over control and process, I think those are the key things. And so if you light up your cloud or even if you decide to use public cloud, there's not a lot of value you're gonna get out of it by doing the old thing on a new platform. And by the old thing, I just mean the way we run IT. And so if you can check off a few of those, you're definitely on the right path. But get the executive support you need to start changing the entire picture of how you look at this to be successful long-term. Yeah, I talked to eBay also on the podcast. They were nominated for the Super User Award. And I said, man, y'all have been at this OpenStack thing for a long time but where on earth did you get the skills that you needed to be able to now have hundreds of thousands of virtual machines and cores running in OpenStack? And he said, you know, it's interesting, we actually hired initially, we hired a bunch of interns because we figured out that fresh college grads didn't come in with all these preconceived notions. And so they brought in all these grads and he said the grads that we hired three years ago, even two years ago are now our rock star engineers. And it's because they didn't come in with all of this pre-existing programming. It's almost like you have to forget some of what you know and in a lot of ways start fresh. And it's not easy to do and it's not cheap to do, but I mean, it's gonna be really hard to find OpenStack expertise. And so we're starting to see a lot of companies really start taking the time to ask for the budgets and invest in training for the employees. And that's coming through Chef and Puppet and some other OpenStack vendors that provide training on not just how to operate the platform because there's plenty of those, but how to properly architect applications on top of OpenStack. Other questions? Yes ma'am. So how do you balance compliance and standards and certification type obligations with moving fast? It's a balance that there's certainly plenty of good examples of companies that are required to do those things executing well, whether it's something like PCI, whether it's big pharma, banks, but there's plenty of examples of people being successful both with cloud and OpenStack. You have to pick where you start, right? And so if you're manufacturing, right, there's probably a third of the apps that you use that could easily be moved into a model where they're quickly deployed, quickly iterated on, quickly innovated on, automatically sent through that process with cloud. And then there's probably some that can't. Pharma's a good example. You validate a system during R&D and then it can't change for the 10 year cycle of that R&D all the way through to the production life cycle of the drug, right? Can't change without going back through a complete revalidation of every line of code in the system, right? And so it is a balance. Doesn't mean that that's not, moving fast to one industry is not necessarily moving fast to another industry, right? If your development life cycle is 10 years and you can shorten that to nine and a half years, that's fast, right? If your development life cycle is six months and you want to shorten it to six hours, that could be fast for another industry. So fast is a relative term and I would encourage you to look at what can be really fast without disrupting some of the other sides to your business. I'll put it this way. If PayPal can run 90% on OpenStack, other folks can do it too. And that might not mean moving everything to cloud. You might have a ton of stuff that's still on dedicated infrastructure, on a lockdown network somewhere, but there's probably components of applications that you could actually move to cloud while leaving other components that require different types of security in another component of the data center infrastructure altogether. And this might be a shameless plug for Cisco, but I would encourage you to pick a partner, I'll just say generically a partner, that really understands the regulated space and controlled industries and validation and all those types of things to assist you in your journey. Any other questions? We have two minutes, anything else? This side of the room's been very quiet. This gentleman here in particular has taken lots of pictures, so I feel like you must have at least one question. And we will post these slides, both on SlideShare and the video goes on the OpenStack YouTube channel. Is that a question? No, you're just getting that after lunch stretch in. I hope you had a good conference and you're enjoying Vancouver as much as I am. Thank you. Thank you so much.