Following our article on the Future of Online Video and on Amazon’s platform business model we look here at another interesting product from Amazon – Cloudfront – to tease out some more lessons for telcos:
Everyone’s impressed by the low low prices Amazon Web Services is offering for content delivery from its new content delivery network (CDN), “CloudFront“. Heavy users might pay as little as $0.09 a GB!
This feeds into another story — the paradox of CDNs’ increasing importance, but decreasing profitability. Nobody seriously considers working with heavy traffic sources like video without using a CDN of some description. This is chiefly because their importance has led to a wave of new entrants – both VC-funded startups and telcos who integrate CDN capability in their networks – and a price war. Surely, Amazon’s entry to the market must mean a further wave of price-slashing?
But there are reasons to suggest that CloudFront is considerably less revolutionary than it sounds:
That’s not a heavy user – *this* is a heavy user!
For a start, there is one significant exception as regards CDN profitability – Akamai Technologies, the original CDN operator, is making more money than it ever has done. And this is quite likely to be the case, even with Amazon offering low, low prices — as Dan Rayburn points out, what Amazon considers a heavy user (over 150TB/month) is nowhere near as heavy as what Akamai considers a heavy user (closer to 800).
Further, the only way CloudFront accepts requests is as HTTP GET requests; we tend to describe things like YouTube as “Web video”, but it would be more accurate to say that they are video wrapped in the Web. In fact, the actual streaming occurs between the Flash application running in your browser and the video server, using their own streaming protocol. This is how PlusNet were able to “characterise iPlayer traffic so easily. Video streamers won’t get much benefit from CloudFront yet – it is possible to stream over HTTP, but it’s noticeable that nobody does when they have any other options. By comparison, Akamai (and friends) positively specialise in handling seriously large volumes of music and video.
All CDNs are not the same
In effect, CloudFront isn’t a CDN so much as a mirror server, the old-fashioned way of distributing static files. CloudFront would be a great way to deliver images, software distributions, or video for download, as long as you weren’t planning to do Akamai-like volumes and you weren’t particular about latency. Going by the published list of CloudFront server locations, it seems that Amazon has opted for a deployment strategy that places servers at major Internet exchange points, rather than pushing the CDN further down into the ISP infrastructure.
For example, the European locations match the top three IXen – LINX, AMSIX and DECIX, and the North American ones match up with PAIX, NAP of the Americas, Equinix Ashburn, 111th St NYC, and the two in Seattle. This is cheaper in every way, but it faces fundamental limits.
Here’s a BGPlay visualisation of an Amazon Web Services prefix from their European data centres:
Obviously, content from a macro-CDN like Limelight or CloudFront must transit your internal network to reach the access network. Further (as Akamai pointed at last autumn’s Telco 2.0 Executive Brainstorm), as bandwidth increases, round-trip latency accounts for a bigger chunk of the time it takes a particular chunk of content to arrive, making CDNing more important. The haul from the CloudFront server in London could easily be of the order of 400 miles for subscribers in the UK and Ireland; as UK webhosting is so concentrated in London, this is arguably little better than naive serving.
Akamai’s deployment strategy is the opposite – they endeavour to put content servers as far into the eyeball ISPs’ networks as possible, so as to shorten the round-trip time and save traffic on metro networks as well as backbone networks. Also, Amazon doesn’t seem to be planning a Google-like peering strategy, as its Internet presence is entirely accounted for by its transit providers (NTT America, Level(3), Qwest and Tiscali). Compare the list here, for Amazon, and Akamai’s European network.
Here’s a similar visualisation of Akamai’s London network:
Cache is king
Further, it doesn’t yet provide for dynamic content (like enterprise applications, gaming, user generated content, e-commerce etc), where most of each page has to be generated by an application on request. As CloudFront requires the use of Amazon S3 storage, we’re obviously thinking in terms of all-Amazon Web Services development here.
Consider the case where some application has a Web server running as an Amazon EC2 instance. Now, the server could also be an application server itself, or it could be the frontend to an app server running elsewhere in EC2. It doesn’t matter. When the server receives a request, it has to either process it or call the app server and wait for the callback to return, depending on the details. But once it has the response, it would have to then write it to an S3 bucket, and then call the CloudFront API to register the new content, handle the response, remake the Web page accordingly, and then do the same process again to put the page on the CDN, and redirect the user there.
There are a lot of moving parts there, and a lot of latency-generating operations — and you have to use S3, a storage service — rather than Amazon’s message queue service. Akamai, however, has a whole specialised CDN (Edge Computing) devoted to dynamic content and application servers. The big CDNs also provide a lot of other functionality for your money – greater or lesser integration in your DNS, use of your own origin servers, access to raw server logs or to data provided by their analytics program.
So if it’s not suited to streaming or dynamic content, it doesn’t reach down into the eyeball networks, and it doesn’t offer anything special in terms of analytics, what is it for?
Keep it simple, stupid
The first thing is that it’s a simple solution for simple problems. Got a startup? Are you yourself a startup? Got a credit card? You’ve got yourself a distributed Web-serving infrastructure. We can certainly imagine small software companies, who can be small in the sense of one or two people and typically have to load out lots of very big files that can easily be broken, finding this very useful. Another wonderful feature about all the AWS products is that the notion of “bursting” your bandwidth allowance is disposed of. Haven’t you noticed that popular sites stopped disappearing behind “Contact Our Billing Department – SomeISP.com” splash pages about when S3 was launched?
The second is that it’s easy for Amazon. They have to have a presence at major IXen to keep their infrastructure going, they have to push out really enormous numbers of graphics files to generate Amazon.com pages. Why not extend it a little, create yet another way to interact with their core infrastructure, and generate even more of those lovely transactions?
Conclusion: it’s another spin of the flywheel
The big take-away from this is that Amazon are following their classic “flywheel” strategy that we “wrote about last week”. They reduce prices and costs of entry to the “long tail” of merchants and application developers. Capabilities that only the “big boys” could access before are democratised. This drives volume across the whole of their platform infrastructure.
Whether Cloudfront is profitable or even competitive against Akamai is almost a moot point; it’s like asking if a particular robot in a Toyota car assembly plant is profitable. It makes no sense in their strategic worldview. Amazon’s platform is more than the sum of its parts, and it just added an important new part. Telcos should not only learn from this, but also take heart – quality distribution is still an area with big opportunities for those who are willing and able to provide it.
Read our latest research on the future of telco and what this means for operators and their partners.