Peering like this isn't all that new. Roughly 80% of our transit goes directly to our host's peers, which means they're probably not paying anything for that traffic (though they're charging us for it). We're happy with this because if it's going through a peer, it's much snappier for those particular users.

By doing this Google can skip most of the usual transit bandwidth tax, which is where most of the money traditionally goes to if you're sending massive amounts of data to end-users.

What tax? Sure, Google doesn't have to pay for transit while us mere mortals do -- but that's just because Google provides its own transit.

> Its costs for bandwidth are then amortized across the life of its fiber and routers.

It's basically the difference between 'renting' and 'buying', the costs can be (and probably are) significant though.

If you rent some resource you'll be paying bit-by-bit (pun intended), if you own it outright you pay it all in one big 'bite' .

So, their bandwidth bill is far from 0, it's just under a different heading on the balance sheet.

Building your own inftrastructure doesn't make bandwidth free, it just eliminates the cut that the provider normally takes.

Also, Akamai doesn't charge by the megabyte either, they charge by the megabit per second, as does most anyone once you start dealing with Facebook or Youtube-size loads.

When you peer, you no longer pay a 95th. You work out a peering deal with some provider you send a lot of traffic to and effectively connect directly to them in some shared facility. Some providers will charge you a 95th rate when you peer, but even then it's vastly cheaper than what you'd be paying for normal transit.

There's an "Akamai markup" which is a well known thing that Akamai charge for the heritage (somewhat analogous with the so-called "Mac-tax" except the Akamai "tax" is agreed to exist). A better comparison would be CDN pricing for Limelight or CDNetworks, the other two big players. It's worth bearing in mind that a lot of peering contracts for major carriers (but not necessarily Tier 1 - for example BT, Telefonica etc) depend on having a backbone - Akamai doesn't have a backbone, their backbone is the internet.

Also Google only do HTTP, so no Flash RTMP or Microsoft streaming which you effectively subsidise with an http product from a CDN.

Google also used Akamai for its Google Live broadcast which indicated that their network couldn't do RTMP (at the time).

the best way to not have your cost scale is probably to do what spotify is doing - make every user into a peer in a bit-torrent network and have them share the vast majority of the bandwidth consumption

A Glance at Spotify's Peer-to-peer Streaming: http://www.google.com/url?sa=t&source=web&ct=res&...

Now that google is a large enough force it could very well make money from offering bandwith, and isps will bid for it because not doing so would cost _them_ customers.

This article states that "[Google] has purchased unused fiber optic cable known as 'dark fiber'. ... Its costs for bandwidth are then amortized across the life of its fiber and routers." Sounds logical to me -- it doesn't seem like Google is "getting away" with anything here.

Yes, they very well might. The ISPs costs are largely fixed, it doesn't really cost them much to stream you a movie or whatever.

It's like the old memory/cpu/whatever is cheap argument. Yes it is, until you run out. Then you're in trouble.

http://blog.streamingmedia.com/the_business_of_online_vi/200...

I'd recommend Dan Rayburn's blog for a real-world perspective on CDNs, video etc.

Power is a major issue in datacentres here especially ones in large cities. I also wouldn't be surprised if Google use software routers instead of hardware beasts that cost as much as a house.