Cloud computing and the coming clone wars

All this talk about Dell’s place in the cloud computing ecosystem has got me thinking… I’ve been saying for a long time now that the hardware market will turn into a bloodbath, with squeezes on the server side coming from horizontal scaling/commoditised hardware, multi-core processing, virtualisation, etc. as well as on the client side from cheap computers that we’ll (hopefully) soon be able to purchase by the kilo. It is no surprise then that the traditional vendors are clamouring for their slice of the (next generation) pie. And who better to service our cloud computing needs than the very same people who have been fitting out data centers for decades?

The problem is that a ‘cloud computer’ (on both sides of the fence) is a completely different beast than traditional client/server devices. Rather they are (or at least can be):

  • Smaller, a lot smaller (think cigarette packet)
  • Cheaper, a lot cheaper, like an order of magnitude cheaper (think <$100 before long). They last a lot longer too.
  • Greener, drawing only a few watts instead of hundreds (think 2-5W)

The JackPC pictured here isn’t a great example because it currently lacks a capable browser (though I’ve addressed this with them so maybe they’ll add a recent browser at some point) but you can still run one on the server and access it via terminal services, and it illustrates my point well.

I was in fact so convinced of the trouble ahead for traditional hardware that I even built a prototype of an ultra-cheap PC over 5 years ago now. I was looking for something fast, secure, environmentally friendly and easy to support (which meant absolutely no moving parts) and ended up with a Debian GNU/Linux based design. The idea was that it would have no persistent storage (booting itself over the Internet), offloading as much as it could to ‘the cloud’ (which at the time meant my Xbox cluster running Linux). Unfortunately back then the Mozilla browser was still playing catchup and tools like Google Docs didn’t exist so (itself in a sorry state, having just morphed from StarOffice) were required on the client. This arrangement worked nicely on the LAN by offloading much of the work to terminal servers via rdesktop (an RDP client written by a scarily clever young guy called Matt Chapman who worked with me at UNSW). However at home the 256/64k ‘standard’ ADSL Internet connection in Australia just didn’t cut it – people won’t wait 10-20 minutes for their machines to start even if they only need to do so every once in a while (eg to pick up security fixes).

Hang on, did I just say Xbox cluster? Yes, it’s amazing what lengths you’ll go to when you have some time but limited budget (datacenter space was still expensive back then). With servers still going for a few grand a piece and the Xbox selling with a reasonably capable processor, adequate RAM and a relatively sizeable hard drive for only a few hundred it was a no brainer. Apache doesn’t need much in the way of resources (even if the things it hosts including PHP, Perl, Ruby and Python do), nor does infrastructure like mail servers (qmail), dns servers (djbdns), etc. Yes it was a pain having to solder 29-wire modchips into half a dozen devices to bypass the DRM and no doubt they raised some eyebrows in the datacenter where they were hosted, but they did their job well for a long time and were even used for some fairly large jobs. This was the first taste of cloud computing (on a very small scale) and I’ve been hooked ever since.

I’ll leave you with one final thought for today… the picture on the left is one of Google’s first production servers. It now lives in the Computer History Museum and there’s at least one more like it which I’ve seen ‘in the flesh’ at their Mountain View HQ. These are not so different from my Xbox cluster (though the software on these machines made some people extremely rich), and are evidence of the completely different approach needed to build something like the Google platform. The focus now is on size, efficiency, heat, performance per Watt and per dollar, interconnectivity, density, and a bunch of other factors that only really become apparent when you roll up your sleeves and try to do it yourself (The Google Guide to Datacenter Construction is a book you won’t see at your local bookstore any time soon – this is a key component of their ‘secret sauce’).

The thought for the day then is where are the logos? There’s no Intel Inside logo on the JackPC or the CherryPal, nor a HP, IBM or Dell logo on Google’s rack…

Proof Gmail IMAP (Gimap) supports IMAP IDLE

So for those of you with capable mail clients (like OS X, here’s proof that IMAP IDLE works for delivering push mail:

$ openssl s_client -connect -crlf
* OK Gimap ready for requests from 0123456789abcdef
. capability
. OK Thats all she wrote! 0123456789abcdef
. login letmein
. OK authenticated (Success)
. examine inbox
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* 4498 EXISTS
* OK [UNSEEN 1431]
* OK [UIDNEXT 25141]
. OK [READ-ONLY] inbox selected. (Success)
. idle
+ idling
---mail sent and deleted here---
* 4499 EXISTS
* 4499 EXPUNGE
* 4498 EXISTS

This is invariably why some clients ‘feel’ more responsive than others, and why you should find an IMAP IDLE capable client.

Google Apps – On in 60 seconds

To celebrate today’s Google Apps launch here’s a screencast I whipped up showing just how easy it is with Google Apps to get ‘On in 60 seconds’:

Update: On advice from Dave Girouard (VP, Google Enterprise) we’ve changed the name to ‘On in 60 seconds’ from the somewhat less enthralling ‘Setting up Google Apps’.

Update: Thanks for the amazing response – 20,000 views! Let’s hope Google Apps is as popular as its video!

Update: The music in the video was that of Michael Johns, now one of the favourites in American Idol!