Last night I had a long conversation with Akamai (AKAM) about the inauguration webcast and got more details on the actual number of simultaneous streams they served and their methods and reasoning for capping customers on their network.
Many who are writing about inauguration traffic numbers are quoting from the Akamai press release and implying that Akamai delivered, at peak, 7.7 million video streams of the inauguration, which is incorrect. That 7.7 million number is the total number of all audio and video streams for all of Akamai's 2,800 customers delivered on their network that day.
Out of that 7.7 million number, Akamai said roughly half of that was just for the inauguration. That puts my earlier estimate of around 8 million simultaneous streams combined across the Akamai, Limelight and Highwinds CDN a little high, with the number being more around 7 million.
Akamai also stated that they delivered the live webcast for "twelve major broadcast customers" although I can't say who all of those customers were since they don't have permission to use all of the customers' names. How much revenue they earned from the inauguration webcast amongst all of those customers is not being shared right now since Akamai is currently in a quiet period. But if someone asks them on their next earnings call about this, it sounds like they might make that number public. Needless to say, it's not a big number and anyone who knows the space well knows that being in the live events business means tons of work, lots of headaches and very little revenue. These one-off, large-scale webcasts are not moneymakers for the CDNs.
Aside from the numbers, we also had a lengthy discussion about how and why Akamai caps customers and the business reasoning behind it. As much as some may want to think, there is no such thing as unlimited capacity on a day like the inauguration, even for Akamai. On the StreamingMedia.com discussion lists, there were some Akamai customers talking about how they had been capped by Akamai on the day of the webcast without asking to be. While some Akamai customers seemed upset by this practice, it's also important to realize that many customers did not provision properly for the event.
Many customers also were not willing to pay Akamai to guarantee a certain level of service or capacity. A few of Akamai's largest customers were in fact willing to pay more and paid upfront to guarantee they would have the capacity they wanted. Even with that, those customers went way over what they were expecting in terms of traffic and had to be capped. One major customer provisioned for 30GB and peaked at 125GB and Akamai still delivered it. But at some point, they had to cap what they would deliver when the customer is 4x over their capacity planning.
Akamai had to make a business decision to cap customers based on the fact that they have 2,800 other customers they have to keep up and running. Any other CDN would have made the same decision and when customers don't plan, or are not willing to pay to provision for a surge in traffic, no CDN can let that affect all of the other customers on their network. Imagine the impact to Akamai if they didn't cap any video customers on that day and as result, their e-commerce customers went down. Akamai has 83 of the top 100 e-commerce sites on their network and just think of the impact that would of had on the e-commerce industry if Akamai didn't take the necessary steps to keep video from taking down their network. This is simply the way CDNs have to operate on the rare occasions when something like the inauguration webcast happens.
Akamai did say that moving forward, they should cap customers using a better method by using things like a waiting room as opposed to viewers getting an error. The waiting room is what was used by CNN and while I didn't like the experience, it makes more sense to me now knowing the reason behind it.
But this also raises a very interesting scenario though since the inauguration webcast was a planned event. What happens if a major breaking news story happens and we see traffic like this again? In that case, CDNs would have to cap customers again since almost all customers do not pay any premium for what is essentially breaking news insurance, thereby guaranteeing them tons of excess capacity at a second's notice.
While the content delivery market as a whole has historically used marketing phrases to imply that they have "unlimited capacity", that's simply not reality. This is the way the Internet works and it puts things into perspective when many want to say that the Internet will drive broadcast TV out of business, that HD quality video will be delivered to millions anytime soon or that online video will get the same sized audiences that TV broadcasts get.
The Internet has major limitations for delivering video to large-scale audiences and while many want to complain about the problem being at the ISP end, or with the end users' broadband speed, the bottleneck is also on the CDNs' end.