 Good afternoon. We're getting towards the end of the conference now, so if you're anything like I am, we've been through quite a lot of technical presentations, so this one should be a little bit slower for you, a little bit easing towards the end of the wind down time if you like. So let me introduce myself first and give you a bit of background about me and then that will lead to the understanding why I wanted to talk about this stuff as well. So my name is Glenn Bowden, I work for HP. I work out of HP Healing and Professional Services in EMEA and my job is, I'm one of the senior solution architects there as well as running the solution integrators team, so that it's a highly talented team of individuals that go and do their deployments based on the designs that I work with. So my background is technical, I'm a technical person, but this isn't a technical presentation, so this is a fairly high level presentation and this is about the other stuff that breaks open stack rather than the technical bits. I think we've all learned already how we can break open stack with the technical stuff, so this is the other bits that doesn't necessarily get thought of when you go into these projects, but are the things that can trip my team up and make us look bad because they haven't been thought of before we get in there. So we've all, I'm pretty sure heard the analogy of big business being likened to an oil tanker, which is what one of these things is. And if you look at it in the bay, you can see them sort of floating about out there right now. There's a lot of criteria about an oil tanker that maps to a business. So the first thing is the very slow moving. So if you imagine a large enterprise and HP is one of those with over 300,000 employees, doing anything can take time. It's a very slow moving process. These things are slow, the business is a slow. You need to plan ahead for every manoeuvre. So if you're trying to turn one of these things, it's not an easy thing to do. It's extremely heavy, it's moving at around 14 to 15 knots. You need to plan ahead when you want to start moving this thing. And it's exactly the same in business. If you want to change the direction of the organization, if you want to change your strategy, you want to change your process, you need to think carefully ahead about the impact that's going to have. And one of the reasons for that is once you start to turn it, once you start that process, the momentum will carry you on. It's extremely difficult to back out of it again and go in a different direction. It's not at all agile. We've all been in the situation where we've been in businesses that have started down a particular path and we can see that we're heading for a car crash, but it's very difficult to stop that sometimes. It takes a lot of work to execute any changes on this and it takes a lot of work in any business to make the changes. And the reason being is because there's a lot of stuff there that carries you forward all of the time. Things like the culture, things that you're used to, things that you understand already and people are in their comfort zones and they don't want to jump out of that. It takes a lot of work and efforts to manage the people out of what they already understand and into something new. There's lots of rigor and bureaucracy that goes into any kind of change. There's all processes. I mean, anyone that's been in a large organization and I felt it in HP, there's a ton of forms to fill in, right? To do anything. If you want to request a VM or something, then there's a process to follow. If you need to get your badge replaced, there's a process to follow. So there's lots of bureaucracy that wraps around this stuff and it all goes into managing the changes, not just from a technical perspective but from a process perspective as well. It takes a pretty large crew to operate one of these things. Not as big as you'd expect actually but it's still pretty big. Far bigger than the kind of alternative transports out there. And so you're trying to get everyone to pull in the same direction which is inevitably going to have some conflict or other. I've never met a large team that everyone gets on nicely and everyone's pulling in the same direction. It's incredibly difficult to manage. What people don't mention so much about these things though is they are incredibly stable. They're very difficult to sync. Not impossible as we've noticed but incredibly difficult. So they have some things going for it. And actually that stability comes from all of those things above that we're complaining about. So that's slow moving, that being able to turn and understand how you're turning, the bureaucracy around changes. That's what keeps the thing stable. So that's a large enterprise. Now I've been with HP since July so I've had recent experience of salespeople coming to visit me as well as going out and supporting our own teams. And this is what they're trying to sell. So when we talk about OpenStack, and we've had it many times this week I'm sure already, we're trying to sell agility into the business. We're trying to say to the large enterprises and the large corporations, actually this is what you want to be. You want to be this agile thing. You want to change all your processes. You want to throw them away. You want to become this. So what's the characteristics of the speedboat? Well, it's extremely fast moving for one. It can outrun a tanker. It's agile and can change course very quickly. So it responds to the environment that it's in. It's able to change momentum, change direction without too much effort. It's just the turn of a wheel essentially. And it does it quickly and it can respond quickly. That means it can react to whatever's happening around it. It can react to the way the water is. It can react to other vessels in its way. And it can react to weather conditions and things like that. There's a very simple and lightweight control structure in a speedboat. There's a stick to make it go faster and there's a wheel to make you turn. That's generally about it. But if you don't know what you're doing, you can cause quite a lot of havoc with those two controls. There's limited planning involved because of that lightweight control structure. It's very easy to change that direction. It's very easy to sort of maneuver it around. And it's managed by an extremely small crew. There's very few people have to fit in one of these things in order to get it to do what you want. You can have a single person running around in this. And this is, again, what we're being told by sales organizations that our business needs to become. If you're already a big enterprise, they're saying, become this small team, become this small thing. And it doesn't necessarily gel. These things are risky. I did have a video, but I don't think I'm allowed to show it, so I haven't. But it's very easy to sync one of these. It's very easy to go over a wave and roll it. It's not a particular comfy ride either. This thing will bounce around and you'll get thrown around inside it if you don't quite understand how to control it properly. So we can see the kind of comparison between the two. The large enterprise and the tanker and the small startup team that we're being told we need to become in order to be successful. So I talked about boats. What about OpenStack? That's what we're here for. So OpenStack is an enabler for that agile and dexterous team, which is the speedboat analogy. And it's something that we're being told that this is, if you get this, then you'll become an automatically an agile organization. You'll be able to deliver immediately and fast. And you'll hit all your targets. OpenStack very much allows us to focus on time to deploy and react to things. It's talking about being able to deliver VMs or compute resources and storage resources and networking in an extremely rapid manner. The focus isn't on stability. Anyone that's run a large OpenStack cluster will understand that painfully. There's limited rigor around it though. You go into the horizon or you go into the API and it's very easy to spin this stuff up. There's no hoops to jump through in order to get there. But it doesn't fit into price requirements. And the thing we forget is all of that stuff we talked about with a tanker, that all existed for a reason. It came about for a reason. Generally because the organization had felt some pain, lost some money, failed in a project and so put things in place to protect themselves against that happening again. So all of that rigor was born out of pain usually. And it's very difficult to get rid of something that you perceive to be preventing pain. And that's what we struggle in the organizations for. So we need to understand why those things exist. We're trying to get the tanker to use to act and behave like a speedboat. The trouble is if you shackle a speedboat to an oil tanker, it takes on the characteristics of the oil tanker. I couldn't find any pictures of speedboats. You have tugs I'm afraid. But you'll take on the personality of the tanker. It's not that the tanker will suddenly get quick. That's not going to happen when you shackle a speedboat to it. What's going to happen is you're probably going to sink the speedboat because it'll be pulling against the leash all the time. So what happens is your speedboat and your agile team that you now have, despite the fact you have the great tool in OpenStack, now has reduced speed again because you still have all the same rules and processes wrapped around it. You have reduced agility. It can't move in the same way because you still have to fight through everything that's been wrapped around it. It's still very unstable. Just because it's anchored to something that is stable doesn't mean it's going to, it's stable in itself. So the process of reacting quickly but an organization that can't react to keep up with it actually causes more instability and causes more problems. The direction of the speedboat is very much dictated by the tanker in this case. So your small and agile projects are still going to be forced into line with the rest of the organization. So the enterprise needs to change. We need to change that tanker into something else. And we're being told by the sales teams that what we need to do is change into the speedboat. We want lighter weight protocols for change. We want those small changes that can be measured and undone. This is all stuff that we've been hearing all week and things that OpenStack can actually do. But how do you get that big tanker from this large mess of rules to something a little more, a little more agile? So let's have a look at the release process. Anyone that sort of looked at platform as a service or DevOps or anything like that will recognize the kind of software release process we have here. And the little clocks are where we come up against time bumps. This is where we kind of slow down things and where this, our tanker processes if you like, actually bring the speedboat to a halt. So you can see we've got one there between design and develop, another one between develop and test, and another one before release. Now they're the brakes that were purposely put in to prevent the pain that we talked about earlier. That's what's stopping us just leaping off a cliff. And that's how businesses view this. If you go to an enterprise and try to get them to reverse some of this, that's how it feels to them. So what we've been doing is applying Kanban rules to this. So show of hands and to prove you're still awake and listening. Who understands Kanban? Who's heard of Kanban? Cool. Good. Fair of any. Excellent. So it's a process that essentially is limiting work in progress, right? So when you apply Kanban to something, you list the stages that that thing has to go through. So the stages of the pipeline and the workflow. And then you limit how many can be in any one of those individual stages. And the idea of that is it demonstrates to you how long something stays in that stage and now identifies it as a bottleneck. So if you start putting things through the processes, this process very quickly shows where those bottlenecks are and how they're slowing your process down. Because you'll end up with queues waiting to get into that process because things are going through it so slowly. The typical things are approvals and change advisory boards and that sort of thing. And I've got an example of where this goes particularly badly. So this is something I went through before I got to HP with another organization. They required an application. Nothing particularly clever. Fairly simple application. So a web server with a Tomcat back end. They wanted a virtual machine on that company's private cloud. So this is something that was running OpenStack. They installed OpenStack. They brought me in to bring up their cloud and they said right this is going to be great now. Here we go with our agility. So the user needed a user ID. Then he needed a business unit sponsor to actually approve the user ID. Then 19 needed to approve what he was doing. And then he needed to finally provision the VM. Then of course he had to buy the software which meant going out and getting quotes and payment and licenses. Roughly how long do we think this takes? So the user ID took six weeks from requesting it to actually getting it. So this is his speedboat going through mud at this point. He needed a business unit sponsor. That took another three weeks. He needed IT approval. He never got it. At the time when I moved on for that organization and started a new project they were still waiting for IT approval to spin up the first VM on the OpenStack cloud that was in there for weeks. The provision of VM itself would have taken five minutes. Had he ever managed to get that far? Obviously then to get the software we go through the usual quote process of two weeks. Paying for the software, it never happened. Nine weeks it took us just to get the invoice raised and we still never actually got it paid for. Deploying it about 20 minutes. So you can see where the agile bits are there but you can also see where the rest of the pain is. When we deployed it on a public cloud just to prove that the software worked it took us two days. That's from deciding which public cloud to go on getting the software and standing it up and actually having users on it doing something useful. So let's have a look at how we could have fixed it. What the organization then had to address and I came back to this organization and helped them do some of these things. And it's really simple stuff and we ran it through Kanban and we identified where these stages existed. The need for a user ID just to create something on the cloud when they already had Active Directory in there. So why not just link the two together? That was a bit of a no-brainer. The business unit sponsor, well you have to enable the users and trust the users if you're going to give them the power of agility and the power of a cloud. It's no good giving them all this power to stand things up very quickly and then taking away any control by saying but I have to get this one individual to approve everything you do. So what we did is develop sensible budget thresholds. You could request resources and services up to a particular limit and then once you hit sort of budget limits then you had to go and get approval for that. So what we're trying to do is take the things that we protect us from harm the things that keep us safe like we've talked about before but make them more reasonable and make them more meaningful in the new sort of more agile world. They needed IT approval, why? You have a cloud you shouldn't have IT approve anything. If you give the people the possibility to do something on a cloud then you should just let them get on and do it. If you give them the ability to break something you've probably done it wrong. Provisioning the VM, we stuck it at five minutes because it was fine. For the software side of things we implemented software catalogs so that they could select the software from a catalog themselves. As it turned out the thing that they were requesting quotes for and the things it took weeks to get a quote and even more weeks to actually pay for it when it eventually did happen they already had on a catalog they'd used it elsewhere in the organization so it would have been a simple case of going back to the original business unit that had this and using that process but because the catalog didn't exist and they weren't agile in that way they had no idea and then deploying the software obviously there's a bunch of tools you can wrap around that you can either have heat to stand up image is answerable and chef to provision the software and the licenses etc so we can we can speed things up and this was all about trying to make those those checks and balances still meaningful but a lot more rapid and a lot less painful. So we need organizational change to get these businesses to behave the way we want them to not just technical change when people get given open stack and told that this is something that's going to be solve all your business problems and give you the agility you need. It's you kind of end up in this place where if all you have is a hammer everything looks like a nail and that's that's not really working so we have to understand that enterprises are enterprises they're not going to change the personality just because we've given them a new tool we need to be mindful of why previous checks existed so as I said that they were there to stop paying that's not necessarily saying that they're all reasonable because people sometimes will produce resources for bureaucracy for bureaucracy sake I worked for a public sector organization in the UK putting open stack in for them and in order for me to purchase a single network switch I had to go through nine change advisory boards which we then expedited down to four change advisory boards they met every 30 days but not in the right order so it ended up taking us nine months so just because it exists to solve pain it doesn't mean it exists in a good way you need to ratify it and analyze it and sort of break it down to something that's meaningful and is useful for you you can break your organization down to smaller teams though just because it takes a large team to produce a bit of software it doesn't mean you can't start breaking that software down into individual components and this is where things like Scrum come in whereby you can break into the far smaller agile teams and develop and deliver software in a far more agile way and there's been lots of talks this week about continuous integration and continuous deployment so I won't go into the technical details here but you can start breaking your organization down into those teams taking a large software team and breaking them into individual components delegate responsibilities to the small teams though it's no good giving them the tools to react quickly if they have to ask permission every time they do deploy well-tested changes so introduce things like unit testing and the ability to report on that testing but in a manner that can be reversed so that can either be through a patch that can then be backed out of or what's more and more common these days are things like blue-green environments so what a blue-green environment is for those that don't know is you deploy into a pre-production environment you test it to make sure it's all as you want it to be and then you fail over the IP addresses and the load balancing to that environment and it becomes your production environment and you do the same thing again what happens then is if you hear an issue you just fail back to the other environment again and it's very easy to reverse it was originally called red-black because it came from Netflix but the enterprise doesn't need to be a speed but we don't need to change an enterprise into this agile thing that sales are promoting for us all the time but at the same time we do need to move away from the ideology of being a tanker and this slow moving thing so we need to compromise so what we're actually looking for is one of these thank you any questions if there are any questions then there's a microphone around nope great thank you very much