The cloud behind the cloud
Date: Mon, 10/10/2011 - 14:12
How can cloud vendors, enterprises and carriers deliver on the promise of the service cloud, unless the network cloud itself is evolving to keep pace with customer expectations? Massive scalability of on-demand resources spread across multiple locations depends upon an extremely flexible fabric to link it all together – and we already see legacy networks struggling to cope
James Walker is passionately committed to the development of this "cloud behind the cloud", as he heads the $83.5 billion Tata Companies' Global Managed Network Service portfolio for Tata Communications. Being responsible for the strategy, management and development of Tata's VPN portfolio – with over 3,000 Ethernet access nodes in 52 countries, direct MPLS services to 100 countries and managed extended access and network integration offerings in more than 190 countries – he has a wealth of real world case studies to support his case.
Intensely aware of the challenges facing cloud providers in delivering their services, NetEvents EMEA Press and Analyst Summit Rome 2011´s keynote speaker offers a radical reassessment of the cloud behind the cloud – backed with real examples of carriers' most successful current strategies plus an informed view of what can still be done.
James Walker, Head of Global VPN Services, Tata Communications
Good morning everybody. My name's James Walker, I'm responsible for Tata's managed networking business and NetEvents has very kindly given me the opportunity to open this conference up. So the subject of my talk is the memorable Judy Garland, Behind every Cloud is another Cloud. So not necessarily well-known for her networking pronouncements but Judy Garland provides the inspiration for this particular talk.
The question of what actually sits behind the cloud. So we've talked, and a lot of the subject of this conference is going to be the cloud, the services that are provided over the cloud and hopefully the money-making opportunities that sit within that. But to my way of thinking, and perhaps I'm a little bit biased because I'm responsible for the business, there is something that sits behind that cloud and that is the network platform that actually needs to link all of these various platforms, data centres, all of that sort of thing, together.
So for me the cloud is actually that wavy diagram that we as vendors tend to put on whiteboards when we're talking to customers. And there's a multitude of sins that are hidden behind that wavy shape.
So you'll get some illustrations of that wavy cloud shortly but we tend to talk about the network as obviously existing or obviously doing the service that it's expected to do. But in fact there's some quite serious challenges that we as carriers are starting to face about how to link together all these various platforms whether it's private cloud or public cloud. And I'll talk a bit about that.
So there's a variety of different transport technologies that may be represented by the cloud linking these data centres together. It might be MPLS, it might be Ethernet services, it might be legacy ATM services in some cases, Internet and so on. And really when a customer says okay, well that's all well and good and I've seen your cloud diagram and it looks like everyone else's cloud diagram, what sits underneath that. And then the carrier will tend to talk about well I've got this fibre route here and I've got some capacity over there and I've [got] all this sort of stuff. And that tends to be the limit of where it goes. And I suggest that there's a lot more that we need to think about as an industry than that.
This is one of my favourite illustrations of -- you've got to be very aware of the big message about something but it's also very important to read the fine print. So in this case the fine print points out that the bridge ahead is out. So there is an important message that says okay, dangerous sign, all that kind of thing, but also ahead there is a complete gap in the road with absolutely no way forward and you need to be completely aware of that. But you've got to pay attention.
So as I said at the beginning, the cloud brings a variety of opportunities but it also brings a number of challenges. And I think the opportunities are ones that we as an industry are very focused on because it looks like there's money attached to it hopefully. But there's also a significant number of challenges and particularly it's a challenge of bringing technology and networking platforms and data centres and indeed whole concepts that were originally expected to do something different and changing those to actually deliver cloud services.
So a lot of the data centres that were built originally to deliver networking-style services and then perhaps some web servers and all that kind of thing were built to a relatively small scale. Suddenly the cloud says I need thousands of servers to support my operation. And those thousands of servers may be physically located in one location or they may be spread all over the world. And that starts to create some quite significant issues.
Nowadays there's a big concern about the amount of power that's all going to suck because that can be a very considerable cost, in some cases up to 60% of the cost of a data centre over its lifetime is coming purely out of power costs.
Data synchronisation across these multiple locations that we have around the world.
As they get further and further apart, it was kind of easy when there were two data centres sitting in one city but it gets more difficult once you've got multiple cities or multiple continents you need to span all this infrastructure across.
Getting a network that's close to the customers that needs to access your service is also an important consideration. There are a much shorter set of product lifecycles to deal with. So before as telcos we could sit back and wait a year or two years to deliver a new service, nowadays we're being asked to deliver new services and the cloud vendors are asked to deliver new services in a matter of months. And that's a significant challenge for the infrastructure that we operate and the sort of utility view that we've traditionally had.
Continuous service improvement. So you see cloud providers launching services in beta but still happy to take customers' money off it. That's something that we as a communications operator have never done before. And now we're going down that track which is good or bad from your perspective as a consumer.
Five nines availability is probably the minimum that you're going to have to deliver and again this was something that in the Internet world was not really considered. So three nines, three nines and a half, something like that, was fine, now customers are saying as a minimum if I'm going to run my entire business off something that sits outside my control or in a data centre I need at least five nines, six nines, something like that.
There's some very complex laws starting to emerge about how to protect a citizen's data in different countries. And a simple example of that is the problem that banks that operate in Switzerland have. If you are a customer of a Swiss bank in Switzerland your data cannot be shared outside Switzerland. So even if you're in the US and you have a meeting with your account manager to talk about your money your account manager is not allowed to see your account data if they're sitting in the US.
How does the network know where you physically are as opposed to where it thinks you are. And it needs to be extremely precise.
So I talked before about this nice diagram gets written up on whiteboards and it looks something like this. You build a couple of data centres as a cloud service provider, your network provider comes along and says brilliant, you've got some customers over here, we'll probably connect you through a couple of providers and it all looks very, very tidy.
Reality of course is fairly distant from that and so we have a specific example of an IT service provider that we've been working with. They built a data centre and started to offer some applications out of it. They got their first customer who connected through a given provider, this was the provider that already provided their WAN network globally. Then they got a second customer and lo and behold the second customer had a different set of application requirements and two other providers that they got their WAN services through because they were a bank, they couldn't rely on one provider, they had to have two, so both of those providers then needed to be connected into the various services that they bought from this IT service provider.
Another customer came along, took another service, luckily part of the first provider they had, then they did so well on their first application they needed to increase the size of that, they couldn't do that within the facility they had so they had to build a second data centre location. Then they started offering some more services which various customers took connectivity to get into from their various MPLS service providers.
Another customer came along, had more connectivity requirements, more services, more applications were developed, they didn't have enough space in their original data centre so they had to build new data centres, they had to put those customer applications in those data centres. They launched a storage service which then needed to connect into every single provider that they had. And then some bright spark developed a new application and they had no idea how to connect that back into the rest of the network that they had.
So this is in fact a simplified version of the problem that they had. To give you an idea of the size of the problem they had they had 5,500 enterprise customers, 340 data centres with applications sitting in them. So the problem of how do you consolidate all of that together -- and they reckon that they could probably turn 340 data centres into 20 if they could just figure out how to unpick the customer connectivity from the service that they were providing.
So what we're starting to see from particularly the large end of town in either private or public cloud service provision is this concept of disconnecting how the customer gets to your network with the network that actually connects together the data centres Public cloud is a little bit the same and a little bit different. So a couple of data centres, a bunch of customers connect through a couple of ISPs, pretty straightforward.
The reality, a little bit different. You connect to a couple of data centres and into a couple of ISPs as far as you're concerned as the service provider but in fact your customers are going to connect through a variety of ISPs that peer or transit from each other and it can become quite complicated, particularly when one of your ISPs providing service into your data centre goes down. And then you end up with completely unpredictable access into your remaining service providers for your end customers.
So this is why we see the very biggest providers of public internet access provided cloud services, so people like Google and so on, not only taking internet access from a very large number of ISPs but also building extremely large-scale networks themselves to do their own distribution because the risk of relying on individual service providers to provide that service into them is too high.
So another interesting question that's coming up as these data centres get larger and more complicated is where do you put them. There's really two choices. You can put it near connectivity or near cheap power, somewhere where power is cheap, space is cheap and all that sort of thing. And those each have positives and negatives. You've got low connectivity costs and a big choice of suppliers in the middle of a city but you have extremely expensive real estate, you have extremely expensive power costs and a whole variety of other issues. If you're out in the middle of nowhere you've got great cheap power and land is extremely cheap, you can build your data centre as big as you like, you can make them extremely green because you can put it in a cold environment, so Iceland is somewhere that is getting popular for data centres for example. But then you have all sorts of issues in terms of connectivity, how do you actually connect your end customers to that site. It's not going to be somewhere where five, six, eight, 10, 15 providers actually have access into.
I was originally going to have a nice thing that showed a complicated network and a simple network but then I found two pictures that I liked so I should put them both up so you'll have to excuse me for that. But there's an interesting discussion around what kind of topology you actually need to run your two -- your various data centres together. What we're finding is that customers are being forced to run two entirely separate networks, one which provides point-to-point connectivity where the performance of the application and the synchronisation between the data centres needs to be very predictable. So the end-to-end latency is predictable, the failover latency is predictable, all that kind of thing. So the characteristics you kind of expect from a legacy private line network.
But then they also have applications that need to talk to every single data centre at the same time and then they have to have an any-to-any topology to do that. So trying to mix those two together becomes inordinately complicated because they have two quite different characteristics.
So there's a variety of services that are appropriate for any-to-any and they have positives and negatives associated with that, mostly lack of determinism on any to any is a big problem. On point-to-point you do get your deterministic point-to-point services and potentially a lower connectivity cost but on the other hand you are facing issues around scalability of end points. So if you had 340 data centres, there wasn't a point-to-point networking topology that was going to help you.
So the conclusion that we draw from all of that and I suppose the suggestion that sits behind is that Tata has an answer to this. But for me the fundamental problems of what is needed to support the cloud is you need a fundamentally scalable and performing network fabric that is very flexible that joins together your various data centres. We're starting to -- after going through many years of seeing network as being dumb pipes and relatively straightforward and IT as being awfully complicated and applications and all of that sort of thing we're now starting to see a shift back from these major cloud service providers into saying well actually the networking piece is the most difficult thing I have. The concept of how to scale an application to very large footprints is more or less well-known but the concept of how to link all of that together and the actual places that distribute that information together is becoming an extremely big problem for them.
There's increasing attention being paid to where on earth are we going to put these buildings with all these servers sitting in them and how expensive is it going to be for me not only to run and power and operate them, because we've certainly seen customers go out and build a data centre somewhere that it was cheap and then suddenly finding that they have no way to connect providers to it, we've had -- in fact we've been guilty of that ourselves.
And there's an increasing requirement for these cloud service providers to understand how the network is performing, how it's providing, supporting an application and indeed what the end customer experience is accessing that data.
And I think there's an increasing realisation that understanding how this incredibly complex web of Internet service providers around the world interacts with each other.
We run a tier one ISP, we have peering or transit relationships with more than 600 operators. That is an immensely complicated ecosystem for a provider whose business really is providing services off a bunch of servers to understand and they really need to understand how that's going to work, particularly in a failover situation.
And then I think that the most interesting issue and the one that really the industry is only just starting to get to grips with is how do you mix together point- to-point services and any-to-any in an extremely scalable fashion but still retain the positives of each type of topology and each type of technology. And today we see some customers who indeed are hanging on to things like ATM services because they simply have not had an answer to that question. So for us as an industry there's a lot of interest in how we can persuade those customers to make a technological change to get out of their legacy platform and go onto something new because that gives challengers like me an opportunity to sell them something. But also it's an interesting discussion to have with the customer, why is it that you're hanging onto that point-to point topology, why do you need it. And it comes down to latency, performance, characteristics of voice services in particular for call centres and so on and then call centre as they become virtual rely on that kind of predictability.
So for me these are the questions that we as the telecoms industry have as a challenge to support the cloud industry and I think we'll have an interesting discussion about some of these topics over some time.
So thank you very much.
Manek Dubash, editorial director, NetEvents TV
James, thank you. Should we go and park ourselves at the table here and I'll come across with some questions after you. Well I've been doing some -- thank you very much for that most interesting keynote. The network is the thing is something I've been saying for quite a long time and I've been doing some research recently with the STL Partners talking about telcos and the network. And one thing that first of all came out when I started doing some research was that prediction of the value of cloud services varies hugely. So Merrill Lynch for example predicts that cloud services market will be 160b by the end of in fact this year. Some say -- IBM says 55.5b by 2014 while Baines says 150b -- dollars that is -- by 2020.
Now these are all hugely varying predictions. So what that says to me is that people don't actually know -- there's a lot of talk about cloud -- as I said in my intro, there's a lot of talk about cloud, particularly amongst the vendors, less so I suspect amongst enterprise customers who are going to have to think very long and hard before they go and replace their existing infrastructures and obviously they're not going to do that, they're going to do it in a kind of piecemeal rolling fashion.
So the question really is given that level of uncertainty how can customers really be sure that service providers have the infrastructure to support them given that you're sort of in fact -- you here are now a proxy for all the cloud providers so I'm asking you this question. Can service providers really be sure that they have the infrastructure support given that they don't know what the demand is going to be?
So I think there's a lot of things that sit behind that. The varying predictions we see for the size of the cloud market depend on how much you consider likely to be provided by third parties. So we see a lot of uncertainty at the moment about whether enterprises are going to trust third parties to provide cloud services, whether that's on a public internet basis, so a sort of Google Docs style environment, or some sort of more private cloud with VPN access and all that sort of thing.
And then do you consider the networking that enables that connectivity as being part of the market or not part of the market. Then you start to get to some pretty varying numbers because effectively the cloud market then becomes a proxy for the total size of the industry. And I think that's a bit of a nonsense really.
The -- we're pretty simple folk really, we invest money where we think we're going to make a return. And we've been right in the past and we've been wrong in the past.
For some providers it's a bigger challenge than others. Some providers have got a large amount of legacy stuff that was going what they thought would be important 10 or 15 years ago and they need to finish extracting the last few dollars and cents out of that.
A whole rip and replace and forklift upgrade of that infrastructure is something that is a big concern. And I think those providers are going to struggle to make their business case work until they can understand what their piece of the cloud is going to be actually worth. And that's where I see a lot of activity at the moment.
The more newer service providers are saying look, my infrastructure is more or less there, I just need to adapt it. In that case the big challenge I see is those who have build very large enterprise-facing businesses, and here I talk about people like BT and AT&T and Orange and all of that sort of thing, but have not built necessarily large wholesale businesses then they are at a big disadvantage we're finding because they don't have an internet network that's big enough to provide any kind of guarantee of the service that the end user is going to have.
So for us having come from the other way round we were basically a big wholesale provider that has then built an enterprise business. It's relatively simpler than somebody who has a huge enterprise business and really not a global wholesale business. 73% of our revenues come from international, if you look at AT&T 3% of its revenues come from international, so the emphasis in investment is completely and totally different.
So I think that's one of the places that challenges will come.
Okay, just picking up then on another point you made in your presentation which was the suggestion that -- and I think it's true -- that obviously there's going to be a lot of partnering going on, a lot of peering and not just from a network perspective, obviously from a services perspective as well. How easy is it going to be both say from end user customers' point of view that they're going to be able to trust not just their cloud provider but the two or three or half-a-dozen or however many it is partners that they've got further down that supply chain? Are service providers in a position to guarantee those partners I guess? And is that infrastructure ready? Which is essentially a similar sort of question as I asked first time but thinking more in terms of the service provision.
I think that from a telco perspective we have always had to rely on third parties in some way, shape or form. So whether that was last mile, it was backbone infrastructure, a lot of carriers buy backbone infrastructure from us, so the simple level of things we understand how to partner with somebody. I think for telecommunications operators we're struggling to understand exactly how the entire stack is going to work out.
My life is a little bit simpler because we have a sister company in the Group that is very good at doing IT outsourcing and all that sort of thing and there is no objective within the Group for us to start becoming a soup to nuts kind of IT services provider that's seen as a -- we concentrate on what we're good at which is the infrastructure piece, TCS concentrates on what they are good at which is the consulting piece.
I think it's harder if you're a provider who's trying to do everything from start to finish and I think you're going to have to make quite a lot of potentially quite expensive acquisitions to support that. And then even then you're going to have to bring in third parties and then you're back to the problem you stated which is how is a customer ultimately going to trust you. And we've seen some quite high profile even whollyowned cloud services go down. And so we're still seeing a lot of reluctance from major customers. The small and medium enterprise was happy to look at cloud but the major enterprise is still looking at is as a private cloud exercise that they're going to build themselves on top of somebody else's data centres, network and all of that sort of thing and not really as something completely outsourced. So that to me is a long way off.
Okay, I'm going to throw it open to you guys for questions in just a minute but I've got one more question I would like to ask so think about that. One question I would like to ask you which is again perhaps a fairly blue sky sort of question because I'm quite interested in the role of the telcos in cloud because we've seen a lot of service providers, dedicated cloud service providers or renamed cloud, ASPs, whatever we used to call them, calling themselves cloud providers but the telcos have been conspicuously absent in the cloud market apart perhaps from the infrastructure layer.
Are we going to see them climbing from the hellhole of infrastructure to service into the sunny profitable uplands of software as a service, assuming that is profitable given they're going to have to partner? What do you think?
I think you're going to see for the intermediate term some dabbling in it. We do see Verizon being quite aggressive in the market in terms of acquiring cloud service provider types and the CenturyLink obviously with service and so on. So we do see some early steps and it's being done by acquisition rather than development. So I think that's an interesting trend to watch.
My view is that every new product that has been launched in the telcoms industry has been very quickly and increasingly quickly commoditised. So as far as I'm concerned I have a smug sense of assurance that fairly soon somebody's going to create essentially a marketplace for cloud infrastructure where I can buy storage or compute seconds or whatever off some sort of global market and the whole thing becomes more or less interchangeable.
That's a very interesting model for somebody who has very large requirements very occasionally. So I'm an oil company, I need to process my seismic data and today that's a very complicated thing for me to do. If you could go onto a marketplace and say right I can use Chinese servers for the next three hours and I can use Egyptian servers for the next four hours, that becomes a very interesting marketplace. But that also implies there's going to be an extremely rapid commoditisation of the actual infrastructurey bits that go to support a cloud and so you've got to hope that the value remains in the application. If the value remains in the application then the long-term view from a telco has to be I've got to be very good at the infrastructure piece because I'm never really going to be superb at the writing software bit.
So for me and strategically as far as we're concerned we are concentrating on being very good at the transport bit. We think that there's going to be a lot of activity at that sort of service provision, infrastructure as a service, platform as a service kind of area but ultimately it's going to be extremely quickly commoditised and then all the value is going to be sucked out of it and we don't want to be making multibillion dollar investments that are going to be commoditised in two years.
I just want to ask you one question that occurred to me while you were talking. Why is it do you think that very few people are actually bringing up the issue of the network which seems to be me fundamental to the notion of cloud if it's ever going to work, the network has got to work. Everyone talks about the servers and the services and the data centres and so on but the network's got to work. Why is nobody talking about that? That seems to me significant.
My slightly cynical view on this one has been that --
Because I'm cynical. But it's come really because the cloud services are where the money is, the network and the data centre is where the cost is and you -- the image you want to give is profitability, money for everyone, beer all round, it's going to be great. But in fact sitting behind that is an awfully large amount of infrastructure investment. What the concept of cloud has been is a relatively asset-light piece of infrastructure and it's certainly true that you can launch a relatively small cloud service for relatively little outlay. But as soon as you come to something that's going to be critical to an end user I think you end up with something that is actually dragging behind it an awfully large amount of potential investment and complexity.
And that -- we've seen the profitability tip of the iceberg but we haven't seen the underside cost piece.
I mentioned Google and they're our largest enterprise customer, the amount of money that they are spending on infrastructure is astonishing, it's really astonishing. Even in a carrier space it's an astonishingly large amount of money. We're not -- whereas we look at the other cloud-type service providers, the Facebooks, the Yahoos and all of that sort of thing, we see them reluctantly coming to that conclusion and starting to buy and Microsoft and other people like that starting to buy but they are three years behind that realisation.
And then if I look even further forward at the VMwares and all of that sort of thing I think they're only just starting to understand what the implications are. So this is a very rapidly maturing industry, there are new things turning up every day, but I think that realisation of just what you need to run something of the scale that you're at is not well known in the industry yet.
James, thank you. I'm sure there's a host of questions out there for James. Thierry?
Sorry Thierry, can you wait for the mike please, it's just coming to you. Name, rank and serial number.
My name is Thierry Pigot. I work for Windows News and I was wondering do you consider Google like a competitor or a partner or is to be only one like this one?
I think the answer is yes to both. So I see -- for a company like Tata whose concentration is as I said more on that transport and infrastructure level we see them as a customer and as a partner and a very beneficial one from both parts and we're getting involved in more and more complex and high value things with them as really a partner. So we have -- in our wholesale business we have the world's largest mobile signalling business sits there as well. How can Google take advantage of the world's largest mobile signalling business, that's a very interesting discussion to have. How can Google take -- we're also the world's largest international voice carrier, we carry about 20% of the world's international voice. How can Google as a business take advantage of that, that's very interesting as well.
So we see them very much as a provider of service and there's a whole category of that sort of service provider, so there's the Googles and there's the Facebooks and there's all of those sorts of things who will continue to add more features. We see ourselves as a partner and a supplier to them. Yes, they will eat away at the edges of some of the business that we provide but fundamentally it's much more beneficial than it is detrimental from our perspective. Other carriers may feel differently.
Luke Collins, freelance. I was very interested in this notion of an open marketplace for cloud services. I wonder whether you could say a bit more about that and also hazard a guess at what kind of companies might choose to organise and launch that kind of a market?
Well I suppose until this presentation this was my secret retire young and make lots of money plan so now that that's out in the public domain -- I suppose it's only something that consumers of cloud services I hear talking about, they're very – the concept of cloud was supposed to be something that as I said was relatively asset-light that you had a service that ran over the top of it and it was more or less service independent. So there was a float, the cloud floated over something else.
I think that in fact it's much more complicated than that. As a service provider as soon as you launch a cloud service you have to pick somebody's platform and as soon as you've done that you're tied into them. I see a lot of resistance within the cloud service provider to that concept, they have to take it at the moment because there's no other alternative in the market but long term their objective is that they want to be infrastructure independent if they're not an asset owner themselves.
So I think it's going to be the application service providers as they were known or the service providers in general who are going to drive that change in the industry. Look, I'm only going to use your service if you can provide it to me in some kind of standardised sort of way so I can write my software in a consistent way that will interface with your platform in a consistent and logical kind of way.
Otherwise the risk for the service provider, not only in terms of being tied to one vendor but also not being able to determine where what went wrong went wrong. So if you put the hooks of your service very tightly into the hooks of a platform providers service then the determination when something blows up was it my problem, was it their servers, was it my application, was it the driver on their platform becomes immensely difficult to do. If you have a clear demark point that says everything to the right of this line is my problem and everything to the left of this line is you problem, that's a significant net advantage to the service provider.
I think as soon as you do that, which is something that we're seeing a push for from service providers, that in turn then forces the underlying infrastructure provider to change the way that they supply service and as soon as you do that then the market is open for an interface provider. And I think that if that -- if the infrastructure providers don't do it themselves then a third party will write a series of APIs that interface into the largest and loudest cloud providers and provide that API themselves.
So I don't think it's going to be -- it's either going to be something that's done by the infrastructure providers themselves or it's going to be some small smart aggressive start-up which you can invest in if you just write me a cheque for it I'll give you a return. But it'll be a small, aggressive, flexible kind of provider who will provide that interface and then I think open up an entire market. And I certainly would be surprised if five years from now we don't have some sort of essentially live almost stock market kind of environment to be able to buy compute services from multiple providers.
Is this a call for a set of standardised cloud APIs and so on?
Yes, I'm not the one that's calling for it but certainly I'm starting to see that as something that the application service providers are starting to ask for, yes. And how long it's going to take them to convince the infrastructure providers is going to be the interesting piece.
That was the next question.
And I think that some are going to want to resist that. So those that are already taking billions out of the business in providing platforms are going to resist it. Those that need to build market share are going to be more or less forced to do that in order to get their foot in the door because they need some point of differentiation.
Okay, thanks. Have we got time for some more questions?
Steve Broadhead at Broadband Testing. Just to continue the theme here, yes, there are lots of problems. If we go back to the point where in the late 80s when companies who sold biscuits found out they were actually better at IT than they were at selling biscuits and then had to kind of retrace their steps and reinvent themselves as the company who sold their core business. The problem we've got here is exactly that where you've got application companies who are trying to be network builders and then network builders who have to understand applications in order for the cloud to work.
What that then requires obviously is companies who would never politically work together working together. The fundamental issue here is that to get to point-tomultipoint or any-to-any connections you do need lots of optimisation technologies. I do a lot of optimisation technology testing. The issue there is that the technologies work but they're all proprietary. So then you've a starting point which indeed is how do you get standards based to say that company A in one part of the world is going to use the same technologies as company B in another part of the world so that all those optimisation technologies work end-to-end. And I don't see how that works.
What's the question?
So the point is who's actually going to come in at some point and say yes, can we establish some standards or which two major companies, vendors in the world who basically are complementary in terms of applications and networking come together and provide the next step beyond Amazon, the next step beyond Google etc.? Who's going to be the first to do that?
So de facto or passed down from above. Our view in this market or -- I suppose I don't want to represent it too widely -- so my view in that market is I'm approaching that question in a different direction. So my objective is that I believe that a large part of the solution of this how do you make all of it work together in a more easy kind of way is I want to drive all of your data centres to look like they exist on the same LAN.
As soon as they all exist on the same LAN then really what you're trying to solve is a software problem rather than a networking problem. So a lot of the issues come in because you've got to have interoperability between how x marks their traffic prioritisation and y marks their traffic prioritisation or you have -- as I said many service providers have a cloud that's provided by or underlying transport clouds provided by two different providers and then potentially also a point-to-point network that they've built up themselves.
That becomes immensely difficult to manage. So my view is if you could mark within your LAN a piece of traffic and then really I think what we have in fact delivered is a platform that allows you to mark a piece of traffic in your LAN in a certain way, pass it to a service provider and then determine -- your marking determines how that packet is carried through the carrier's network.
Historically what happened was you marked your traffic and then all you ever got to decide on was how it was queued in your service provider's network. That was very much the MPLS model. And I can't with 100% certainty know on an MPLS network what route a given packet is going to take across that network because I don't control that, that's something that's dynamically driven.
If you as an end user could say I want that packet to be queued in a certain way but also I want that packet to go on a specific known route and I want that packet to just certainly get to the other end or have any-to-any topology or whatever else it is, that is a tremendously powerful sort of thing. Then your issue becomes one of not deploying WAN acceleration devices and all the other stuff that goes around that and also a complex layer about how you move a virtual machine over a LAN, through a router, through a wide area network, over IP, back through a router and then back onto an Ethernet LAN and then back into a system. It doesn't become that problem any more, it becomes as far as the software is concerned a LAN to LAN move and that becomes a lot easier.
So my view is you can solve an awful lot of the problems that you're creating by introducing a WAN element by making that WAN element look like part of the LAN that links the servers together anyway.
Now what that means is it's very "simple" from the customer's perspective, it's immensely complicated from the service provider's perspective. But I think that's kind of where we have to go. Because otherwise you're trying to create interfaces between a plethora of different types of WAN and WAN behaviour and all of that sort of thing and I don't see how do you do that in a quick and easy sort of way.
So I'm afraid that's a very parallel answer to your question but hopefully it's -- yes.
Right, time for one more question. Yes, Rob?
Hi, Rob Bamforth, Quocirca. I was at a meeting of CIOs discussing cloud computing last week and the big question was not about packets or WANs but contracts and responsibility. What are your thoughts on that aspect, legal liabilities and responsibilities?
Yes, so we're starting to see a few things like consequential damages being introduced into contracts. The interesting thing is that as the actual amount of money being spent on the WAN reduces, if you took a 100Mg point-to-point LAN type environment, WAN type environment from three or four years ago and bought the same network today you're talking about a 60% price decline or a 50% price decline.
So it's interesting that the requirement for me to take a higher responsibility for my network going down is coupled with the amount of revenue I'm actually receiving from that customer falling. So there is a fundamental disconnect between what the company that's providing the service wants and what the telco or the infrastructure provider is actually able to do because my finance department is never going to agree to -- here's a customer spending $1m a year with you, consequential damages are $25m. It's never going to -- that gap is never going to be bridged.
So the reaction that some service providers are having to that is saying okay, then I'm going to take multiple providers and I'm going to build my own network and I'm going to build it to a standard that I understand. That's an extremely risky approach to my way of thinking because as we said earlier, they're not necessarily great at that bit.
But they are starting to go down that track.
The other way is just to say look, I have to understand in very great detail what it is that I'm being provided by my network service provider and then I will do my own risk assessment. But this wish list that I'm going to -- I as a service provider am going to sign up to a blank cheque and you're going to be paying me $100,000 a month, it's not realistic, it's not -- there's no reason for me to want to do that, there's enough other business at the moment for me to not have to take that on.
So I suppose as a service provider my ability to agree to those is a measure of my desperation to take on new business and I'm not that desperate.
Okay. Any other burning, burning questions otherwise we'll move on to the next session? Okay, James Walker, you've been a sport. Thank you very much.