 that you're thinking. Thank you very much. First ball, can you all see me? Yes, can you all see me? Yes good. So cloud computing wire matters, quick introduction first, my name is Simon Wardley I work on cloud computing strategy at canonical and canonical for those of you who don't know is the company that sponsors and supports the good to. Ym bleddoch cyngorau. I'm a sciences by training which means I like graphs. Now I've crossed a quick graph. This is a graph at the level of audience pain that you against the number of slides given in a 20-minute presentation. I reckon there's a safe limit of around about 10 slides. Now seeing that I'm a scientist and I like to experiment I'm going to be doing this with no less than 196 slides. I know what you're thinking, but don't worry if you do get a bit lost, this is a talk on cloud computing being lost as normal. So what is cloud computing? Well on the way here I asked the taxi driver in London and he said it's like computers on the internet in it. That's actually very very good. So I asked the technology strategist and he said it's the future of technology and a disruptive shift of the computing stack to online services. Well that's just the posh way of saying it's like computers on the internet in it. So I asked the businessman and he said it's what the technology strategist said it was but it's also about the provision of computing resources like electricity and getting rid of expensive costs like sys admins. So I asked the sys admin and he said it's like software as a service or SaaS and infrastructure provision and platform as a service that's pass and utility computing being provided on public cloud which is different from private cloud which aren't cloud computing unless of course you're talking about hybrid cloud and it's height and locking did I mention infrastructure. So I often knew I found 67 definitions of cloud computing. Now once this doesn't help you if what you're trying to do is understand a field it does help me because I'm trying to pad out a presentation. So what I'm going to do is I'm going to look at those 67 definitions. Number one. On demand self service internet infrastructure when you pay as you go use what you need managed by a browser application API. The cloud computing market is broken up into six including cloud application, cloud platform, cloud infrastructure, brackets, c-cloud pyramid. So what's a cloud pyramid? Well it turns out it's another eight definitions and an entire argument over what the cloud is a triangle. And if so which way does it point? Lost yet you're already definition number two. Now I'm not really going to go through 67 definitions with you now so don't worry. But having done so I can tell you that there is no definition for cloud computing unless of course you're talking to a technology strategist in which case they'll normally define cloud computing as being their pride. So I looked around for analogy. Why are we having such a problem with definition? I found an analogy and that analogy is this. What is industrial revolution? Well I asked my taxi driver and he said it's like mechanised horses in it. Again very good. I looked on Google and I found 43 definitions again. So let's have a look at them. Number one. Broad socio-economic changes starting in the 18th century. Bad. Number two. Rapid development of industry in the early 19th century. Okay we can't even agree on which century the industrial revolution was in. Once you've gone through the definitions you find that there's no absolute definition. And this is 200 years later. Now at this rate by the time we understand what cloud computing is kittens will be online. Now the reason why there is such a problem with definition is cloud computing is simply not a thing. It's a transition. And this is at the heart of the problem so I want to go and have a look at the fundamentals of this using the example of the industrial revolution. So the industrial revolution was a time when we went from bespoke cottage industry to one of mass production. And that required a number of different factors. For example you needed the concept of mass production. You needed suitability of activities for mass production. You needed the technology to achieve this. And most of all you needed a change of attitude in society to accept these models. Now this is what caused the industrial revolution. And you can't define industrial revolution in terms of a product or in terms of a technology. Now the same is true with cloud computing. Because it's not just a technology it's actually a transition and transformation of that industry. And it's caused by multiple different factors. So this is where I'm going to start. And we're going to start with the concept first of all. Well the concept behind cloud computing is actually fairly old. Started back in 1968 with John McCarthy who predicted that in the future computing resources would be provided just like electricity. And this term was called utility computing. Now it's a great idea but where did it come from? To understand that you have to go back further and look at the electricity industry. So the electricity industry started off back in 1821 with the innovation of electricity production. And it was brand, it was hops, it was what we would call an innovation. And then over the years the number of spoke systems were created such as the hippo white pixie. And then we started to have products being produced. And so we got to about the 1890s when Edison of Western House created the first utility grids. Electricity had become much more of a commodity. It had become suitable for service provision. Then we had Harvey Hubbell created the plug. And then by the 1930s we had things like the national grid. So electricity provision had transformed from an innovation to something which was a client service. It had become ubiquitous. It had lost its spark. Now this transformation is known as commoditisation. And a similar pattern has been occurring in IT. So for example if we look at infrastructure we can go back to the original innovation of computing resources back in 1941 which was the Z3. You had bespoke systems such as the Leo computer in 1946. And then you had the first products, the IBM 650, around about 1954. So it was fairly logical the next shift for computing would be from products to services. And this is literally what John McCarthy predicted back in 1968. He made the conceptual leap to say that in the future what happens to the electricity industry was going to happen to the computer industry. So this is the basic concept behind cloud computing. The question however was always when was this going to happen? When would IT activities make that shift be suitable for that change from a product to a service world? Is there some way we can actually plot this? But actually we can. I'm going to plot a graph because I like graphs. This is a graph of ubiquity from something rare, like a good film with Tom Cruise in, to something common like a film with Tom Cruise in. And against this I'm going to plot an axis of ubiquity from something, no, well something which I, sorry, axis of certainty from something which I'm not sure about whether I'm going to finish this presentation on time to something which I am sure about which is how much time I've got. So I'm going to add some real data. This is TV's famous PCRs across against these axes. And what this suggests is that there's an escurred relationship between the ubiquity and the certainty of an activity. There is a pathway perhaps something which is rare and poorly understood and innovation becomes something which is much more common and well-defined or of a commodity. And ultimately something which is potentially provided through a utility-like service. So we can follow this. If we look at something like CRM, you have the innovation of CRM before we even called it CRM, which were the early list of the 1980s, to database marketing systems of the mid-80s, to the first C9 products in the 1990s, right up to the modern day where you have utility-like services of south spots. So CRM has gone from an innovation to much more of a service. Now all business activities are somewhere on that code and all of them are actually moving in that direction. And why is that? Ask any businessman and they will tell you that business is nothing more than a cat fight. It's warfare. And as soon as one company gains some sort of technological advantage, some new big gun, like an e-commerce site, then every other company will follow suit. This creates a constant pressure towards commoditisation. So what's happening at IT is a whole bunch of activities which were at one point innovations, but more recently have been provided as products, have become so widespread and so well-defined that they've moved up that curve and become suitable for service provision through volume operations. Now this doesn't mean everything in IT is on that path. IT contains a range of activities all in different areas of that curve. We're still innovating in the area of IT. However, some activities have become so widespread and so well-defined that they are now suitable for service provision. But concept and suitability is not enough. You also need the technology to achieve this. And the technology, while there's a couple of core pieces of technology here, one of them is virtualisation, but that's been around since puppet wrote the book in 1964. So from the point of view of virtualisation we have the technology, yes, it has been matured, but we can just take it as written while the technology to do this. But concept, suitability, technology is still not enough. You also need a change in attitude. And the change in attitude has been echoed. Business has been changing its view of IT ever since people like Nick Carr have written books which have simply pointed out that common and ubiquitous aspects of IT don't actually bring much competitive advantage. In fact, the strategic value of something diminishes the further it goes out that curve and the more widespread and commonly defined it is, the more of a cost of doing business it is. So these four factors are actually in play today. This transition from a product to a service world has been going on for some time. We've seen earlier attempts, like the ASP, attempts to take activities to a service world, but not all four factors are in play at the time. They are in play now, and that's why there's this big push, basically, from a product to a service world. Now this transformation is obviously highly disruptive if you happen to be a company whose entire business depends upon producing products where those products have become well-defined ubiquitous and suitable for service provision. So why does it matter? Well, there's another aspect to this curve, which is this. If you treat an activity as though it's an innovation, whereas in fact the rest of the market treats it as a commodity because it's well-defined as ubiquitous, then the only thing that you're going to create for yourself is a competitive gap between yourself and the rest of the market. The rest of the market is going to get benefits, and though some of those benefits are on a common scale, some of them are paper use, some of them are faster speed through componentisation, some of them are about being able to focus on poor activities, but overall those will create a disadvantage between you and the rest of the market, and that's why there is a constant pressure on you to keep up. To go back to my cash analogy, if we take the fighting cash, there's no pointing up to the battle with a snazzy rifle if everybody else has bought tags. All organisations need to continuously evolve. You don't have a choice in this. So I'm going to quickly recap because I've covered a lot of ground there. We've looked at what is cloud computing, and I've looked at the answers from the sublime to the absolutely ridiculous. Cloud computing is not, contrary to popular perception, a new concept. It describes a highly disruptive transition of IT from a product to a service world, and we really don't have a great deal of choice about whether we're going to adopt it or not. I'm going back to the example of the Industrial Revolution or what I like to call Mrs Muggin's Inc. I mean we can know more avoid cloud computing than Mrs Muggin's could avoid the Industrial Revolution. So that's the theory. What about the practice? Well, as I said, activities which are on ubiquitous world fire are becoming suitable for service provision, and that's not just one particular aspect of IT. Those activities can occur anywhere in the computing stack. This, unfortunately, has given rise to what we generally call the different asses of cloud computing. So, for example, you have software as a service, or SaaS, where you have providers like Salesforce, you have SaaS or platform as a service, providers like Windows Azure, and you have IaaS, which is infrastructure as a service provider, like Amazon. I'm not a bit fan of these terms, because you may as well just call it software as a product, platforms as a product, infrastructure as a product in the old world, so SaaS, SaaS and IaaS. It's simply all of this is doing, it's reflecting the fact that these activities have shifted from a product to a service one. But it has one important distinction. It creates a boundary, a division of responsibility between you and a provider. So, for example, let's pretend that you aren't using a company like Salesforce. Well, you're obviously concerned about your data, whereas Salesforce is concerned about providing the application, and all the things underneath that, so the framework is built in the operating system, the machinery in London. Anyone of these layers, whether it's software, whether it's platform, whether it's infrastructure, is all about some components being on your side that you're concerned about, and some components being on the provider side, and what they're concerned about. Of course, but unfortunately, this is actually a delusion. The reason why it's a delusion is because your data actually doesn't exist outside of this. It actually exists on their system. And that actually creates a risk. So, the types of risks it creates, and there are two basic forms, there are transitional risks related to the formation of this new industry, and that's things like management, trust where you trust the vendors, where there's transparency in their operations and the security of supply. But it also creates the normal outsourcing risks of suitability of the activity, pricing competition, locking and second sourcing. Now, second sourcing isn't important, so I'm just going to pick on this one for a moment. If we take the example that you're using a software as a service provider, so they are concerned with the underlying systems and your data exist on that system, if something goes wrong and it could be a disaster, it could be it was bought out by another company and then closed down, then you've got to somehow get your data out of that system. But the thing is, you get your data out of the system and that's pretty useless because all you've got is data. So your choices are to rebuild everything they've done in order to run it, or you need to find another provider. So you shift your data over to another provider, but of course your data's only going to work in another provider if they're pretty much running exactly the same systems as was originally in the first provider. In order to get second sourcing, you actually need these things. You need portability of data code, whatever happens to be in that provider. You need a choice in destinations. You need interoperability or standard outputs between the providers and you need easy switching. Without these, you do not have second sourcing. But we've actually been here before. The whole thing about standard outputs, easy switching, all goes back to Paul Brown's work on security supply back in the 1960s. Now for those of you who don't know, Paul Brown's work led to an awful lot of different network protocols. What we ended up with many years ago was a mass of different protocols, IPX, SPX, Banym Vines, Able Tool, SNA, DECnet, until we got consolidation in the industry around one particular protocol, TCPIP, principally because it was open, and also because it was supported by our stream open source systems. So if we just take the infrastructure layer of the computing stack, where we are today is something like this, we have a mass of different protocols and different APIs, none of which have become the de facto standard. We are in that sort of IPX, SPX, versus TCPIP, versus DECnet stage. Now of these, one, and that's the Amazon EC2 API, is the most dominant. So, as in Ubuntu, what we've actually done is we've said, well, rather than create our own API, which seems to be the flavour of the month at the moment, everybody is creating either an API or an API of APIs, we would actually adopt someone else's API. So we found an open source system called Eucalyptus which actually matches the Amazon EC2 API. So we introduced this last April into the Ubuntu distribution. And principally, this enables all the Ubuntu users in the world to build their own private clouds which match the Amazon EC2 API and also to run Ubuntu on Amazon EC2. So you have much easier switching between the two environments. Now, this is a first step. What we're actually trying to do is create a competitive marketplace of different providers, just like you have within the electricity industry. But in order to do that, we need to get standardisation, we need to get standardisation around APIs. And the reality is that's only going to happen if those standards are not specifications but actually defined by running code or open source records models. So to quickly recap, fact computing, underneath all the noise, it really just describes a disruptive shift of IT activities from a product to a service world. And it's governed by a number of different factors, the concept suitability technology and attitude. Now, we can't really avoid this change. I know people talk about while we may not adopt it, but you can no more avoid it than people could avoid the industrial revolution. There are obviously risks. Some are transitional, will be sold. Some are all to do without sourcing and things like locking and second sourcing options. But there are solutions to those risks and we've also been here before. So the real question is whether we're going to learn the lessons of history or whether we're just going to actually repeat them. And unfortunately, at this moment in time, in the cloud space, repeating the same lessons of the past seems to be the way we are going. So thank you. Can I, just before a sparrow? Did you all follow that, or did I lose it? A horrified face, though. Did I lose you? We...