 Right. Hello everybody. I think we don't need all the rows at the back, actually. We could just do with one or two rows in the front. I proposed this session because I thought it would be useful to talk to folks or talk with folks who are interested in the longer term economics of clouds. And so I only have initial preliminary thoughts to share and I'm as interested in what you think about this because it will shape how we engage and how we invest over the next year or two. I think we're in the middle of the gold rush, right, which is a kind of crazy time. And so I thought I'd start out with a statement about gold rushes and hangovers. Nothing feels as terrible as the period right after a time that felt so good, you know. And I've been around a little while and seen this through a number of hype cycles, the dot-com bubble and various others. And I think we should be sanguine about the fact that right now we are in a time of irrational exuberance around OpenStack. And that's good because it engineers a lot of creativity, brings a lot of resources and it has negative consequences now as well in terms of sort of the fog of disruption, you know, on the show floor and in the sessions. And it may have bad consequences later as well as the tide recedes. The way I kind of think about this is, you know, if you look at things, when you're getting started with a new kind of way of doing things or a new industry, the first guy in demands a return, right? He sort of says, well, I'm not going to do this unless I understand how it's going to work. So that's not what I meant to do. So if we consider in the cloud industry, you know, Amazon would have felt like they could at least be certain that they were generating a return on capital in the beginning. And as a hit emerges, right, capital becomes really easy to attract. And I think we see that right now, you know, there's lots of signs of venture funding and institutional investments. So capital right now for OpenStack is getting easier and easier to achieve. But correspondingly, the return that people are demanding is plummeting, you know. I see a lot of people saying stuff like, well, you know, we're going to build a cloud and obviously we have to run it at a loss for a while, right? And to me that's a clear sign that we're somewhere in this drop, right? The income expectation is very, very low. People will say stuff like, oh, it's strategic and we have to be there and so on. And I think that's fine. But we should know that what is going to happen is that at some point people will decide there are winners and losers and there's no point in joining because you're just going to be a loser. And very quickly the dynamic changes very, very quickly. Suddenly, capital gets very hard to find because everybody says, well, why are you doing this? You know, that game is over. And that can change in two months, three months. And immediately then the situation starts to normalize and income expectations grow again. And in the long run, hopefully you have a nice sustainable industry for those who've survived. That's where I think we are today. I don't think it's peaked yet, but I think we're getting close. And that's when the hangover starts, right? It's when everybody starts saying sure, but we really need to have a sustainable story here. Otherwise there's no point in us being in it. Now, there are some very large players out there. The Amazons, the Googles, the Microsofts of the world who have genuinely profound strategic reasons to be growing in scale. They already operate at tremendous scale. And so, you know, for them it's relatively easy, I think, to stay in the game. But I think there's a much larger collection of organizations and we have to really understand the dynamics that will keep them, keep clouds viable for them. And two kinds of organizations I think about in this regard. One are enterprises who will be operating private clouds and the other are smaller regional or local public service providers. And I think it's really important, I think this is the forum which will decide whether or not that second category of enterprise private clouds and smaller regional and national telco type, service provider type offerings, whether they in fact in the long run have sustainable niches. So the first thing I worry about is cost competitiveness, right? Because of the ability of the very large guys to buy at scale. And we've seen how scale becomes a weapon, famously Apple buying up the entire, you know, world supply of a critical component for two years, you know, is a weapon essentially, right? It means that nobody else will ever get to scale because they can only buy from smaller providers who ramping up and it's a way of essentially locking new competition out of the market. You know, Apple did that famously with Flash for their iPods and it had a dramatic effect. Consider the CAPEX commitments that Amazon, Google, Microsoft are willing to make. I think there may well be a risk that that essentially has exactly the same effect, whether it's deliberate or otherwise, on supplies of critical components that drive the underlying costs for smaller players, right? If you can't get the next generation SSDs, the next generation. I think we're really starting to see signs of that. You know, there are new classes of SSD coming to the market in non-volatile memory, which I see a lot of signs of the big players essentially saying, well, we're only going to deliver these to the mega data center operators for a period, right? Three contracts could buy up their full supply and it immediately locks out smaller players. So it's not just cost competitiveness, it's also access to the ingredients of a successful underlying infrastructure. I think this is just as important for private clouds as it is for service providers. For the simple reason that private clouds don't have, they face competition from the public clouds, right? If you're an IT guy inside a large institution, you are watching workloads move off into the public cloud and that you're in competition with that public cloud. And I think at some level, IT guys understand that, right? That if all of those workloads were to move, that would be, you know, they would be looking for a job at a public cloud provider. And so this is as important for private clouds as it is, obviously, for service providers who are competing. In this regard, obviously, you know, we, I think, quite famously have taken a very lean approach to the pricing of the services that we provide and it's because of this, right? There's no point in building a model, you know, that depends on input costs to service providers and private clouds that will price them out of the game. And so that's just a hard cap on what, you know, the sorts of engagements we will structure. But the other half of that is revenue models, right? What are the ways in which these service providers and private clouds will generate revenue? And, you know, there are the obvious things to do, you know, sell VMs, sell disks. And then there are things that I think are further down the pike but worth understanding and exploring. And I think it'd be interesting to have an open conversation about what those things might be. The obvious thing that an infrastructure as a service provides is capacity, right? Compute capacity, storage capacity, network capacity. But commodities we know, commodities on a global market provided by large institutions with deep pockets, we know that the economics of that are very, very, very brutal, right? It's like airfares. The, you know, as soon as you have 10 airlines flying a particular route, the economics of that are extremely lean. Server capacity, the server industry itself, you know, has very lean margins. We must assume that the cloud market for essentially virtual goods of the same nature is going to be even leaner. And, you know, all of the price wars between Amazon and Google and Microsoft support this. There is something, there is one way to differentiate a commodity like that, which is location. And this, I think, is one of the strongest assets of the smaller players, proximity to a particular audience or a particular customer. And I see this at multiple levels. For example, telcos. I think NV, the Google's their ability to operate at huge scale, very flat infrastructures. But I think telcos have an asset that Google NVs, which is the fact that they have points of presence in so many places close to customers. So, you know, the grass is always greener on the other side. What Google really would like, I think, is lower latency access and higher visibility access to the full pipe, essentially, which is something that telcos have. And conversely, I don't think the telcos will ever be able to compete with a mega data center operator at scale, simply because they're not structured to do that. But they do have this location story. And location is important for data because of regulatory reasons. It's important for latency because many services, and increasingly I think the services that matter are going to be very latency sensitive. The faster you can get that movie streaming, the lower the, you know, the faster the response times on the game that somebody's playing, the better your perceived quality of service. And the combination of those two things, regulatory compliance, data protection and all of that, plus network latency, I think are very, very powerful things to think about. And meaningful ways in which to be able to charge a premium for the otherwise commodity goods, right? You may not be able to compete on price with Amazon for a VM of a certain capacity. But you don't have to, if you can say that your VM is much more valuable because it's closer to a particular thing. The earliest example of that that I can think of is advertising. If you can associate a postcode to a click, it's four times more valuable or it used to be. I think that it's now, you know, that's commoditized a little bit too, but certainly location is an extremely valuable thing if you know how to spin that story, tell that story. So if I look at the strategic questions facing smaller service providers and telcos, national, regional players entering the infrastructure market, I think they have this slightly daunting picture, right? And if you think that you're selling, they're typically selling to a company which is connected to an audience. So if you think you may be hosting the web infrastructure of a news organization or a media organization, they're your customer. But their customer, their audience, you know, has a footprint out there in the world. So if you kind of just look at it as global customers, local customers, global audience, regional audience, and you make that map, I think this is what it looks like when you are a national or regional player. If you have a local customer that only has a local audience, I think that's pretty easy, you know. So say you have, for example, a media organization, all of whose channels and radio services and newspaper pages and so on are in a language that's only really spoken in your country, and you're the dominant brand in your country, well then that's easy, they'll come to you and they'll believe that you can serve their audience. So straightforward. But say you're trying to reach, trying to offer services to an international organization that wants to reach your market. So it's all in your language, you are the branded player, you are the local leading hosting company or infrastructure service provider in that market. The problem is that foreign institution doesn't know that. You have a brand problem. You're the leading provider in Turkmenistan, right? Hard to know, right? Maybe someone knows, I don't, right? And so of course, people in that sort of quadrant will say, well, the best I can do is probably Amazon, they're pretty huge, they're pretty everywhere, just go there, right? And Google can tell a pretty good story about being pretty global. Similarly, you know, if you've got local customers who are trying to reach a world audience, they don't prejudice their local provider because they just don't believe, you know, they're attracted to the global brands and it gets even harder if you've got global guys trying to reach global guys because they're very conscious of scale. At that stage, they're buying very much on price, they're buying very much on scale and it becomes very difficult. But I think those two, the brand and footprint questions, can be addressed. If you look at the very large players, they have incredible footprint around the world, but it is concentrated, right? They'll have N mega data centers. And if you look at a single regional player trying to compete with that, it's a tricky prospect. But if you were to aggregate many of those, then I think you have a potentially interesting story. You have an interesting story on scale because potentially that represents substantial scale and certainly that would put you into the category of being able to deal direct with the big suppliers, whereas being an individual operator might not, might force you to deal with a regional player or a local reseller. And from an audience point of view, that looks like a much healthier picture. If I choose you as the infrastructure for my service, I could credibly feel that, you know, if I wanted to reach somebody way out in Turkmenistan there, that you have a region in Turkmenistan. So this idea of federation, I think, is very interesting for that important category of players. Let me map out the story. Your service provider in this country starts and builds an open stack cloud and they establish a certain amount of competence in the operations of that and ability to reach the local market. So they're now hitting that first quadrant pretty well, right? Local audiences, sorry, local customers talking to local audiences. In order to reach a broader footprint though, they then start to federate with a variety of other providers. What does that look like to their customers? An announcement that they now have a region in that other market. And so if you were a customer of any of these providers, you would start to see that your cloud, your local cloud provider, now has capacity in a long list of markets, which is quite attractive, right? You're still talking the same API. You're still using the same credentials. You still have one bill. You have potentially common expectations of service across those regions. Although I have to say even the major players do have a certain amount of colorful diversity between the characteristics of their different regional data centers. And over time then, you get the ability to potentially be a local player reaching a global audience through this mechanism. And in aggregate, that federated cloud could come to look like something that the global players might choose to engage with rather than one of the mega-data center operators. So that's the theory. Any comments or questions so far? Anybody actively working on these kinds of cross-cloud relationships or thinking about the dynamics of those? So that's keystone-level work. That's at a technical level, essentially. Do you want to tell everyone a little bit? I'm going to get to identity pretty much now. So that's perfect. Do you want to tell everyone a little bit about what that work entails and what you're doing? Can you pass the mic back? Sure. So it's actually a whole bunch of players. Red Hat, IBM, Rackspace and CERN all working together to introduce federated identity across multiple different clouds. There's a demo later today. There's a talk at about 11 as well about how we do it. But it's using standard protocols. So it could go beyond OpenStack, if you would, using SAML approach. Yeah, that's completely up to the trust in between the identity provider and then the remote cloud being the service provider. There are certain attributes that are actually passed along according to that trust, such as username. But there's no credentials actually being sent over. The service provider doesn't have the user's password, for example. Thank you. I was telling, this is more of a legal issue. Because if you are demanding the middle, you are responsible for the transaction between the user and the provider. So it transcends the technical stuff. What about data confidentiality and protecting the least infrastructure provider from being able to access the data of the user whose workload is being shifted around, for instance? Again, it's a legal issue. It's not a technical issue. That's the main problem. Because this federation think it's wonderful. I'm working actively on this for several customers. But the problems transcend the technology. And that's what we need to think about. Yeah, I think this is not a technical talk. That's why we're having this talk. So my sense is that from a customer perspective, it's very, very clear. You will want, obviously, to comply with the know your customer requirements of your local provider, the provider with whom you've signed up. But you're not going to want to have to think about now suddenly, essentially, becoming a customer of another company with all the know your client issues that that entails. The reason I think it's important to talk about this now is because if we just let it happen, we'll get a mess. We'll have different opinions. We'll have different approaches. This is an opportunity for industry to essentially have an opinionated stance and say, no, no, no. We want to federate and to recognize that it's not going to work very well if, essentially, every player demands to know everything about every customer. So the contracts between these players essentially need to be opinionated and with a view to success. So there are regulations. The cloud provider, the remote cloud provider will probably be under pressure to be able to account for everything that's running on their cloud. But as long as their contract back to the other party essentially addresses that, you know, in the event of a law enforcement process, how does that get escalated to the other side and is it appropriately backed? Is the sort of language that we need to be thinking about? If we just stumble into this, it won't work. We need industry to have, I think, a fairly opinionated view on what will work and then go out and build it and deal with any issues that arise. So I think identity is the first issue. I'm not sure if I had... Let's put data privacy, data security into that. I think if you're a remote operator, one of the reasons, sorry, if you're a remote foreign customer, essentially, one of the reasons to want to put infrastructure and data into a place other than latency is compliance with local laws. If that country has said, any data that you hold about our citizens must be held in country, as some countries are starting to do, that means that you have to find a way to put your apps and your databases and so on and so forth in that country. So I think there's mutual incentive here. The customer, the ultimate customer, wants to be in your country, but they want that to be a smooth and seamless process. They don't suddenly want to become a customer of different cloud providers. They don't want an engineer placing a workload in a country to trigger a whole bunch of contract processes, is what it really boils down to. We need to decouple the engineering deployment type discussion from the contract type discussion. What about security? What concerns would people have from a security perspective? For instance, what might concern me or what I can think of might concern customers is that a portion of my data will probably have to leave the premises of the provider that I trust and enter the infrastructure of a provider that I'm not sure I trust or I don't know how much I can trust him. And it's going to be visible not to the other customers in that infrastructure but to the infrastructure provider himself. So it's a difficult thing. So for instance, if I'm doing any credit card processing, those credit cards are going to go into an infrastructure which I don't know if I can trust. So in that case, there will have to be some strict assurances of a feature set that some parts of my data I'm allowing to go and some other feature sets that I don't want my data to go into, for instance. I think it comes down to how to generate this trust. You have to somehow generate this trust. You might get some kind of PCI compliance for credit card processing or you might have some ESO certification, ESO 9001. So these are things to prove and to prove your credibility and you have some kind of quality control in this federated crowd and this is something that we have to work out then. So you have some kind of basic trust to ensure some kind of basic trust. I think it's also kind of what the role the person has so some people are buying and some people are usually selling on the cloud and so if you're a seller, then you have a lot of concerns also versus just being somebody on there buying. If you think of other places where these problems must have been solved, where are you from? Where are you from? From China, in Munich, in Germany. Brilliant. And you, sir? No, not you, sir. You, sir. You're Latvian. Now what would be fantastic is to think like if you exchanged phone numbers and called one another, what would be happening? What's that? Someone would be making money. But think about it. Your cell phone comes from, I assume an operator in Munich, a German company whose course comes from an operator in Latvia, in Skype. I don't be difficult. Between the telco industry, we already have mechanisms for signalling. We already have mechanisms for handover. We already have mechanisms for billing. That call gets routed. It gets placed. Go even further. There's two cell phone base stations. Those might not even be, and all of that's through the local operators as well. There's two base stations. Those may not even be owned by the operators that are showing up on your phone. And yet everybody's getting paid. Law enforcement happens. It's just fine. So we've solved this sort of problem in the telco industry before, out of necessity. And I don't think there's that much difference between placing a call and placing a thread these days. And if we start to think of it in that way, maybe we can build quite a nice fabric for this kind of distributed computing, which is the sort of era that we're going into. Okay, what else? Brand. What are the various... Which was the project called? Congress. Anybody go to that session? If we go a couple of years back to the grid computing that was initiated, I stopped following it for a couple of years, but the original idea of the grid computing was to commoditize compute and storage resources and to be able to share them between multiple infrastructure providers and tenants. So I know that obviously OpenStack and cloud, commercial cloud and open source cloud solutions have taken over most of that public interest from the original grid project. But that's something the original grid project was trying to solve, and mostly succeeded, at least as far as I know, in some aspects of it. So it's a topic that already came up before, but for some reason I don't know if it's just the technology that didn't take off, or if there are other issues that the grid project wasn't able to solve. So maybe we can refer to that and see where we can improve a part. So from a brand point of view, I think the key brands involved in this case are the local brands. I think your buyers are going to be dealing with their closest entry point to such a federated cloud, and they will effectively assume that that's what they want. But there's also going to be a brand associated, I think, with the overall story, and for me this is a little bit like Visa. You get your Visa card from a local institution, but you expect it to work anywhere in the world. So I think there's an interesting analogy there. And perhaps we can look to those sorts of institutions for model templates on how to structure, and they also have trust and data protection type issues, so perhaps we can look to those sorts of institutions for how to structure those relationships. Service definition, how consistent do you think service definitions need to be across those players? And by service definitions I think we mean instance types, performance levels, SLAs, what else might be in that, and how important do you think it is that they be consistent across the various participants? Let me ask you to resale that. We need to unify the service definition first because each service provider will have their own service definition. There is no standard, and in fact this is a great opportunity to create a standard for service definition. And what would you include in that service definition? What are the attributes that you think are important? Is it straight instance types? Is there more to it than that? No, it's more trick than that, and it's the correlation between all the attributes from the different services because for example, just for simple infrastructure as a service you can have 120 different attributes to describe that service, and the permutation between all those attributes it's a huge mess. And if you put on top of that the pause and the size and the security and the networking and so on and so forth, it's a complete mess. So we need to standardize the service definition Who's in... Is anybody here actually representative of one of these... or feels that they would like to be one of the smaller dots on that picture that I had up there? Yeah? How do you feel about having your services standardized by somebody else? Yeah, it's difficult, so we have to comply with the definition from somebody else, and our infrastructure might not fit to this service definition. The tricky thing about that ease of capital access is that everybody who's going out and grabbing that capital is doing it because they say they're going to differentiate. Right? I mean, I see this pattern dramatically, right? Well, we should go raise $20 million to build a cloud and we're going to beat Amazon because we'll be different, but if everyone's different in different ways... You cannot generate trust with the different service levels. Yeah, it's tricky. You can't generate capital if you can't differentiate. It's interesting. Well, you don't necessarily have to differentiate on the service description level. Like, on a basic level, compute resources, even if we have a similar definition of CPU counts per VM type, those might be different CPUs there. So if we agree upon a unit of computing, a unit of memory, a unit of storage, it still leaves enough room to differentiate in different ways to potential investors, like efficiency or data locality or latency. Even if the unit of measurement is the same everywhere, there still should be enough ways to differentiate. What about the search? So actually, if you federate a lot of clouds, the end user from Portugal, for instance, might want to know what kind of services are in the federated cloud. How does it search for a service if there is no standardised in the service attributes? You cannot do that. There's always a way to translate. I think you said it best when you said that you can. It's ultimately just computing storage and connectivity, not even networking. So I think that there should be a way to translate. And the more you standardise, the more time you reach bad compromises and it will drive consolidation in the industry in the same way that it did with the tacos around 3G. So I would be very wary of pushing towards standardisation. I think there is also another problem. Most customers are not even aware of the parameters they need to know. And it's making it difficult to have some standardisation on this because the providers who are really bad on some specific parameters don't want to see them standardised. For example, latency in some VM environment is very bad and very few people talk about this just because they don't know how to solve this, for example. Well said. We can't get stuck on this one. Billing, I'm not going to get stuck on that one either other than to say that no one will be interested unless that's a solved problem. And I think we've got about three minutes left. Solution portfolios. Talked about the other services and the searchability of services. What sorts of solution portfolios do you think will be most compelling for these cloud operators? And is that something that's attractive and useful? Do regional operators feel like they would prefer to be leading and differentiating on solution portfolios or that it's better potentially to have standard portfolios that are accessible everywhere? Do you want to just shout? I don't know. We have time to get a microphone to you and I'm not sure where the microphone is. There it is actually. So yes, it kind of goes back to discoverability of what capabilities in each individual service provider actually has. And I think they'll probably want to differentiate on the portfolios that they offer, saying that they're best for big data workflows or workloads as opposed to web tier workloads. I think that would be very valuable to the customer. Other thoughts? Somehow, IS has been commoditized. So next generation opinion is more really driven by the past platforms. So it just sort of provides their own past platform to attract the local developers to create their own marketplace. Smells like teen spirit. Right. I think that's just about everything we have time for. Any other topics that you folks want to touch on? At the back, do you want to shout? I have a mic. So what happens if the relationship between a big player and a small player becomes broken? So if they went out of contract, what will happen with customers in that case? That's also something that we need to consider. Unminding. Yeah, that's interesting. Any other topics? Very good. Well, let me thank you very much for all of your contributions and ideas. I think this is a very thought-provoking area and certainly an area where we see a good deal of interest between the folks who are raising money and want to have a long-term sustainable view on how that will work. Thank you. Have a great conference.