 Alrighty. I think the light's coming on means it's time for me to start. And so, thank you for coming. My name is Mark Baker. I'm giving a talk here called Understanding Where Value's Created in Your Business with OpenStack. And the kind of basic premise for this talk was, because I work for, in fact, let me put this slide up. I work for a canonical company behind Ubuntu. I'm the OpenStack product manager. And I see I've been coming to these summits for quite a while and worked with many customers who are deploying OpenStack and have seen lots of behavior where people are investing lots of time and energy into OpenStack. And that's great helping further it. But I aren't necessarily convinced that they're helping move their business forward. Not because OpenStack can't help people move their business, but because they're expending lots of energy in certain areas which may be spent elsewhere to help their business. And so that was part of the motivation. It's not a technical talk at all. It's mainly about how, I think, you can look at value and how technology can help that value and how you can channel your resources appropriately. So as I say, I'm the product manager for Ubuntu OpenStack. My background is sales engineering, system administration actually to begin with sales engineering, then doing some marketing stuff. And I rarely get to do anything else now other than look after my children. So who can have a stab at what the greatest human instinct is? Sorry? Death? I guess that's inevitable, right? I'm not sure it's something that we instinctively strive for, but any other suggestions? Fear. Sorry, fear was that one? Yes, survival. I think those are all good answers, right? But to a degree, and we can certainly argue this out or discuss it offline if you like, but it's doing that which is familiar, right? So it's behavior, doing regular things, things that you are used to doing. And routine is the enemy of time, right? When you get into routine things go very, very quickly. Time goes very, very quickly, but we all kind of get comfortable with routines because we know what we're doing and we can't mess it up too much. And I think this conference, the summit rather, is an awful lot about behavior, right? We are here because we want to learn from other people and change our behavior, but that can be hard, learning can be hard. We want to try and influence the direction of OpenStack, get other people to change their development behavior. And we're also trying to understand what cultural behavior changes we need to make to be able to take advantage of this new way of thinking, this new type of technology. To kind of illustrate this point, right? I don't know how well that comes out in the picture. Is this kind of question of how do you train an elephant to be secured to a post, right? And the answer to that, does anybody have an elephant? No, so the answer to that is that when the elephant is very young, when the elephant is very small, they use a big, thick chain to chain it to a big, thick post. And the small elephant, the baby elephant will try to get away, but it can't. And they'll keep doing that until it basically just gives up and accepts the fact that it's changed to a big post and it's never going to get away. And then by the time the elephant grows up as it goes through, it's, I don't know, whatever the equivalent of elephant teenage years are and grows up, it's developed a sense of learned helplessness, right? As long as it has something tied around its leg and that thing is tied to a post, it's not going to go anywhere. And it's never even going to try because it tried for years and years when it was younger and it gave up because it never went anywhere. And so thus you can see elephants tied up to very small trees with bits of rope that they could easily pull down and walk away. But it's this sense of learned helplessness. And of course, that's how many of us in our organizations are, right? And the trying to break away from that, change that behavior is very, very hard. We have that, it's almost like the safety blanket if you like, that reassuring comforting thing that's chaining us and keeping us doing what we've been doing for a long time. So let's talk a second about strategy. Who has an IT strategy, business strategy? Nobody? People have come here to get one. So I think everybody has a strategy about how they're going to use technology. Every business has a strategy about, or thinks they have a strategy about how they're going to take their business forward. But I don't know if people have genuine strategies. What we see is an awful lot of jargon, right? And if I set this up right, we should hopefully see this sign, right? The strategy jargon generator. So we go and generate a new conversation, copyright to the website this is, which is very, very good. But a lot of people will have strategies that are based on this. You know, we're going to differentiate our opportunity, mis-approach our challenge operationally, and achieve whatever that is, our market leading performance deliberately, right? And we can carry on generating strategies like this. And we went and edited the words, which I won't do now, but changed some of those words to include flexibility and agility and operational excellence. We could probably generate strategies that would be applicable to all of us and we'd nod and say, yeah, we're going to do that. So an awful lot of what people have about strategy, I'm trying to find my presentation again, an awful lot of what people have about strategy is kind of the what and the where and the how. A lot of people have an open-stack strategy, right? And that open-stack strategy will look, if we start with a blank canvas, we'll say, okay, the strategy is going to begin with a POC. We're looking at then moving into deployment. We'll have sets of app migration. We'll look at building and buying various components in and servicing applications on top of that. We'll be looking at getting support processes in place, right? And all of these things are very good, what, the where and the how, right? Very good at saying this is how we're going to be able to have an open-stack cloud in time. What they're less clear about is the why. Why is everyone doing open-stack? Well, a cynic, not necessarily me, but a cynic may suggest that because everybody else is doing it, right? You know, you look like me. I like what you do. I'm going to do it myself. Because it's cool technology, right? We're technologists like all of us are to some degree. The fact that it's new and it's interesting, it allows us to do some interesting things makes it cool, right? The sense as we walk around the summit over the last few days feeling that we're part of this kind of, you know, technical gang or technical club, right? We understand these problems that other people don't and we're the ones that are helping fix it. That all goes to, you know, to make us feel good about ourselves and make us feel good about the technology. But also, this is a big deal, I think, in the open-stack world, right? Because it boosts my resume. And we see this all, certainly in, say, working with Ubuntu, I see this all the time when we're going to talk to customers where there's sets of operators and devs in a room that are really excited that they're going to get to work on open-stack, right? Because it's going to boost their resume and they can go off into the city and earn thousands of dollars a day or whatever it is, right? And in fact, I remember going back to San Diego. It was the open-stack summit in San Diego and I had somebody from Red Hat came along and thanked me for Ubuntu doing so much good work with open-stack because it meant that Red Hat was now getting into open-stack and he got a chance to go and work on open-stack and he felt that was going to make him very employable elsewhere. So, although he's still with Red Hat, I have to answer that. So, the other bit is case study logic. You know, if a company X does Y is successful, if I do Y, I will be successful too, right? And there's lots of, you know, a lot of the management books you buy will talk about those great sort of pioneers if you like of certain types of business model. And, you know, you look back over time now, it's quite amusing. You can go and read case studies of people like Blockbuster and Kodak and AOL and Sun Microsystems and all the great stuff that they did that you should do because you'll prosper like they will. So, but, of course, it doesn't necessarily, one, you don't necessarily want to copy them, but two, it doesn't necessarily follow that if you do what they do you will also be successful unless your business is exactly the same in which case you compete with that company and therefore you don't necessarily want to copy them either. So, again, I think a lot of people are doing open-stack because they see other people doing open-stack and being successful but I'm not sure that's the right answer either. So, I think part of this is caused by a lack of situational awareness, right? What is it that open-stack means to me where my company is today? And to be able to do that you need to, I think, have a clearer understanding of where you are. Most of us know where we are by looking at a map, right? Or a GPS on a phone, but basically a map. So, and we don't do a lot for a lot of mapping in this world today. So, I'm going to take a little time to talk about value chains and value mapping, which is a concept actually that's been developed by an ex-canonical chap called Simon Wardley, which is, I think, the kind of the interesting piece. So, most of us are looking at open-stack or hoping that open-stack is going to be able to enable us to do something more cheaply than our competitors, right? We may not necessarily think of it as being more cheaply than our competitors. We may think of it as being more cheaply or cheaper, I should say, more cost-effectively, if I was in marketing, more cost-effectively than the other system that I'm using today. Or we may be looking at bringing new services to market faster than our competitors or faster to market than we are currently able to do today. And again, I think most of us would agree that, you know, open-stack is either going to deliver both of these or one or the other, depending on how you want to implement it. Allow us to do something more cost-effectively or allow us to do things faster, maybe it would deliver both and we'll be happy. So, why do we use open-stack? You know, is it going to really deliver those things? Well, there's a gentleman called David Rogers who developed this theory, I can't remember where it was, 50s or something like that, about the diffusion of innovation. And that most innovations will follow this standard adoption path, this standard adoption cycle. So, innovators, the people that are leading edge with this, about 2.5% of the overall usage will be the beginners, then we move it to early adopters of 13.5%, then the early majority, and obviously we're entering the middle of the bell curve here, the later majority that come along and then the laggards, people are very slow to move in the end. And so, it doesn't matter, this theory can apply to software, but it also can apply to just about any other innovation, right? So, electricity, for example, or lighting, or radio, or TV, or any of those kind of things. Anyone got an eye watch? No? No one's running up to that. Okay, we're missing that 2.5%. That was going to be my winning example, but clearly a fail. And I think, where does OpenStack sit on that curve today? I'm quite sure while my build isn't working out, there we go. I think we're kind of there in the early adopter phase. Anyone agree with that or disagree? No? So, I think we're still early adopters, even though we're 6,000 people plus here this week, and there's a lot of big company names, you know, OpenStack's still a very small part overall of how people are managing their infrastructure. Certainly people running in production are a very small part today. So, we need to think, but we still need to think why are we doing OpenStack, right? What value is it going to bring? I hope it's going to bring me cost benefits. I hope it's going to bring me agility. But why do I need OpenStack to deliver those things, right? If I want cost benefits or agility, why is OpenStack going to do it versus something else? Well, let's look at this, the adoption curve. And I didn't make this point actually. The yellow curve, so the bell curve shows obviously how people are adopting technology over time. And, you know, the yellow curve here is showing how, in terms of the total number, the total percentage goes to 100. And so, as we move towards the right-hand side, as you're looking there, we get towards 100% of adoption. Let's hopefully, if I got this right, break this down. So, in that beginning timeframe, apologies, you can't see the line very well there. Try and do an edit in real time. Is that better? Yes. Good. So, looking at that line, you'll see that in the beginning is the genesis, right? And this is where they, you know, in the OpenStack world, this would have been NASA and Anselab and people putting this together, right, the genesis. And so, the early adopters, the innovators that are taking that on, as we move forward, then we go into custom products. And so, this was still back in the early days of OpenStack, people taking packages, you know, certainly in Canonical and Ubuntu, we were starting to package OpenStack, put that into archive, but putting it all the pieces together to create an implementation required smart people with experience to do that. So, it wasn't a product. It was a set of packages, but not an integrated product. But that's the next stage in the adoption cycle, right, which is where you have products. I think we're just kind of getting there now in OpenStack, right? With OpenStack distributions, creating products that are targeting certain people, certain use cases in certain ways. And then, the final stage is commodity, right? And this is where it doesn't matter what shape, size, color, flavor of OpenStack, you get it's a commodity service. It's easily installable. It's easy to run. You can switch between vendors seamlessly and easily, and it's a commodity product. And of course, there's a great many examples of commodity technologies out there, whether it's, you know, Intel-based servers, you could be able to, I'm probably going to upset people from HP or Dell now, but you should be able to switch between those Intel vendors relatively easily and get the similar level of service. It shouldn't matter to you whether you're getting your power from one power company or another, it's still power and it's still going to work. So, those commodity products enable you to be able to negotiate much better on price and deliver services more cost-effectively. And as I say, I think OpenStack's kind of here at the moment just moving into that product space. There are products out there that will work, but you're still going to need expertise and smart people to get it running. So, the challenge for us is how we move it up to here. And this is us as an OpenStack community and an awful lot of the talks that we have today about how, you know, this week about improving it to deliver greater functionality, improving it to deliver simplicity of installs, simplicity of management to all of those other pieces. And we as users are very interested in that because the faster it gets towards being commodity, the faster we're going to be able to derive more value from it, right? We're going to need less expensive people or fewer expensive people, I should say, to be able to run it and manage it. We should be able to negotiate between the different distributions and get a good price and get a good deal. So, that strategy, you know, I want to be able to do it more cheaply than somebody else. I want to be able to launch a service faster than anybody else. I think these are very good reasons why people are doing OpenStack. But let's add another dimension onto that. So, I mentioned value chains earlier on. And this is a value chain for a relatively simple web service. And we start at the bottom. In order to be able to deliver that service, we're going to need power. We're going to need some servers. They're going to be co-located in a data center. We're going to need a platform of some shape or form of description to be able to develop that platform or add value to it. We need development tools. From that platform, we'll have a web service. And just simply, I've got, you know, payments and a banking system. That web service is obviously going to generate money for us in one way or another. And then the secret source. I tried to think of a smart example here, but I couldn't, so I thought secret source. But you could, that web service, I don't know. You could think of Airbnb or whatever. I don't know. But a web service that is adding value that nobody else is offering or very few people are offering. And of course, the closer we get towards the top, the greater the value to our business it is. Now, even though we wouldn't necessarily be able to run it without power and servers and data center and dev tools and all these other pieces, the value is in the secret source, right? That's the bit that differentiates me running this web service from somebody else that's running that web service. We've got customer needs. As a customer, I'm a customer of the power, a customer service. But then towards the top of this, I'm a supplier. I'm supplying my secret source via my web service to end users or customers. Hopefully that's relatively easy to understand. So if you start to map that against the diffusion of innovation, the stages that people go through as we're looking at this technology, it allows us to be able to, if I've got this right, let's simplify it a little bit, because it just illustrates the point a little better. But let's take away those outliers, the pieces that we need, the servers and the power. Sorry, what was it previously? Dev tools and servers, the banking system, right? Those are our kind of utility providers. And if we start to stretch it across the environment, we can start to map that value chain across those different strata, if you like. So the commodity piece is payments, right? There are very many different ways of processing payments, managing payments. It's a commodity service, even though you'll get charged for it, but you can jump between different payment providers pretty easily. The power, as I already said, is a commodity, right? But as we move further up towards the top in that value chain, the platform has more value, right? And likewise, the web service. And at the top, the secret source is where all of our value lies, right? This is the differentiator in marketing speak. So we map those across these different strata. We can say, well, these things are commodities, so we just go to utility providers for them. These pieces are things that we should be looking at products for existing products. These pieces are custom builds, or even, depending on our secret sources, it might be the genesis. It might be the innovation. We might be the only people in the world that are developing this, right? And so the key here is choosing the bits that we place, right? How do we do them? The utility providers, well, we should probably just outsource that, right? Very little margin in me managing that myself. No point in me generating my own power. That's just expensive. Little point in me managing my own payment system. I might as well just go and let somebody else do that. And likewise, data centers, unless you're very big. I know there are very big people here this week. Unless you're very big, just go in somebody else's data center or rent a bit of space, right? And benefit from the economies of scale that they can provide you. So outsource a lot of that. The product pieces go and buy ideally off the shelf. Yes, you may have to pay some margin, but go and buy off the shelf or obtain off the shelf some products. You need to necessarily buy them, and I'll come up to that in a second. But the secret source is where you want to put your resources, your in-house resources, your smart developer resources on developing that piece. This is all making sense very early. Anybody disagreeing with us? No? Good. So I think, again, the platform in this context, in this example, would be open stack, right? And part of the challenge today is because an awful lot of open stack has been custom development, and I see an awful lot of very big customers that are still doing a lot of open stack development. Open stack development is great, and I'm very glad that a lot of those big customers are doing so. But an awful lot of them are developing open stack in-house to suit their particular needs, and not necessarily pushing all of it upstream. Some of that's because they want competitive advantage. Supposedly competitive advantage. Some of it's because they don't know how to push it upstream. Some of it's because they think it's only relevant to me. It's not going to be relevant to anybody else because it's to work around our own broken in-house IT systems. But I think that's a waste. It's a waste. I'll come on to that a little more in a second. The value, as I say, is all at the top. As an open source guy, I think the, sorry, the shading hasn't come out pretty well there, but the, those mid-tier components, those products should be open source, right? So even though you're getting them as products, and you may even be buying them from someone, the fact that they're open source is going to help you push them in towards this commodity section faster, right? Open source generally is developing fast. Open source means everyone has access to it. Any competitive advantages between different providers of open source technologies are relatively short-lived, right? So I think these areas should be open source. So value, the secret source is that business value, right? That's the thing that allows you to charge your end-user customers money. That allows you to differentiate from your competition. An open stack is that product. If you're doing it right, if it's in that mid-tier, and it's a product, is that product that allows you to be able to get faster time to business value? It should be. Anyway, the speed is the important piece for a lot of people. I think it was a couple of summits ago, wasn't it, where they had, if you have to try and make that trade-off between cost, speed, or was it availability, take speed every time, because with enough speed, the other two become less important. And so I don't know if that's true necessarily, but certainly having speed, being able to deliver things faster, in my experience talking to customers, is what they see greater value with open stack than perhaps cost reduction. But measuring value is going to depend very much on how you, as an organization, your particular state and the particular things that are important to you. So I think the time to value reduction, and by that I mean not reducing value, but I mean the time to business value, being able to implement a new service quickly, whether that's external and you're charging for it, or whether it's just making your developers or in-house more efficient, that time to business value is one of the key advantages here. It can be cost reduction, but then point three, and again we see this a lot, is attracting or retaining developers. There are open stack projects out there that are specifically to ensure that the company, X, is attracting or retaining what they see as key operational staff. They don't want to go and lose those people who want to go and work on a fancy new open stack project somewhere else. And even though I think there was it in one of the job board surveys recently that the highest-played developers in the world were on Wall Street programming in COBOL. Most people leaving university right now or leaving college right now want to work in some exciting DevOps startup-like environment, which means if you're a dusty old corporate, you've got to try and present yourselves as being an exciting, interesting place to work and open stack can be one of those ways. So maximizing value. If you're not selling open stack but you're spending a lot of time developing it for in-house use, you're wasting resources, I think. I don't think you're making best use. Because those pieces, they should be products and should be focusing on the value that you're able to deliver higher up the chain. So that means focusing developer resources on the new technologies, the bits that are going to make a difference to your business. And the bits that are going to transition to commodity quickly. And so back in my diagram, excuse me, flipping back so quickly, those web services, those platforms that are open source will transition to commodity quickly. That's where you want to spend less of your resources and keep focusing higher up in the value chain. But this doesn't mean that you shouldn't contribute to open stack, but contribute to open stack as part of the community is hopefully because then it is going to transition to be going commodity faster and hopefully it's going to deliver more of what you need faster to enable you to be able to deliver that secret source, that high value applications, more quickly for less money. It's very difficult though, I see. Very enthusiastic teams in organizations that are developing open stack. They may well be doing it on Ubuntu. They may be using our packaging but then doing other bits around the edges and tweaking it. And you think, you don't want to discourage them from being excited and working on open stack but at the same time, you know, it's dubious to whether it is delivering value for them. So that was, we've gone through that a little quicker than I thought, but that was how I wanted to try and position this. Look at value chains, look at the pieces of your organization, understand where the value for your business lies, and then choose which pieces you outsource, which pieces of products and where you actually spend your developer time. Does anyone have any questions or comments? Yep. Do you mean in terms of Chargeback, for example, Chargeback models or that kind of thing? Or, okay. Well, I know that there's, there are definitely companies looking at that and whether that's via app catalogs, for example. So you need to be able to go and get XYZ service as an application. I think Murano was trying to do some of that, but then there are third-party orchestration tools or deployment modeling tools that will offer similar app catalogs to be able to do that. But I think you kind of raise an interesting point in that an internal IT department is often competing with Amazon, right? So it has to be able to both compete cost-effectively but also in terms of feature function-wide, right? Make it easy to consume and provide a lot of those features. And so, yeah, I think absolutely. Maybe as a community investing time on how that's where, you know, often that value is delivered, right? In the application layer, higher up the stream. Maybe, yeah, maybe we need to look at more of that. Right. Yeah. And so I think that, I mean, there's two answers, well, there's multiple answers to that, but let me pick on two points really. That any change from this needs to be, even though OpenStack often starts bottom-up in an organization because it's developers that have easy access to it and playing with it and see that it can help them and solve some problems or they want to bit a resume or whatever it is. But in order to be successful, it needs to be driven very much top-down, right? Because only top-down can you make people make the changes. Often in organizations, storage, networking, computer, different, you know, different managers, they're different departments, different groups. And they really like talking to each other and then you have DBA teams and these things too that add additional complexity. The only people that can force them together and say you need to work it out is executive teams, right? It's management teams. So why do you need to have that buy-in? And two, the kind of the funding model, I think, changes here, right? So organizations typically are very sort of verticalized in how they charge. You know, if you want space on this, then you're going to have to pay for it. And this is why you see in investment banks, for example, different, you know, equities or fixed income or whatever it is, applications have their own machines, have their own environment because they're able to then accurately measure the value it's delivering to the business. It's not a shared resource, although I know that that's changing a lot of the time. So you have to implement not only top-down push but also have sort of changed some of that structure from a corporate mindset to do that. Good. Any other questions or comments? Yes, sir? No, it's okay. I can hear. I'll repeat the question if maybe. Yeah, so... So yes, great questions. So I think, I mean, the time to value, if you like, is just being able to launch services faster. And even... I won't mention the customer. I was talking to a customer just very recently this week. They're saying that to be able to launch a VM takes them a day, but to be able to configure all of the networking components around that through the various teams can take weeks. So it can still take four weeks to be able to get their application set up with the right config, the networking config. Now, I know this is the ideal world and we don't live in the ideal world, but when you have software-defined networking and the right tooling to be able to allow people to deliver that much faster, then that time to value should be reduced, right? Whether it's going to be reduced in minutes, I don't know, but to be able to launch a VM and have that network configured dynamically via some smart soft SDN tools, I think we should be able to do... The cost is still a big issue, right? Yes, you can get... There's no such thing as free, even though we talk about free software, there's no such thing as free because everyone's time costs money. I think it's always difficult to say, and I will avoid that conversation as much as I can about is OpenStack cheaper than VMware or another different technology, right? Because your mileage is always going to vary and it depends on the use case. If you've already got operational processes built and designed around tools from others, then it's a very hard discussion to win over, right? I think you can say, though, that very often people will look at the migration cost. If I'm going to move from application X onto a platform Y, as it were, then the migration costs are prohibitively expensive. I may as well just stay where I am. And that may well be true at a kind of spreadsheet level, but you need to view that migration cost as being almost the cost of lock-in rather than the cost of migration, right? Because otherwise you'll stay on a platform forever. And that may make sense for you strategically, but don't view it as being the right, necessarily the right way all the time. Great. Any other questions? We're good? Thank you very much.