Some of those criticisms are baseless.  Technical reporters have a really hard job. They write about complicated subjects for a really broad audience, so they have to try to both get it right and make it interesting (or at least comprehensible).  The sad fact is that most tech journalists fail on both accounts. This happens in part because tech journalists just don’t have the serious technology background that they probably need to write accurately and coherently about the things they write about.  And it also happens because in an effort to be more comprensible and relevant, many journalists gloss over or flat out change details that matter.

A funny, and frustrating, example of this occurred recently when Jason Perlow tried to explain why Limelight Networks was better than Akamai at serving Olympics content for NBC. Perlow stacks generalization upon inaccuracy and ends up mistating the facts and miseducating readers.  All of this can be clearly, and simply detangled.

Perlow is trying to explain why NBC chose Limelight Networks (Autonomous System Number 22822) over Akamai Technologies (ASN 12222 and 20940 among others) to serve streaming content of the Olympics.  Perlow writes:

“Akamai uses a centralized data hosting infrastructure with big Internet pipes that mirrors content that is hosted on a customer’s own servers. Usually with the aid of a special caching appliance installed at the customer’s ISP or edge network, the request to download that content is re-directed to Akamai’s own servers and fat Internet pipes. When you download big ISO CD and DVD images from MSDN, its going right to Akamai’s data centers over the public Internet. As fat as Akamai’s pipes are, I’ve seen MSDN’s downloads slow to a crawl during peak download periods, such as the days following Windows XP SP3 and Windows Vista SP1’s release. So like my colleagues here at ZDNet, I was expecting the worst.”

So far, Perlow is not even wrong, a phrase coined by Wolfgang Pauli, but which I heard first from Thomas Pogge, a stellar and compelling philosopher who tried valiantly to teach me some Kant long, long ago. That is to say, Perlow isn’t making enough sense yet to be clearly refutable, since it’s unclear what he could possibly mean.  The gulf between the truth and what he writes is so large that the brain of any reasonbly technical person struggles to reinterpret everything he writes in some way that might be closer to reality.

Akamai most certainly does not have a “centralized data hosting infrastructure”.  In fact, Akamai has one of the mostly widely distributed hosting infrastructures (probably the most widely distributed hosting infrastructure) on the planet. Akamai grew up during the go-go days of the late 1990s when space and power were cheap and bandwidth was expensive.  Akamai pitched Internet Service Providers (IPSs) on a value proposition of allowing Akamai to put servers in your space and in exchange serving cached/distributed content to your customers (thereby saving bandwidth).

When I was Chief Technology Officer at Oso Grande Technologies, we ultimately cut a deal with Akamai to host servers with us because we thought it would save us bandwidth.  It did.  Hundreds of other ISPs made the same decision for the same reason. According to Akamai, “Akamai has the most pervasive platform for content delivery and application acceleration – 34000 servers in 70 countries within nearly 950 networks.”  That’s not centralized, hoss.

Limelight, on the other hand, tends to pay for colocation and put their servers in a relatively smaller number of locations (although still a massive number of servers).  This difference in architecture is probably for at least two reasons.  The first is due to when they scaled out.  While Akamai was building out a Content Distribution/Delivery Network (CDN) in the late 1990s and early 2000s, Limelight was still just a Phoenix-based ISP who mostly just resold Global Crossing bandwidth.  Limelight didn’t find their true identity as a CDN until much later.  So they were faced with a very different economic and industry landscape.  By the time Limelight was building out latency was lower overall, speeds were higher, bandwidth was cheaper and power more expensive.

The second reason is that Limelight specializes in streaming large files:  videos and downloads.  These files are much less sensitive to latency than the small picture and html files that Akamai was originally architected for and may also benefit from centralization of storage (to improve cache-locality). That last is a slightly subtle point and if it isn’t obvious to you, ignore it.  Doesn’t matter.  Anyway…

Perlow goes on to write:

Where Limelight differs from Akamai and why the Internet didn’t “melt” is quite simple — they are completely “off the cloud”.  In other words, unlike Akamai and similar content caching providers, their system isn’t deployed over the public Internet.

There are many differences between Limelight and Akamai. Some of those differences are even relevant to performance and scale.  Not only is that difference not related to performance or scale, it isn’t even completely true. Let’s review what he might be talking about.

CDNs replicate content “closer” to users and serve that content up quickly—more quickly than the originator could have served it to that user.  CDNs serve that content on the Internet, of course, so obviously any CDN (including Limelight) is “deployed over the public Internet”.  It would be idiocy to suggest otherwise.

What Perlow might mean is that Limelight replicates to each cluster over their backbone whereas Akamai replicates over the Internet.  That much is true.  He got something almost right!  Akamai does not have a backbone and rather they rely on their colocation and ISP partners (and transit-providers’) bandwidth to replicate content to their server clusters.  Who cares?  In order for that to matter you would have to believe in a world where the first copy of the source content to the server cluster was routinely failing.  That doesn’t make any sense.

The source content is copied out to many, many server cluster who then serve that content hundreds of thousands of times to customers.  Those server clusters are heavy on the outbound-bandwidth and very, very light on inbound bandwidth, since the bits going out go to customers and the bits coming in go to the servers.  Since data circuits on the Internet (except for at your house) are symmetrical, there is always a surfeit of inbound bandwidth available.  Whether you copy the data across a backbone or across the Internet, it’s going to get there.  This difference between the two companies has nothing to do with whether end-user performance is slow or fast.

