Google Blog Platform

A few years ago, in the early days of blogging, Google made a play to buy the Blogger platform. What occurred after that was a long period of time where Blogger received no love from their new parents. Also during this time, Movable Type came along and was then eclipsed by WordPress. WordPress went from a project to a business with the advent of Automattic and WordPress.com while the software remained an open source project for anyone to use and build upon.

It wasn’t until WordPress.com came along that we began to see some forward motion with Blogger. Google tied it to their authentication system and added some spit and polish, but nothing earth shattering. One of the biggest failures of Blogger is not the platform, but the management. It is the single largest source of splogs (or spam blogs) in the world – a failure of leadership that can be placed squarely at the feet of Google management. Meanwhile, WordPress.com is an open and airy environment that is policed actively (but passively, if that makes sense – no one is being a Nazi about content, but spam is ruthlessly dealt with).

While Google continues to release a parade of new products (anyone tracking the release of Google Shiny(Beta) today?), some of their largest and most potentially lucrative assets continues to meander aimlessly in an industry that continues to expand at a relentless pace.

Here’s a comparison between Blogger and WordPress.com

Blogger WordPress.com
Cost Free Free*
Personal Domains Yes Yes*
Template Control Yes CSS*
Javascript Yes No
Discoverability No Yes
Remote APIs Blogger Movable Type, Metaweblog, Atom, WordPress
Portability w/Domain Hosting only WXR Export
* Optional Paid Upgrade

Of all the migrations I’ve ever made, the biggest challenge exists around Blogger blogs. I’ve moved WordPress to WordPress, Movable Type to WordPress, Blogger to WordPress, Serendipty and Expression Engine to WordPress. I’ve moved TypePad to Movable Type. Blogger to Movable Type. You get the point. The most difficult migrations are off of the blogger platform.

Mark Evans suggested this morning that Google buy WordPress.com for name recognition and platform familiarity. The idea is to bolster the suite of services that Google offers now that it will have its integrated browser. Mark argues that WordPress.com has tons of traffic.

Here’s a hint though. Google doesn’t care about traffic. Plus, they have Blogger. Granted, Blogger sucks but according to Compete, it gets more traffic anyway.

Picture 2.png

So here’s what we know. Blogger gets more traffic, but savvy users like it less (particularly the UI and SEO). We also know that Blogger is a closed platform and that it is laden with spam. We know that Blogger is under very little active development, or their release schedule is abysmal.

We also know that WordPress is an open source platform that invites external developers to hack on it. We know there’s viable business in using the platform (hey, you don’t have to pay for active development on the platform!). We know that there is a hosted and self hosted version currently and that the WXR format makes it easy to transfer data around. We know that Akismet is open source and can be used to kill spam as well. We know that there are tens of thousands of people developing themes, plugins and offering knowledge. We know that it is possible to have a hosted version of WordPress in the vein of Blogger. We know Google engineers are smart.

So here’s what I propose instead. Leave Automattic alone. Let them keep innovating and building their enterprise client list like the New York Times, Dow Jones, and more. Matt has no interest in Google (at least he didn’t) as his philosophy is largely incongruous with Google (open source via mostly closed source).

Instead, Blogger should be transformed into an WordPress MU platform. Google engineers can solve problems such as providing FTP to other hosts, as Google has, with the new WP_Filesystem class that is used for plugin and automatic upgrades.

They can use their cloud to provide DNS services to point Blogger blogs to a different host, as they do now. They can tie in Google Auth with the available hooks. They can even port existing Blogger theme offerings to WordPress themes.

They retain the traffic and immediately compete on a close level, at least by all tangible metrics, with WordPress.com. Of course, there is that little thing about management styles where WordPress.com wins hands down in the current paradigm, but… thats something that can’t be addressed by technology.

Personally, I think it’s a solid play. May not happen, but it probably should for Google’s sake.

Cloud Computing Does Not Spell the End for Common Sense I.T. Management

Sometimes I think I might be the only one who retains commons sense. Really. At least in the area of I.T. Management. Though we had our share of growing pains at b5media, the knowledge gained from working in an enterprise environment at Northrop Grumman was only accentuated by my tenure as the Director of Technology at b5media.

Unfortunately, some common best-use practices in developing infrastructure are often put aside by those with shiny object syndrome surrounding “cloud computing“.

Let me explain.

You may have noticed a severe hampering of many internet services over the weekend. The culprit was a rare, but yet heavy-duty outage of Amazon S3 (Simple Storage Service) cloud storage. S3 is used by many companies including Twitter, WordPress.com, FriendFeed, and SmugMug to name a few. Even more individuals are using S3 for online data backup or for small projects requiring always-on virtual disk space. Startups often use S3 due to the “always on” storage, defacto CDN and the inexpensive nature of the service… it really is cheap!

And that’s good. I’m a fan of using the cheapest, most reliable service for anything. Whatever gets you to the next level quickest and with as little output of dollars is good in my book, for the same reason I’m a fan of prototyping ideas in Ruby on Rails (but to be clear, after the prototype, build on something more reliable and capable of handling multi-threaded processes, kthxbai.)

However, sound I.T. management practice says that there should never be a single point of failure. Ever. Take a step back and map out the infrastructure. If you see anyplace where there’s only one of those connecting lines between major resource A and major resource B – start looking there for bottlenecks and potential company-sinking aggravation.

Thus was the case for many companies using S3. Depending on the use of S3, and if the companies had failover to other caches, some companies were affected more than others. Twitter for instance, uses S3 for avatar storage but had no other “cold cache” for that data rendering a service without user images – bad, but not deathly.

SmugMug shrugged the whole thing off (which is a far cry from the disastrous admission that “hot cache” was used very little when Amazon went down back in February), which I thought was a bit odd. Their entire company revolves around hosted photos on Amazon S3 and they simply shrugged off an 8 hour outage as “ok because everyone goes down once in awhile”. Yeah, and occasionally people get mugged in dark city streets, but as long as it’s not me it’s okay! Maybe it was the fact that the outage occurred on a Sunday. Who knows? To me, this sort of outage rages as a 9.5/10 on the critical scale. Their entire business is wrapped up in S3 storage with no failover. For perspective, one 8 hour outage in July constitutes 98.9% uptime – a far cry from five 9’s (99.999%) which is minimal mitigation of risk in enterprise, mission-critical services.

WordPress.com, as always, comes through as a shining example of a company who economically benefits from the use of S3 as a cold cache and not primary access or “warm cache”.

Let me stop and provide some definition. Warm (or hot) cache is always preferable to cold cache. It is data that has been loaded into memory or a more reasonably accessible location – but typically memory. Cold cache is a file based storage of cached data. It is less frequently accessed because access only occurs if warm cache data has expired or doesn’t exist.

WordPress.com has multiple levels of caching because they are smart and understand the basic premise of eliminating single point of failure. Image data is primarily accessed over their server cluster via a CDN, however S3 is used as a cold cache. With the collapse of S3 over the weekend, WordPress.com, from my checking, remained unaffected.

This is the basic principle of I.T. enterprise computing that is lost on so much of the “web world”. If companies have built and scaled (particularly if they have scaled!) and rely on S3 with no failover, shame on them. Does it give Amazon a black eye? Absolutely. however, at the end of the day SmugMug, WordPress.com, Friendfeed, Twitter and all the other companies utilizing S3 answer to their customers and do not have the luxury of pointing the finger at Amazon. If their business is negatively affected, they have no one to blame but themselves. The companies who understood this planned accordingly and were not negatively affected by the S3 outage. Those who weren’t were left, well, holding the bag.

Added: GNIP gets it, and they are new to the game. Even startups have no excuse.