 Hello, everybody, can you all hear me okay? Is everybody having a great summit so far? Glad to see so many of you here on a Thursday. You know, well done all of you for surviving the parties. Well done. How many of you, not that I can really see, but how many of you are actually attending the summit for the first time? It's pretty cool. How many of you are new to OpenStack and here to learn more? Oh, good, you're in the right room. How many here are just to heckle me? Yeah, figure that. Or am I just the warm-up act for Termi's brand tough to this one? You might wanna go for that talk, it's in the same room. So who am I? I'm a technical consultant specializing in OpenStack for the professional services team in the UK. I help businesses in the EMEA region basically be more successful with OpenStack. I help design their infrastructure and I help operate the infrastructure once it's all deployed. How many of you are from Europe and around that kind of area? Okay, that's cool. So if you ever chose Rackspace, you know, as a partner to work with, fortunately for you guys, you get to work with me probably. Yeah, I feel sorry for you too. So, I've been using OpenStack now for about five years. So yeah, that goes back to the really dark days. The candidates where you type in Overboot and you've got Hello World back. They were good days, that's when Hello World worked. But you may know me from such books as the OpenStack Cloud Computing Cookbook, first edition, and the second edition. And also the OpenStack Foundation Architecture Design Guide. I've always wanted to say that. Just doesn't sound as good not in a trauma claw kind of accent. By the way, don't buy the Cookbook. Yeah, now I'm the world's worst salesperson. But there's a third edition coming out at all. If you've already bought it, great. You know, my kids will have their beans this week, but yeah, I'd wait for the third edition. So, how have I managed to persuade all of you people to come to see my talk early morning on the fourth day of the OpenStack Summit? Well, I think it comes down to the title of my talk. So, never has a true word been spoken. Especially if I tie that title into a, you know, one with a Disney theme tune attached. Bound to be picked. So, if you ever want to get a speaker pass for the next summit, that's how you do it. But thing is, have you ever known, do you ever know what happens after a talk gets accepted? Well, there's a little bit of a loophole. Because basically, I've got you all in a room right now and I can do anything I like. So, I mean, I could have, you know, I could have actually started and launched my career in comedy. It's always good to have a plan B. But, I thought after a few days of OpenStack, you must be all OpenStacked out. Well, I thought, you know, given the title of the talk, thought we'd just do a little bit of Disney karaoke. You want this. You know you want this on a Thursday morning. So, you're all ready. You think I'm joking? Do you want to build a snowman? Come on. Do you want to play? I never see you anymore. Come out the door. If like, I've gone away. Do you know what? Vancouver, you haven't half left me down. Seriously, right? If this was Tokyo, this room would be rocking right now. Right, I'm kidding, right? OK, so back to building snowmen. Right, just go with it, OK? So, I've got kids. You know, I've seen Frozen about a gazillion times. But, yeah, I know. Maybe I should have just let it go. Telling them that comedy career is looking good right now. And I want to talk about Snowman Stack. I guess I've got to use this somewhere in my talk. It just wasn't clever enough. So, Snowman Stack it is. So, what is it? Well, it's like OpenStack. Everything seems all rosy. Then halfway through, disaster strikes. Somebody breaks into a song. Obviously, none of you lot. Then after a perilous battle, your next tech team finally understands neutron. As Snowman Stack is, make believe. I want to give you five takeaways from this talk to get you there with OpenStack. So, number one. People. It's important that people are involved in your project. Ah, sorry. It's important the right people are involved in your project. How many people have heard of failed OpenStack deployments? You hear it in the press. Yeah, it happens all over and it's the doom and gloom. It just doesn't work. But when you dig deeper into some of those failures, you kind of understand, you know, what kind of went on behind the scenes. You hear that the developers didn't get what they wanted. But that's not surprising, because the developers weren't sitting at the table when you were designing the solution. It's unfortunate that that happened far too often. I go into organizations and you don't realize that it's a two-way conversation. You know, the requirements flow from all directions. And that's from the people that write the checks. They're important. To the people who rack and stack the boxes, to the people cabling the boxes to the developers or the end users of your system. Don't be surprised if some of the conversations that you have around that table make you feel a little bit uncomfortable. The thought of developers having the ability to clone complete environments or heck, just even create networks, you know, makes grown NetSec engineers cry. I don't know why I'm picking on NetSec. They just seem like such an easy target. I'm sorry, if you've got any NetSec engineers in here, I do apologize. But OpenStack will only be successful in your organization. If you see it as an evolution of your processes, it will have to change and adapt. And the rule book will have to be rewritten. Education is vital here. Understanding what OpenStack is and what it isn't can make or break a project. I've seen many meetings where, as a pre-sales architect as part of my function, you know, I would sit there and I'd go into a full-blown design session. I'd go into a full-blown session on what is OpenStack, what is Nova, what is Cinder, how they all fit together. It's the kind of session that would make our training team a rack space really, really proud, apart from when they see the scrolls on the whiteboard. But that's important. Get educated. I mean, you made the great first step, you know, to come to these kind of summits, you know, but attend meet-ups and stuff. Get all that information that you need to plan your next deployment. So the C word. We're all adult, right? We have to use the C word carefully. Cloud is a four-letter word. Do I need to bring that hand back up? It freaked me out as well. But the word confuses the hell out of everyone. But it brings clarity to everybody else. Cloud, the word cloud is designed to hide complexity and makes it someone else's problem. The reason I'm bringing this up is simple. You're designing services that are complex by nature in your date center. The outcome of your project should be to hide this complexity. If people are finding it difficult to use your OpenStack platform, we need to go back to the design. We need to go back to that day one and actually ask if you had the right people in the room. So they're all interlinked all these. But it's your job to understand that complexity or at least appreciate the complexity that OpenStack brings. OpenStack has a number of moving parts. So it's like a car. I'm no mechanic. But I appreciate that a car takes petrol or gasoline, depending on what country you're from, injects into my engine, you know, sparks happen, crankshafts move, the engine turns and then wheels move, and then, you know, pack it all together in a nice shell with a whole load of other electronics. That's my car. As a user, I just, I operate that car. I don't have to understand the inner details of it. OpenStack is no different. It's a suite of open source projects that are glued together by other open source projects. And operate as a cloud to my end users. Do you need to know that NOVA uses a message queue? You know, to understand what work it needs to do? Of course you do. Do you need to know how, for example, RabbitMQ actually works under the hood? Not necessarily, but you have to appreciate how that works if you're in that area of troubleshooting that. But do the end users need to know that RabbitMQ's being used? Definitely not. Do they need to know that there are three controllers wrapped around, you know, wrapped together with low balancing and Galera? Of course they don't. Do they need to know that computers are not fault tolerant in your particular design? Hell yeah. There's so many stuff which, for years, they might have been on a platform which has been doing a lot of that work for them. When are you going to surprise that one on them? Developers want to know what features are available. They want to know what API to use. So number three, be realistic. So, cloud answers all of IT's problems. All some introduces new ones. By the way, before I go any further, you know, obviously there's a little bit of a Disney undertone to my theme. Anybody see the sort of reference to Disney in that particular slide? Font is aerial. Little mermaid. I know it's 10 o'clock on Thursday morning, right? Just go with it, okay? Cheap laughs. Anyway, OpenStack has exploded in growth and interest. Of course it's a wide and open development platform. It's fantastic. The list of vendors supporting OpenStack now seemed like a pipe dream five years ago. I mean, there's challenges, especially for people who are new to OpenStack. It must be very daunting to actually see the paths you can go down to work out where you need to be. The list of OpenStack projects and programs is immense. It's also like a shopping list. You know, for people heading to the out-of-town DIY store. If you ever walked into the vast warehouses, ceilings up to the sky, full of power tools, materials, ride-on mowers, you've got in your head how that lovely out-house of that shed is going to look in your back garden. You know, with the heated floors, little balcony, the bifold indoors, but OpenStack is what you hear if you're not careful. It'll work. It'll be a place to store your ride-on mower. I don't know why I've got an obsession with ride-on mowers. I've got a tiny garden. I just really want a big garden for a ride-on mower. What we should have done is done your homework. Find out what works together and what doesn't work so well. So when we operate OpenStack for our customers, the projects that are highlighted in red are what we support. Sure, there are many others on there, which from other vendors or other people that's all well and good. But we found that they either cause problems in our environment or we're just not ready to bake them into our product that way. The point, choose your projects carefully, as well as who you want to work with in the industry to help you get there. Many developers and ops folk basically see that list and they're like a kid in a candy store. So it's important to understand the maturity with these projects. What I find is people tend to do research in OpenStack, which is obviously a good thing, right? So they go in and they find out how they think all these things fit together. And they come up with a great design and they might run it for a little bit in their environment and then they come along and ask for some rack space and say, hey, can you support this now? But we have reference architecture and products that we trust. We've done our experiences of running these things for quite a while. And that's based on different size organizations, many big, many small, a lot pushing the boundaries. What I say is if we don't support it, just approach with a little bit caution and pragmatism. It's not warning you off, it's just a case of, look, you're in here to actually, well, I want you to go away from here with success. So I would say just err on the side of caution. This is a simple view of what we support and operate for many organizations today. All of the software you see is open source. Or if you have the cheap seats in the back, maybe you can't, but it is open source. It's a very stable, scalable solution, surprising of a three-way, I can't really tell there, but there's a three-way cluster controller set up, a login server running, you know, what people see is the Elk stack, it's very common these days. And then scale out compute, Swift storage and Cinder storage. All we ask is we put this behind dedicated, highly available pieces of kit that you run and trust in your environment, like dedicated redundant switches, redundant firewalls, kind of stuff. But the point is, keep it simple. I wouldn't say stupid, although I just did, but kiss. You don't have to see the sessions available over the course of this week to start to get overwhelmed of where to start with OpenStack. Look at what you're trying to achieve. Remember, OpenStack is just compute, storage and networking. Please pick up a free copy of the OpenStack architecture design guide. You can even buy a tree copy. But that has reference architecture for a number of wide use cases. But have a look through that to see what additional expertise you might need to enlist for your particular project. But I spend most of my time talking to businesses through applications and environments that are on the cusp of an automation journey. They choose OpenStack for its OpenStack API. And many, many actually say it's a standard API these days. It's gone on the days of wondering where the Nova API and the OpenStack API is going to go. I have banks telling me this is standard these days. They choose it for flexibility and working with the tools that the developers have been using for years. They choose someone like Rackspace for their ability to help realize these automation and DevOps goals with OpenStack. DevOps. We know that this is just a mechanism for efficiency. OpenStack is a link in that chain. For those just starting out though, start out simple. You don't have to automate everything from day one to realize the benefits of OpenStack. Take each project in turn, migrate to OpenStack, then move to a more efficient model. But it's imperative to have your developers work with your ops teams throughout the whole of this cycle. Rackspace, we can help you with that transformation. So number four for takeaways, the OpenStack community. The OpenStack community loves you. Everybody in this room, everybody in this conference, the OpenStack community loves you. I love you. How are you looking? And you're in a room with locked doors. The OpenStack community exists because of the successes and even the failures of everyone involved in OpenStack. We wouldn't be here today if we didn't have a vibrant and very active community. I love this picture when I saw it paid into it the other day. I love it. It's got nothing to do with what I'm about to talk about. It's no secret that to successfully run OpenStack, you need to get your hands a little dirty. OpenStack has a rapid and regular release cycle, and jumping on that conveyable can be daunting to some. But what it means to operators of it is a change in mentality, maybe a change in risk, a change in how you operate your infrastructure. At Rackspace, we embrace this change. On the backdrop of a very stable core platform, our latest architecture of OpenStack allows for seamless upgrades from one version to another. Community has a very big, very active development community. You can see it as you walk around this conference this week. The thing is, you can participate without even knowing a single line of Python. Raising bug reports are crucial to generating resilient code that ultimately you consume and the people next to you consume. There are lots of eyes on open source projects, and OpenStack is one of the biggest out there. Can you go one step further and actually create patches? Even the documentation is part of this process. If you see a mistake or a typo or even commands that just no longer work, click that little bug in the corner. Very important that documentation, along with everything else, is kept up to speed with the rest of the development. To be fair, the reason why I'm bringing this out is documentation is very, very hard from an author, and it's incredibly frustrating. If you have a question that needs asking, there's a very active mailing list. Very, very active mailing lists. There's a busy forum Ask.OpenStack.org and many IRC channels with the specialist teams. You can actually ask direct questions. I'm so glad I found a picture of a blueprint of a snowman to tie it back into the talk somehow. Is there a feature that is preventing you from adopting OpenStack? If so, blueprints are your friend. Whilst you're off partying the night away, the OpenStack developer community are hard at work discussing the features, the blueprints for the next release. You should get involved. You should join those discussions to ensure the success of your project and many others by your contributions. That brings me on to my last point, support, because of Rackspace we can help you in that, raising those blueprints. I've worked with a number of organisations big and small, young, old. A lot of the old ones are coming out of the woodwork these days and think OpenStack is the right thing to do. But they've had great success but it hasn't all been a smooth ride before they come and approach us. Many either start out on their own, in fact lots start out on their own or they've chosen some other vendor who design and deploy OpenStack but basically just give them a phone number to call if anything goes wrong. There are many vendors at the summit this week that offer different ways to help you with your OpenStack journey and different levels of support. All I ask is that you choose the right one that works for you. You didn't get the subtle thing before so I went a little bit more in your face with this one. But yeah, seriously, understand how they can help. They're all different. They all offer their own bits of support on top of OpenStack. But I do hear that Rackspace is pretty darn good at this thing. But it's crucial to have that partnership in place, not just to support contract. Understanding business drivers, long-term strategies, how you upgrade, how you want to do business is what we actually do. I actually went through that pretty quickly. I should have put more jokes in, obviously. But the key thing here is I want to give you... It was the five takeaways. So let's recap. It was the people. It's making sure that the right people are in the room when you're making the decisions. It's so easy to forget that very, very simple message because it happens time and time again. The C word. Use the C word liberally. Use it appropriately. And where it makes sense when you're talking to other developers, the end users of your cloud, or whether you're talking to the system integrators. And that's about education. But be realistic in your plans as well. I say OpenStack basically solves all of the world's problems, apparently. But just make sure you keep it back in reality and what works for you. Certainly embrace the community. Obviously, for those in the room here, you're doing the right thing. For those who are watching at home through a web browser, shame on you. But join next time, okay, in Tokyo. Enlist the right support that works for you. I say all vendors offer different levels of support. Different ways to make sure that you're successful. Just go around talking to the ones that make sense for you. Think of it to us. But that's it. I went through that very quickly, I'm sorry. But that means there's plenty of time for questions. So anybody who has any questions, and if so, do you want to go up to the mic? Or we can just do karaoke again, in which case, go up to the mic. Any questions? If you don't have any questions, you can feel free to come and see me, get business cards and all that kind of stuff and chat strategy, Disney films, all that kind of stuff. But since I know that some of you were disappointed about not doing any Disney karaoke, I just want to leave you a little something. You don't actually need the words, I'm pretty sure everybody knows this one. You enjoy your day and make sure no songs get stuck in your head all day, okay? Thank you, everyone.