 So I think it's 11 o'clock, so we think we can start, right? So welcome, everybody. My name is Florian Ohtel, and I'm HP Cloud Services Technical Sales for Europe. And I would like to welcome you to this talk called OpenStack to Enterprise, Keep Calm and Boldly Go. Not sure how many of you here in the room were present at the last design summit. But during that summit, my friend and colleague, David Johnson gave a talk entitled Enterprise to OpenStack. Here's what you're missing. And during that talk, Pete went through all the features and functionality that we have been hearing from our enterprise customers that OpenStack is missing, and thus preventing larger adoption of OpenStack by those customers. The purpose of, in the meantime, again, six months ago, things moved very, very fast. And the technology has made tremendous effort in overcoming many of those objections. However, life is never perfect. And we will ever hear some sort of objections in some way, shape, or form of why things are not happening. So the purpose of this talk, like the cheesy title suggests, is an answer to that talk, and that presentation, and share some of the lesson that we have learned in how to position OpenStack to our enterprise customers, and how do we overcome those objections in practice. Before I even go into the presentation, a few kind words of warnings and biases, like the name of this track suggests, which is business value. This presentation is not about technology. Here at the summit, we're very fortunate to have very deep technical sessions out there. This is not one of them. This is about OpenStack making hardcore business sense. The second one is that I'm sorry to disappoint you, but this will not be a glitzy PR marketing exercise where I will have enterprise customers coming on the stage and telling us how wonderful life is with OpenStack and how they have seen the light. This is, unfortunately, real, neat, gritty, unglamorous, real-life examples that we have learned during the two years that we have been using OpenStack. And on that is a bias warning. Again, as I'm working for HP Cloud Services, which, as you may know, is one of the largest OpenStack-based public cloud service providers out there, my talk has a natural cloud service provided bias to it. While I will try to address other OpenStack usage and environments, again, that sort of bias will shine through, so again, you have been warned. Last but not the least, I'm a very big fan of few MacLeod cartoons and Gaping Boyd. And maybe we will see quite a few of them coming up. So before we delve a bit deeper, a quick level set. Does anybody in this room not recognize who this guy is? So anybody who doesn't know who this guy is, quick show of hands. Thank you. So for those of you who don't know, this is Geoffrey Moore, and he's a well-known venture capitalist from Silicon Valley. And Geoffrey Moore wrote this book called Crossing the Chats. In this book, Geoffrey Moore illustrated a process called Diffusion of Innovation, which is a process first researched and identified by a guy named Everett Rogers, which showed that the rate of technology, or quote unquote, innovation is adopted in a marketplace, follows very distinct patterns, namely that it is adopted in a bell-shaped curve. And the adoption goes through very distinctive phases of types of people who are adopting the technology. And what Geoffrey Moore showed in his book is that, and relevant to our subject in OpenStack, is that when we are marketing a particular technology, we need to be very mindful of the different types of customers that are in the market. In particular, the fact that between what we have there on the left are the early adopters and visionaries, and the mainstream market are fundamental qualitative differences that we need to be very mindful of, hence the term chas, and how do we cross it. Second quiz, and I'll try to make this easier. Anybody who doesn't know who this person is? Quick show of hands. OK, so Professor Christensen seems to be a bit more famous, and I even make it easier. Put his names in the back. This is Professor Clayton Christensen, and he wrote this book, which is actually a series of books, but arguably this is the first and arguably the best in the series. And what Professor Christensen showed was that he analyzed how different technologies, and quote, unquote, innovations are adopted. And he came out to the conclusion that there are fundamentally two types of innovation, one which is called a sustaining innovation, namely making an existing technology better, better, faster, cheaper, and a different type, which is, excuse me, called disruptive innovation, which is a new technology, or a technology which is used in novel environments or in new ways. And he analyzed the dynamics between the two. So if we delve a bit deeper into that, and we use Professor Christensen's innovation model, and we see that the technological progress due to sustaining innovation and technological progress due to disruptive innovation and the marketplace in a battle-shaped curve on the right side, and my venture, I guess, where exactly OpenStack would be on the horizontal axis. Any guesses? Thank you. I would argue that we are, based on our experience, somewhere between point A and point B. In other words, OpenStack as a technology that is today, it is an emerging technology that is a low-end disruption that appeals to some sort of customers, but not necessarily so to a large group of many others out there. So how do we position OpenStack to enterprise, which by definition, again, are very large customers? And like Jeffrey Moore showed, it's a very large majority out there. So one way of how not to do it is this. When we go into a large shop, or a very large shop, and we see that after some analysis and discussions, we realize that their technology, their process, the culture, the whole thing is dying, and they will die the horrible painful death they will deserve to die, we don't necessarily quite put it that way to them, because it doesn't help you and far more importantly, just annoys them. Because as the joke goes, in the long run, or in the very long run, we are all dead. It's all about times and timelines, and how do we position when and in which terms. So if this is not the way to do it, how do we do it? So let's take a bit more serious look and make the parallel between OpenStack and Linux. And again, it's a dreaded comparison. But what I mean by that, it's purely as a low-end disruption platform, right? And I'm not sure you have seen the keynote session this morning when they've done the same parallel between Linux and OpenStack, and how the adoption proceeded in the marketplace. If we are making that parallel, how Linux was adopted by the mainstream market, and we focus only on how Linux was adopted on the desktop. Anybody remember that this will be the year of Linux on the desktop menu? How many years we heard that? By the end, the answer was it will be the same year that Duke Nukem Forever will be released. And the year that it was released, it was so outdated by the sunset of the day that the only people who bought it were only for nostalgic reasons, right? So what I would argue that what had to happen for Linux to be adopted by the mainstream market was that Android had to happen. In other words, it took a vendor like Google, take the platform, bundle it with a hardware, but far more importantly, with a use case and the application, and offer it in the end-to-end value proposition that appealed to the marketplace. In other words, made the underlying platform irrelevant, make it and address all the concerns about security, manageability, affordability, and so on, and offer a value proposition based on that platform. And in other words, the platform was only the enabler. And to me, when I watch Jonathan Keynote yesterday, I absolutely loved the examples that we had with Best Buy and Comcast. Anybody noticed that during that blinky lights, was there any sign of open stack? To me, there wasn't, right? And that's exactly the whole point, right? The underlying platform was made irrelevant, right? As long as it fitted for purpose, it only enabled downstream value, agility, how they go to market, how they do things, and so on and so forth. So it was only the underlying platform was only as an enabler as a, depends on how you look at it, downstream or higher-level value based on that platform. And before you argue that Linux has very little to do with Android, I will say that's absolutely right. It has as much as OS X has to do with free BSD, right? The underlying platform is irrelevant as long it sustains a very clearly articulated use case and application and environment. So let's delve a bit deeper into that. If we turn to Jeffrey himself, he makes a very clear point in his book that applications have much easier time to cross the chance, in other words, be adopted by the industry market than platform, Ergo, OpenStack, and Linux, for the very simple reasons that applications can be articulated in terms of end user needs. He goes even further to say that to accelerate adoption of platforms, and that is a literally quote, if to accelerate adoption of platforms, vendors must clothe them in applications clothing. Or the way that I like to joke about it in the wise words of London Underground Train operators, please mind the gap between the application and the platform as you board this train. Right, so how do we do that? So even if we manage to take a platform like OpenStack, articulate in terms of applications and end user needs, and we try to position in an enterprise, we run into this problem. Namely that enterprises, by their very definition, are large, very large, or humongous organizations, and as such, very slow to change. Or putting it differently, due to sheer physics, change takes a very long time to propagate throughout the whole organization. So even if we have end user, and we empower end user, and these users have the authority and the capability to drive that change, by and large, or at the very least, to a good extent, they are prisoners of the system itself. Right, so if we position that, we are at risk going into this problem. Namely that if we take the platform, articulate in terms of end user needs, we're able to drive the adoption. In the organization at large, we have a very high risk into having technology for technology's sake. A pitfall, as I would like to call it. In other words, technology is accepted somehow grudgingly by the enterprise, by the organization, and it starts spinning and people are doing things, and they do stuff with it for personal career reasons, for just playing with technology or any other non-business reasons out there. And this is a point that Jeffrey Moore makes very clear in his book, that we have to be very mindful of that risk. And what we need to do is that when we articulate that value, we have to have a very clear roadmap with milestones, and at each milestone have the buying in terms of commercial commitment from the organization at large, and have closure beyond that so we can move on to the next phase. However, believe it or not, that's still not enough. Well, for this particular reason. Because if we take a platform, articulate in terms of applications and end user needs, that have the capability and authority to drive change with clear business value, we need to be very careful how we articulate that. Because what happens is that the ruling orthodoxy or what I like to call the corporate antibodies will realize at some level of consciousness the disruptive potential that this innovative low end disruption pose to the status quo, and they have a natural survival response. In other words, try to kill it before it even has a chance to prove itself. Or the more insidious version of it, namely co-adopted and diverted to their own needs and pervert the direction that the technology is driving. And what we need to do in that case is that we need to be very mindful of that, and we need to use terms and vocabulary that the ruling orthodoxy to put it that way accepts and understand. And then we need to be, we are very careful of seeing which narratives and which terms are used to be, those ideas to be played back to us. The reason for that is that when that narrative changes, that's a mental signal that the mentality has changed and the stoplight has switched to green and we can push further on. Of course, until the next stop, which then we have to do it again. So, enough with theoretical examples and let me go to a particular with concrete examples that we are using. So, here are just a straight out excerpt of the use cases that we are enabling on our platform and in particular case with the partners, with our ecosystem partners which are enabling particular use cases. So, we have an archiving and backup and collaborations with people like Panzer Riverbed, the database and archiving, data sacs, my par, Cassandra, Hadoop, all the stuff that you would expect to be there. Platform as a service from like Giga Spaces, Cloudify from our dear friends from Giga Spaces, Cloudbursting which was mentioned by Saad this morning which is fundamentally a way to instantiate workloads either on the existing technology that's on existing hardware that is on site and or in other capacity resources that are out there. Or for example, an example which is, to me is very telling is Enterprise Dropbox, right? So, for me, the reason that this example and again, the name of the innocence were removed from the slide is that we're seeing Enterprise realizing the viral adoption of technologies like Dropbox and because they have clear business reasons why they need to have some sort of manageability around this because they have governance risk and compliance reasons and if they don't do that they go to jail, right? They need to try to manage that while at the same time they need to navigate the fact that their end users are voting with their credit cards and tell them to just get out of the hell out of the way because they can get the resources somewhere else without the six months overhead that IT has, right? So they need to manage this delicate balance between staying out of the way of the end users and just not be a hinder while at the same time having some sort of governance, some sort of manageability in place, right? And that to me is a very nice example how people are trying and using technology to do that, right? And OpenStack with use cases to try to navigate that stormy waters. Now, a few words of warning. What we have seen is that with such or the technology like OpenStack that is changing such a rapid pace, the rate of mortality among all the use cases up in application is very, very high. So even if we enable two dozens of use cases in application over platform due to sheer physics and the way that the dynamics of the process, we will get traction. We will have the, we're having the 80-20 split, right? In popular vernacular or more potentially said the long tail distribution where any real traction is actually from a very small or a very small set of use cases and customers with a long trail of other stuff that's out there. So speaking about a great idea, let me tell you another great idea, how to get rich quick or how to pull an Android in seven easy steps, right? We take OpenStack, we add our secret sauce, we QA that on a set of reference architectures, from there on we deploy into production, whatever production means to you, from there on pushed out of large muscle overjoyed customers, the lesson that you learn, you contribute back to OpenStack, but please not forget to keep the secret sauce. And what this process we are joking about, what this process, this continuous integration, continuous process shows, is that we are having a tight coupling between end users of the technology and the technology itself. And this is a book, this is a point that Geoffrey Moore makes in his book very clearly in the fact that for such emerging technology for low end disruption, we have to have a very clear and conscious focus on a small subset of customers and use cases that we are following and enabling on our platform. The reason for that is that due to the dynamics of the mainstream market is, and everybody's looking for the big name, Marquina, before they jump into the pool themselves, right? Somebody else has to jump first. Having recommendations and having some sort of footprint that we can use to bootstrap the rest of that particular segment is very important. And this was dealt a bit more into an article from Harder Business Review from January 1993 by Trissie and Birzema, which turned into a book. And in the article in the book, what they showed, what Trissie and Birzema showed, was that there are fundamentally three different areas that an organization or a company can focus. The first one is Operation Excellence, which, as the name suggests, is improving our internal operations and efficiency to make sure that we are structurally in the best way possible to address a particular market. The second one is product leadership, which is, again, as the name obviously says, is having the best product for that particular market and that particular segment that we are pursuing and customer intimacy. In other words, having a very tight coupling between the technology and the customers. And based on our experience, I would argue that customer intimacy, we learned the hard way that customer intimacy was the most important to us. So while trying to do what the cartoon says and try to hug your customer every day, might not be so popular or even get to a restraining order for such a fast evolving technology, but in having a very clear focus on customer needs and expectations helped us tremendously in crystallizing which priorities, which feature are bringing to market, when we are bringing to market, and why and in which order. And if we look a bit deeper into that process, a fundamental aspect that we have learned of that process is that it has to be a true two-way dialogue, true collaboration, a partnership with the customer. Because again, as we said earlier, the technology is evolving at such a rapid pace. We need to be as, quote unquote, secret sauce in the middle. We need to help the customer navigate and absorb all that rapid change of things that they need to absorb and implement and how to do it, when to do it, why and so on and so forth. So we need to help them mediate and navigate all that rapid change and smooth that roughness that we're still seeing for such an emerging technology. And we learned again, it's called bleeding edge for a very, very good reason and not everybody has a reason or willingness to be there. And we have to understand why and focus on those that do and help those who don't. Another important point there, which is we learned it also the very hard way is that it has to be a two-way dialogue. And we have learned the hard way that some things were not exactly as we expected and some other things were absolutely that wrong about. And in that situation, it was an important lesson to not to stand in our own way, right? Realize, have the intellectual honesty that we were wrong and we need to press the reset button, start again and look things fresh from again having customer needs and expectations first and foremost. Now with that said, there is co-creation and there is co-creation because this cartoon says the different types of co-creations out there. So let me try to give you two examples, practical examples of customer dialogues, a bad one and a good one, right? Bad example, right? Custom represents it for customer calls and said, we want an exchange based back of an archiving solution with five lines reliability. And you call me because it's in the cloud and it's cheaper and I'm trying to gingerly explain how the technology works and there might be other solutions out there that might better suited for purpose. But then they interrupt me a half way and said, well, your competition can do that. Why cannot you? At which point I dropped my head and realized they had the rolling orthotics and they have the paycheck, arguing with that does not necessarily end up well. And I dropped my head and send, give them an ice-cazi gateway to my object storage with redundant hardware control. I swear on country and honor it has five lines reliability because I know they couldn't measure it if their life depended on it and send them on their merry way, right? And I cash the check and feel there to take a shower, right? And move on. Good example number two, right? Brilliant customer from Telecom from Central Europe called me up and have very clear understand. We have this mobile device application. We have very aggressive time to market ambition We need Tomcat, we need Java, we need MySQL, some NoSQL databases and a flexible platform to deploy it as a sandbox and then the same platform to use in production. We speak with our dear friends at Gigaspaces and said, check, check, check, check. We speak with a customer, we enable them on our public cloud, we give them a cloudify environment there. And it's one of my bright spots of each every day. What can I learn from this customer today, right? So what I'm trying to say here is that there are customers that we need to serve and carry on because the paycheck has to be there and otherwise the press will nail us to the wall that OpenStack hasn't any commercial adoption while at the same time enable this emerging, messy, innovating and fantastic new ideas that are out there and help them gingerly grow into something more meaningful. And with that, I would like to close you with this talk which I'm telling my customer and myself each day. Well, success with OpenStack is easy. The only thing that you need to do is use it like Jimi Hendrix uses his guitar. And that's all I had to say. Thank you very much. Any questions?