 Time to get started. Welcome to production-ready OpenStack in 12 Parsecs. This is a part of the evaluating OpenStack track. My name is Mark Williams. And I'll give you a little bit more of an introduction after we get the show started. So this should be familiar to you. This is the theme of my presentation here. Now you're all going to have to imagine the theme song playing right now. I couldn't get the rights to the music. I promise this will be brief. And if that went by too fast, I have it a little more legible at the very end. So everybody knows this character, this Han Solo. And he came as an inspiration to me one night, right before the deadline to submit abstracts, his legendary status in the galaxy. And so I'm certainly no legend compared to him. But I do have a lot of harrowing stories from my experience operating large clouds and in my current role helping other customers do that. Now certainly in Han's case, he had wild claims in the movies about being able to do the Kessel run in less than 12 Parsecs. And of course, that's supposed to be impossible because the distance through the Kessel run is 18 Parsecs. So how does this all work? Well, we'll get into that. But a little bit more about my background and how we'll draw corollaries between cloud and the whole Star Wars Kessel run problem is based on some of my experience. So I used to be the infrastructure operations VP at Zynga during its heyday, polluting all of your Facebook feeds with various game things. And in the beginning of my career there, I walked into an Equinex data center on day one with 70 servers. And within that first year, ended up exploding into Amazon, expanding our data centers, which were still not cloud at that time, still bare metal. In year two, exploding wildly into Amazon as Farmville became one of the most successful and 100 times beyond our predictions in terms of growth and infrastructure that it required. So all of these learnings in Amazon, kind of in my first two years at Zynga, translated into gosh, we know we can do this better in a private cloud. We know the performance, we know the reliability, we know that the exclusive tendency of a private cloud will be far superior, but we knew we couldn't do it the bare metal way we had done the first year. So in 2009, I evaluated Eucalyptus and Cloud Stack, and we ultimately chose Cloud Stack to be the core of our private cloud going into the data centers. And through 2011 and 12, we went in the process of exploding out 13 megawatts worth of data center space with two regional clouds comprised of 42,000 nodes. And in the course of about 18 months, we shifted 85% of our workload that was Amazon EC2 based into our private cloud. So all of this happened in crazy, wild times in terms of stress, in terms of also learning and collaborating with great teams. So I hope to share some of that experience with you today. Currently, I work for Redapt. Redapt was actually my vendor as I think it was exploding out into those data centers. Redapt is a systems integrator who helps, typically web and tech companies fabricate all of their integrated racks so that there can be consistency in every build, cabling, testing, firmware versions, everything that's important when you're running large infrastructure. And what Redapt was doing while I was drinking from the firehose at Zynga was putting these cloud solutions on top of that integrated hardware and really accelerating the pathway for customers to be able to deploy their own clouds. And so today we specialize in OpenStack, CloudStack, and a number of other infrastructures of service and platform as a service technology deployments. Okay, so what's this whole road to Kessel? What is the 12 parsec problem, right? So as you've all experienced, and presumably because you're here evaluating OpenStack, you've consumed a lot of the hype with OpenStack, making it feel like it should be completely very easy for you to do this on your own. And kind of the secret that nobody's really letting you in on yet is that it's still extremely hard and what makes it hard is not so much consuming all of the defaults, but when you kind of venture out beyond some of those core, robust, well-adopted features and you get into the fringe of some of the things that might be solutions that are integrating with various foreign components that might be outside of OpenStack. And so you're led to believe that all of that works really well. And so what I want to equate for you here is this journey to the Kessel run and what it really took Han Solo to do how many times he had to go through that before he really got good at making the Kessel run, which is really the same thing as what it should take for you as cloud implementers to do in your cloud journey. And one way to kind of draw this corollary is with the cloud maturity model, which is a framework published by the Open Data Center Alliance. Show hands of anybody who's heard of the cloud maturity model. All right, a couple of people I work with and a couple others, great. I will educate you a little bit about this. So basically it's a five step or five level maturity process through which you really have to go regardless of whether you're doing public cloud or private cloud, you have to go through these steps before you're really able to kind of accelerate your journey. So if we look at this and perhaps how Han Solo was getting through his process and the Millennium Falcon, that first time he ordered his YT-1300 light freighter and tried to make the run, he probably didn't finish. So let's see if we can get this to work. I don't know if you've heard that. But first run probably didn't make it, right? It did not finish. But again, he probably didn't have a map, probably didn't have his hyperdrive configured, right? So again, he starts making successful runs, but it's supposed to take 18 parsecs. His first real attempt at it probably took 20. Same thing with the people starting your first journey on cloud. You're gonna make mistakes. You're gonna pick wrong technologies. You're gonna need backtrack. Same thing on this journey. And as you might imagine kind of iterating through it, Han and Chu, we are gonna get better at this. They're gonna start making optimizations to the hyperdrive. Finally, they get repeatable at step three, which is in the cloud world, where you've really got your tool sets defined. You've got the integrations with how you've been doing IT all this time with all of your incumbent technology. You've now mastered that with cloud, whether it's private or public cloud. This is the step when you have workloads that make sense in terms of being able to take advantage of that automation. And you're beginning to take advantage of the efficiencies in that automation, those APIs and coding to that as opposed to doing everything manually. So at this point, things become far more predictable, but now what Han and Chu are doing is they're making modifications to the Millennium Falcon. They're tweaking the navigation computer and they're beginning to take a more dangerous route but there's safety in their route because their computer enhancements they've done prevent them from getting swept into the black hole that's nearby and the hyperdrive enhancements are certainly paying off. And finally, at the very end, they're able to super optimize their route, get those spices out for the smuggling trade and now become legendary status. So again, same in your cloud journey, you can't start with an optimized expectation around, oh, well, we're gonna deploy OpenStack tomorrow and begin saving money as soon as the project's over. Like that's the last step, typically. And you kinda have to go through these phases. All right, there he goes. Making the castle run, yay, all right. Okay, so here's a little bit more detail about the cloud maturity model. This is available, just Google Cloud Maturity Model. You'll find this document. It's been around for a few years. I wish this existed during Zynga time but all of this makes super sense in retrospect for me and it will be a great way for you to establish a framework and a mutual level of understanding with your management, your teams, aspects of your business, those who are consuming infrastructure from you. If you think about and measure the different elements of your business along these paths. So I've added some highlights here about the things that really stand out to me. Level zero is obviously you like, there's nothing cloud going on in your world. Level one, think of yourself as a, oops, wrong way. Think of yourself as a Jedi youngling, just beginning to gain some awareness of cloud computing, experimenting basically. You're being trained by doing. Similarly with level two, you've narrowed down your approaches. You've become a padawan but you're still dependent on experts to probably help you along your journey. Level three, as I said before, you've got a lot of that kind of expanse narrowed into the tools that you wanna use and that frame of reference. So again, thinking about some of the things I've heard at the keynotes as well. Gartner saying 31% of all OpenStack deployments or private cloud deployments fail because the operational model of the company is not well suited to consuming it. Thinking about and being fair and fairly assessing yourself and your peer groups with this kind of model is part of what will help you get on the right course as you start down this path. So let's see here. Again, obviously I'll draw all these other correlations. You get to be a Jedi master. You really got cloud aware applications at this point. You're beginning to introduce capabilities of self healing as different parts of the infrastructure may fail. You might be getting active active in multiple regions or at least multiple zones within regions. And finally, you get to become Grand Master Yoda. These would be the Netflix of the world who are like intentionally introducing thrash and chaos into their infrastructures and just really sitting back and watching and improving the automation to make sure things stay optimized. The cool thing about level four and five is that the people there and especially in the OpenStack community, they are the people that you hear from on stage like this and that are paying it forward by contributing code, sharing their lessons and really engaging and helping others. So that's one of the great spirits about OpenStack. So another dimension to which you should look at your organization and how you especially as an IT organization or as a consumer consuming it, what things are important to you when it comes to cloud. And I need to give credit to James Staten for Microsoft at the OpenStack Silicon Valley 2015. He had a great slide up there that again was something I wish I had seen back in my Zynga days, but it was definitely something that I felt resonated with me as he shared it. If you kind of just list out the common elements that you expect to be in your cloud, this is the list. Now, if you think about the parties that might have priority or care and influence about this, you might think about the Galactic Empire on the bottom in blue there and the Rebels. They might have different kind of value systems against what they expect out of cloud or what they would want to see prioritized. So as you might imagine, the IT organization is gonna be that nasty, dark side Galactic Empire. They don't wanna do anything that's good for you. But it's because infrastructure and capacity is their job. That's their history. That's where their core competencies lie. As for traditional IT people, as they get up into thinking about what self-services and automation and orchestration, those are far more foreign concepts and comfort zones that they just don't have. And so when they're talking to the Rebels, who all they want is give me an API. I just need self-service. I can do this myself. I don't care if your server node has high availability or not. I'll just spin up another one. Just give me access. So if you think about these opposing views on what's a priority and what's a core competency, this is where these battles happen. And again, this is a way to begin to introduce change and conversation there. If you think about, the diamond shape isn't important here, but just kind of rationalizing and communicating about the relative priorities and deficiencies in your organization and the capabilities of your tool set as it relates to cloud, this is what Obi-Wan wants for everyone, like thou shalt normalize and create DevOps. All right. So again, after I did this abstract and started researching it, I got super nerdy and spent a lot of time on the Star Wars Wiki. And if you go look up more about the Millennium Falcon, you find out that it is a YT-1300 light freighter, which is surprisingly, when you read it with open stack in mind, it has surprisingly similar attributes to it. So some of the main bullet points about the YT-1300 is it kind of comes as a stock minimalistic system, but it's intentionally capable of having add-ons and components connected to it. And that's its appeal, just like open stack. Open stack, you can kind of connect anything that you want to it. And its benefits are being able to modify it. It's kind of an open system, if you will. And in the same way, those core projects, the ones in blue there, Swift, Keystone, Nova, Neutron, Cinder, and Glantz, those are the ones that are, you can't survive without those. Well, Swift is kind of standalone, but for the most part, you can't really survive without those. But the attraction is the Big Tent, all those other widgets that you can do. But you need to be careful. The Big Tent is far more scary in terms of, and there's tools to help you understand this too. In the last year, the Foundation has released a maturity grading system on all the different projects that are in the Big Tent and in the core. And you can kind of figure out where there might be safety in consuming some of those projects. But even within those core projects, as I mentioned earlier, some of those fringe features, some of the things that might not be as heavily adopted, the things you need to worry about. And especially if this is your first attempt at consuming open stack specifically, and that you should be very concerned if you're thinking your need to going to consume some of these fringe features as a part of your first foray and automating anything related to cloud. Okay, so let's discuss kind of as a systems integrator, as a company and a group that helps customers implement open stack, well, why does it take, why should it take 18 bar stacks? If that's the standard reference we're gonna say, Kessel run and implementing open stacks should take, why does it take that long? And why can't it take longer? So I don't know if I can zoom in here, but. So it all begins with you gotta get together with the customer and the vendor to finalize and determine the statement of work. You gotta get your procurement and legal to review it. That just takes time, that's out of your control. You gotta schedule resources. So with a custom deployment, which is the typical traditional approach to implementing open stack, you have to define your architecture. You have to sit down with presumably that ISV, that commercial provider of a distribution or your consultancy and decide, okay, how are we going to implement this? It's a time where during this architectural design session, you're gonna learn a lot about what open stack is and what specific decisions you have to make in your infrastructure to make it successful. And in that process, it's gonna take you getting your team together with their team and that just takes time, right? Then you have that session, they got a vendor has to validate, quote it back to you, then you kind of get into this, well, we're gonna negotiate the price, right? So you might loop a few paths around, that might take a few parsecs of distance there. Then comes procurement. Once you've agreed and signed that, quote, we the SI or whoever's implementing this for you has to go by all the gear, right? Presumably you're doing this on new infrastructure, highly recommended. But inevitably, and I know Kent's over here, Kent works for us and deals with the customer asking for changes, all I have to have this. And you deal with kind of a potentially recurring loop of procurement and changes. What happens then is at least with the way that Redapt does cloud delivery is again, it's like making sausage. Nobody wants to see, you don't wanna do this in the field, open stack's hard enough. So we do all of our cloud implementations in our merge facility, it's where our teams are, both on the physical rack implementation side as well as our cloud engineering people. And that tight coupling of experts that do this over and over again is very effective for us to eliminate a lot of the ugliness and problems that would otherwise be seen in the field. So again, our approach is to do that in our factory. We validate it before we ship it. We deliver it to you as a full integrated rack. And then the last two pieces are okay, we need to do that last mile of validation and provisioning. Then we get to train you on it. Now you're ready to begin putting workloads on it. Okay, that's the traditional path and that could be, there could be a lot of issues with that. So imagine you're taking the test drive of the YT-1300 with the salesperson. And you're jumping out of hyperspace here. And this seems to be advancing itself, but now you're back in the showroom and he wants to show you all the trim line packages that are available for the YT-1300. So you can customize it to make your OpenStack implementation awesome. So there's several different options and a fundamental approaches that might help you shave that path. One is getting OpenStack hosted, dedicated and managed for you at your hosting provider's premises. That's one option. Another one is, I really want to have it on my premises but I do want somebody, I don't have the talent, I want somebody else to manage that for me. And they can do that remotely. There's the approach where you take a predefined appliance, whether that's proprietary hyper-converged or whether that's kind of stock components. There are a variety of options there. Or that traditional path which is custom built to suit my premises, I've got staff and I'm wanting to engage and invest in this process. So what are the relative kind of benefits here? So if we think about distance and how long this path might be with a managed hosted, you can do it in faster than 18 or it might take more. It depends on whether you're willing as a consumer of OpenStack to take those recommendations from that provider, follow that reference architecture. The less you deviate, the shorter your distance will be. Makes sense. But if you have certain requirements that are going to stretch it beyond, you're going to make that path longer because everything needs to be validated, everything needs to be tested. Makes sense. So certainly there's a number of providers across all of these trim lines and spectrums. I'm not going to enumerate them all. I'm going to give you a couple of examples. So Rackspace is a well-known example of a hosted managed private cloud provider. So another short path is through again your premises, but somebody's remotely managed infrastructure. Cisco Metapod is another example. Now what's cool about Metapod is that historically they used to manage any OpenStack that you would do yourself and they'd take it over. After Cisco acquired them, Cisco within that year, one of them a year of that, they said, look, to be efficient at operations we have to normalize all of these differences. We can't just have the wild west of different implementations going on, different distributions. Imagine how hard that is to manage N different snowflakes. So Cisco came out with a prescribed thou shalt have that these SKUs as a part of your infrastructure. No exceptions. You can make changes later, but again, we have to make a prescribed set of hardware and a prescribed set of OpenStack projects that you can consume. Otherwise we won't be successful at scaling this. Now there's an interesting vendor that's come, I think they announced in the Vancouver Summit, Platform 9, if you've heard of them. As a part of my research for this, I started to explore them. They're kind of right between your premises to manage remotely and your own and hosted managed infrastructure. What they do is they take just the control plane. Imagine three highly available OpenStack management nodes. They manage that for you. And your OpenStack implementation becomes a vanilla Linux where you install their agent. And once you've installed that agent, you log into the remotely managed console and you can begin to extend the rest of your OpenStack. You can provide your own compute, but they do all of the upgrades, the monitoring and the troubleshooting of that management plane for you. And I think that's really interesting for, certainly if you self assess your cloud maturity level, kind of two or less, that's a great way to get started. How do you know that OpenStack is the right vehicle through which to try to expose those who would otherwise consume your infrastructure? This is a great way to try it out. I don't even have that many skills anymore, but I was able to do this in a couple of hours through the instructions on their website. So it was pretty easy to do. So again, that could be a really short path to getting something working with OpenStack. Again, as an operations person, I long term would be nervous about having that much complexity in a remotely managed control plane versus a on-premises compute node. But again, I'm choosing a shorter path over the ideal situation. And again, if I don't have the talent, I'm gonna depend on others. So appliances. So this is where Redapt and Mirantis have actually collaborated. And there's been a number of other offerings in this space. But for example, what Redapt and Mirantis have done have created a Dell Juniper-based, again, predefined prescribed rack that you can buy in certain quantities of compute and storage. And again, you don't have as much choice about what SKUs those are or what OpenStack configuration topology has been implemented. But again, it's predictable. There are known quantities of performance. There are known quantities of how to upgrade it. There are known quantities of exactly how long it should take to get it delivered. It's not a, you don't have to have an architectural design session to consume OpenStack in this way. It comes as a predefined solution, which is informed by all of the traditional deployments that Mirantis and Redapt have done in our past. We've normalized all of those best practices into one offering. So again, that's a great way, if you're starting out, to consume something that is well-known and let the rest of the way you do IT innovate with that, okay? So again, a shorter path, hopefully 14 parsecs. And then the traditional path, again, there's many ISVs that participate here and the custom build the suit. And they all have kind of great stories in the marketplace and many of their customers are telling you about their success here. But again, there are varying degrees of how much talent you need to have on your own staff to be able to operate these things once you have them on your premises. Again, the managed ones are obviously gonna be lower expectations on having internal talent. The ones on the right side, you need to have some to a lot to be able to be successful. And again, what I see a lot of customers do, especially in their first deployment, they spend far too much time thinking that they have to have all these bells and whistles in their first deployment when in many cases they aren't able to articulate what their workload is. And what the workload is is so important because that should be defining what special requirements you're introducing into what you're doing with OpenStack. If you don't have that, I strongly recommend you take something that's recommended generic best practice, see how your workloads perform on them and then as you iterate and making successive runs up to your own maturity, you'll be able to make those tweaks in successor implementations or upgrades to that stack. And again, reference architecture that could take 18 parsecs or if you're looping infinitely on these various changes and going on the fringe of these supported features, you'd take 30 or more parsecs. Gonna mention briefly, TCB Cloud. I have one customer who's taken a look at them. This customer I would put at a four on the CMM scale. They are the point where they wanna have control because they're contributing to OpenStack itself. They wanna be able to introduce change into their OpenStack in a very CICD controlled approach. TCB Cloud has a nice model for that. I kind of put it on the fringe because they're a newer, smaller company. They're based in the Czech Republic. I wouldn't recommend this for somebody who's just starting out necessarily. They are also a company that will manage it for you. So again, I haven't used it myself, but it's something that I would keep an eye on in terms of how they do in the market and how it might align with your requirements. And finally, if you get through the summit this week and you think, ah, you know, I can totally do this myself. I'm just gonna download source and do it myself. I got this. I don't know if you recognize what that planet is, but that's Alderaan. Y'all will remember what happened to Alderaan. Okay, so to illustrate as an example, how does that path, the Kessel, get shaved by using an appliance approach or a hosted managed? It's far more predictable. There aren't, the opportunity to introduce change and introduce chaos is far less. So instead of starting that with that ADA session that I had suggested in that other path, you can start with, hey, we're gonna be able to tell you what the performance characteristics, the behaviors, and project features are gonna be in this specific design. And here's an SLA around it, especially if you have a managed provider. And SLA is part of the story. And this is how we approach our appliance delivery in that way. Instead of kind of getting through that and having to validate everything, it really just becomes a schedule and a quote and a statement of work and goes through the rest of the process. Now what's interesting, especially with, I'm sure the hosting providers and certainly the way we do the automated implementations for Mirantis OpenStack on the unlocked appliance is because it's the same every time, the install installation, normally that would be fuel. So for those that have done DIY, Mirantis or a custom engagement with Mirantis, they have a great tool, Fuel, that is very good about doing that install. Now if you can do that same exact install on the same hardware, the same specs each time, you can automate fuel, you can script fuel. And that's what they've done with our collaboration. And at the same time, so that accelerates that, you don't have humans having to introduce configuration options in fuel. And at the same time on the other side, once you've built it, the validation can be far more automated. So that again helps shave that path and get us to doing the validation much, much faster. Okay, so ultimately at the end of the day, you need to make sure you have a master. Who is your master? So if you think about Anakin Skywalker, and he kind of got through those first three episodes and then kind of made some bad decisions, right? He thought he had this. He went rogue and look what happened. He lost his woman, he lost his kids and he ended up getting crispy fried on Mr. Far. So then he comes up for Darth Vader and you know the rest of the story, right? So it took him until the last minute of looking backwards in time and seeing the episodic thing with Luke that he finally realized he should have stayed on the good light side of the force with Yoda. So that's where I would encourage you all to make sure that you, and in the same way, especially with the open stack community, if you're gonna go down that traditional path and build a snowflake and make all these customizations and not contribute them back, that's contributing to the dark side of the force, right? So we want everybody to be kind of fulfilling the altruistic expectations of the open stack foundation contributing back and I think it's also part of that to not deviate and not go too far field into the nether regions, the dark regions of projects that are coming out unless you're very mature, I don't know why this is advancing on its own, unless you're very mature with your cloud capabilities and you have a process through which you can contribute that back. So as promised, here's the Star Wars crawl at the beginning. All I did is I took the beginning of the Force Awakens and changed a few things. So I hope you all enjoyed that and I don't know why this is advancing on its own. But I finished a little early, but I'm happy to take questions if you have questions, the microphones are there. Anything I can answer for anybody? Thank you all.