On Thursday of last week Amazon Web Services took the rare step (for them) of pre-announcing a product - specifically that they will be offering a CDN service to the general public before the end of the year. They, as one would expect, are offering a no commitment pay-as-you-go model that they’re known and loved for.
Naturally, the tech blogs are abuzz with the news - and rightly so. It’s a huge step forward to increasing the value of their offerings and, at least if you think like we do, is getting out in front of where the market is going to be in short order.
Dan Rayburn lends some insight on his post on the Streaming Media Blog - and while he rightly determines that this isn’t immediately disruptive to the ‘bread and butter’ clients of the big CDNs, I think it will greatly erode their ability to compete on the medium-sized HTTP-only deals that are going to be required to help them meet the expectations of the Street (without compromising their existing premiums) and will be a real wake-up call to them and the market in general.
It’s actually impressive how far AWS has come - without any real background as a hosting company, they’re proving quite well at reading and then adapting rapidly to market needs.
At Voxel, we saw the need for CDN to be integrated directly into hosting packages when we we first started building our CDN over two years ago. Almost 4 months ago, we announced direct integration with Amazon’s S3 service via their API, supporting authenticated buckets (which Om Malik kindly pointed out in his excellent coverage of the announcement over at GigaOm). On Wednesday of last week we announced our Universal Transfer – offering zero commitment, usage based billing for all bandwidth – whether it’s from servers or the CDN. In fact, the CDN is included at no additional charge with all of our hosting packages. I’d like to think (of course) that their timing is a bit more than a coincidence and that our latest salvo has given them some cause for concern.
After all, from a CDN perspective, we have a significant head start over Amazon – their initial scope discusses only HTTP progressive download and in a seemingly limited scope. It will be interesting to see how they handle expectations in the CDN market – based on their press release, it seems like they may be delivering from as few as 4 or 5 locations. From a performance standpoint, for any true CDN users this won’t really cut it. Will it be better than standalone S3? Of course – but beating single location delivery isn’t exactly a feat.
On top of that, CDN users expect a certain level of features beyond basic HTTP delivery – certainly not least among them is authentication, logging and specialized reporting. A radio station looks at numbers in a different way than a video portal or an e-commerce site and this needs to be reflected in the way you give them information so it can be meaningfully processed by the clients. However, almost all these clients will require ‘protected’ content sooner or later – and Amazon will be need to be able to authenticate users based on criteria set by the client. Building the requisite features (and the value adds) was a big priority for Voxel when designing VoxCAST – and Amazon is going to need to get a lot more “hands on” and application oriented to fulfill their new role as a CDN to their customers.
The other major consideration is that their press release initially mentions nothing of Flash or Silverlight – both of these technologies are essential for many of the applications being built today – and they’re only going to become more prevalent tomorrow. Amazon has seemed to tailor the initial CDN salvo to their lowest common denominator – their clients who want to distribute simple HTTP content with minimal performance requirements. It seems to simply be lip service to placate the masses and buy Amazon more time before more of their customers look to S3 compatible CDNs like VoxCAST or PantherExpress to do their delivery.
Naturally, I expect Amazon will be playing catch up ball with a purpose – they’ll have to come out and feature match against CDNs like VoxCAST, supporting more advanced delivery formats and applications, as well as dig substantially deeper in understanding the needs of their clients beyond moving bits around. CDN customers expect 24/7/365 support for more than just an API.
I think what we’re doing with our CDN at Voxel and how we’re utilizing it with our Universal Transfer represents the Holy Grail of what hosting should be – clear, concise and affordable. Like what Ford did for transportation with the Model T, we’re both doing for the hosting market by making CDN services accessible to everyone - and all consumers will appreciate that. Combine this with offering world class proactive systems administration and support and we have an unbeatable value proposition. We take full responsibility of your delivery from your servers all the way through the CDN - and we’ll be here to help you when you need us.
CDN is an integral part of the hosting ecosphere - there truly isn’t a single website that couldn’t benefit from it, and just as importantly, no reason that it shouldn’t be easily, transparently and cost-effectively purchased.
So, while Amazon has a long road ahead of them to catch up, they’re moving in the right direction for the overall hosting landscape - and that’s good news for everyone.
Here’s to you, Amazon, and your first step down the path of integrated CDN - if you want to submit patches to enable your CDN to work with our mod_cdn out of the box, we’d be pleased to have you!
Posted in General Posts |
October 22nd, 2008 at 5:58 pm
Interesting ramblings Sam .
I have not used Voxel yet, although you guys are on my list of providers to try out. I’ve heard good things. I will be contacting you this month. Does Voxel offer any sort of free trials for larger traffic sites?
Here is some information I found about the Amazon CDN after digging a bit. I found some of this stuff out by accident. I figured I would share.
I noticed some images being served from enstxzrnsprxt.6hops.net – when I do a traceroute I get:
6. ae-12-55.car2.Newark1.Level3.net
7. AMAZONCOM.car2.Newark1.Level3.net
8. 216-137-40-129.ewr2.cloudfront.net
Check out the hops there. It appears that Amazon is in Newark connected to Level3, and the domain cloudfront.net is interesting.
When I do a WHOIS lookup on cloudfront I get the same pseudo-anonymized registration information as 6hops.net. Interesting eh?
It gets more interesting. If I check the ASN for that IP I get:
[dbutler@zonker] ~> whois -a 16509
OrgName: Amazon.com, Inc.
OrgID: AMAZON-4
Address: 605 5th Ave S
City: SEATTLE
StateProv: WA
PostalCode: 98104
Country: US
Hmmmmmm, what is this mysterious cloudfront?
Trying 216.137.36.152…
Connected to 216.137.36.152.
Escape character is ‘^]’.
GET / HTTP/1.1
HTTP/1.0 400 Bad Request
Server: S3Cache
Date: Wed, 22 Oct 2008 11:16:20 GMT
Content-Type: text/html
Content-Length: 1171
Expires: Wed, 22 Oct 2008 11:16:20 GMT
X-Cache: Miss from cf-pxy
Via: 1.0 fff0fbeaa9a952d8e03289463bc6f830.cloudfront.net:11180 (S3Cache)
Proxy-Connection: close
A-ha, note the references to ‘S3Cache’ Sounds like this could be their new CDN offering!
Further evidence in some DNS lookups from some of my servers hosted with various providers around the world:
enstxzrnsprxt.6hops.net is alias’d to enstxzrnsprxt.ewr2.6hops.net
enstxzrnsprxt.6hops.net is alias’d to enstxzrnsprxt.iad2.6hops.net
enstxzrnsprxt.6hops.net is alias’d to enstxzrnsprxt.sfo4.6hops.net
Those are the only alias’s I could find.
So, just an FYI seems Amazons service is called CLOUDFRONT or 6HOPS.
Assuming the codes for DNS correspond to airport codes, they have confirmed nodes in NEWARK, VIRGINIA, and SAN FRANSISCO.
The plot thickens!