In the end, we’re left to wonder:  does Perlow understand anything about Internet routing and CDNs at all, or did he just confuse users by glossing over details that he actually does understand?  At this point, we don’t know…

[Disclaimer:  I know and have long relationships with people from both Akamai and Limelight in my day job at Renesys.  They're both good companies doing interesting work.  I don't have a particular opinion over which CDN is better since I use neither.  But both deserve more accurate coverage than this.]

“Of all places, I never would’ve expected to build my startup in Pittsburgh. I moved to the ‘burgh from Chicago when Sonya Labs got a seed-stage investment from AlphaLab. It is not so unfathomable that I’m here, though, it actually makes quite a bit of sense. Even Paul Graham, a Pittsburgh native, who is famous for advising that startups go to Boston or Sillicon Valley says so!”

I have read this Paul Graham essay before (and found it frustrating, given where I was living and would be living, but not obviously wrong).  But I had totally missed the fact that Graham is from Pittsburgh.

Graham’s central point is that Pittsburgh has plenty of tech talent and not enough money to create a startup environment.  Specifically, he argues that there are “no rich people”.  I’ve only been here a few days, but that seems obviously wrong.  There may be not enough rich people or not enough rich people investing in high tech companies, but that’s very different from arguing that there are no rich people.

Sonya Labs argues that the presence of good technical talent, combined with lost cost of living make Pittsburgh an almost-ideal startup city.  They spend some time talking about how to make Pittsburgh a more obvious choice to people in other cities thinking about relocating in order to start a business.

When I lived in Albuquerque, I worked with the New Mexico Information and Software Association (NMITSA).  One of the hardest problems we faced was with the idea of how to get more of a startup, innovation economy going in Albuquerque and Santa Fe.  That area had two national laboratories, a decent research university, a metro area of about 500k people, and a bunch of tech-oriented rich people with second homes running around.  But it was much harder to get that kind of economic activity started and running than I thought it would be.

I will be very interested to see how Pittsburgh shapes up in this regard over the next several years.  On the face of it, Pittsburgh has several advantages over New Mexico.  It is a much bigger city than, Albuquerque.  It has more (and better–sorry UNM!) universities.  And there is already a certain amount of start-up infrastructure here.

So what is Pittsburgh missing to make it really take off? Tax policy?  More money?  A few dedicated (crazy?) people?   Anyone?  Bueller?  Anyone?

The new offering is likely to ruffle feathers on at least three fronts and will shake up the analytics industry over the next several months.  It should be interesting to see it play out.  In the process of trying to shore up a key part of their own business, Google is likely to make a few new enemies and may even endanger a current stream of data.

The offering is supposed to detail which populations of users are visiting what sites.  If it is integrated into the adwords system, then ad buyers would be able to see more about the audience of the sites in the content network in order to determine which of them are worth advertising on.

Adwords users already know that the content network is the weakest, most underdeveloped part of Google’s ad-selling empire.  What we’ve seen, in placing small ads for Babbledog over at Renesys, is that the click through rate (CTR) of the same ad on various parts of Google’s content network gets 1% or less the CTR of the exact same ad placed on search.  The low CTR on the content network is a known problem whose official answer is “those content pages are just so darned interesting that people don’t always see the ads!  honest!” The more likely explanation is that there is a behavioral difference involved.  People who are searching are in the act of reaching out and trying to answer a question or acquire information.  In that mindset they are much more receptive to well-targeted paid answers to their questions than they are when reading icanhascheezburger.com.

This is trouble for Google.  Search is already monetized and its growth will be relatively small.  On the other hand, the content network could, conceivably, be as large as the Internet as a whole.  That’s probably bigger.    But in order to make more money off of the Internet as a whole, Google has to do two things: 1) get more ads on all those pages; 2) get more viewers of those pages to click on those ads so that Google gets paid and advertisers are happier.  This new website analytics product is designed to do just that.

The WSJ says that advertisers might be worried about giving too much of their money to Google.  Since Google already has a dominant market share for online advertising, they might worry that they should not use Google for website metrics, too.  It’s a matter of trust.  Still, free is hard to argue with.  Comscore and Nielson Netratings should be worried.

There’s an interesting backstory here that is barely covered in the WSJ article.  Where is Google getting the data for this product?  ” Google’s new offering will be based mostly on data from Web servers, allowing for a deeper and broader view of Internet use.”  Hrm.  “Data from Web servers”.  What webservers?  Yours.

It’s obvious that Google is finally cashing in on their free Analytics product by aggregating all of your web hits and putting them to work for advertisers.  This should be of no surprise to anyone, since Google’s entire enterprise is about aggregating all of the data out there and putting them to work for advertisers.  However, the nakedness, the blatantness of this particular scheme may surprise some people and may make it more difficult to justify that “free” Google Analytics account.

All of this should have people thinking about the subject of website analytics and why this is big business in the first place.  Jay Adelson, of Digg and Revision3 fame, wrote an excellent piece about the sorry state of the web analytics industry last year.  He wondered why large sites couldn’t just publish audited web stats from their own logs rather than relying on silly panel-based metrics such as Comscore and Nielson offer or extrapolated data such as Google is likely to offer.

I have to say, he has a point.