Amazon Elastic Block Store

This has been presented as a small, incremental step forward for Amazon's cloud-based computing. It's not. It's a big deal.

First, some grossly-simplified terminology. In the beginning there was Amazon Elastic Compute Cloud (EC2), which is your server(s). There was also Amazon Simple Storage Service (S3) which you can think of as being your network-attached file system. A little later they also brought out (though it's still in beta a.t.m.) Amazon SimpleDB which is your database and Amazon Simple Queue Service which is your messaging infrastructure. So what's the problem? Why do we need EBS?

Well I said "servers" above, but it's more accurate to think of EC2 instances as being like a CPU + RAM, where the RAM has enough space for a virtual disk. Your server does have some disk space attached ("instance storage" in the lingo) to which it can write files, but remember that the whole point of EC2 is that servers can get started automatically in response to demand, and that when demand falls, they can get automatically switched off. At that point, anything they've written to their local disk just disappears. I suppose it's the same as an object going out of scope and getting garbage-collected.

So if your web application, running on your EC2 instance, has done some work and updated some records, then it needs to salt them away somewhere outside the server-instance itself, and that's where S3 and SimpleDB come in. And of course, once you realise that your EC2 instance is probably going to need to save some data, it's but a step to see that it's also probably going to have to initialise itself, once it's up and running, from a data store too. So data passes between EC2 and S3 and SimpleDB in both directions.

So again, where's the problem? Well, I said that S3 was like a file system. It is, it's like some old, clunky PC-DOS 1.x floppy-disk-only file system, before you had directories and certainly before you had subdirectories. Each user account gets I think it's 100 bags (they're the floppies) and each of those bags can hold vast amounts of objects, but all at the top level, and all in the same namespace. If you want to impose any kind of structure on top of that, then you must do it by appropriately decorating the names (keys) that you use. It's as though your whole hard disk could only have a single folder and you had to keep everything organised by using tremendously long filenames.

Again, I said SimpleDB was the database, but it's not an SQL database. In fact it doesn't even have tables. It's more like a set of objects and a set of attributes, and any object can have (or not have) any of those attributes, and you can search on the attributes. So imaging that you could add some kind of metadata tags to S3 files and search on the tags, and that's SimpleDB.

I'm not criticising them, the constraints of replication, timeliness, availability etc. etc. very likely imposed all these limitations. And in an odd kind of way, the objects you get in S3 and SimpleDB remind me more of the sort of constructs you get in programming languages like Java or Javascript, so you can see that as building blocks they might be very powerful and useful.

But it's probably true to say that the software that would run well in this environment would have to be written or adapted specially for it. A lot has been written too, in the couple of years that EC2 and S3 have been available. But there's a whole class of more traditional applications that haven't, and which won't work in this environment, and they represent 99.9999% of all the software that's out there.

So now Amazon introduce EBS, and you can think of that as an infinite array of network-attached hard disks (but this time they are proper ones, with subdirectories and everything :) ). Previously, if I wanted to store my web application's data in say a PostgreSQL database, to get the benefit of SQL based access, I had to put that database on the EC2 instance's hard disk (instance storage) and had to make sure that the data in that database got pickled to S3 before the instance was shut down. Now I can just put the database on the EBS disk and forget about it.

Of course, for the very largest, most fault-tolerant and distributed of applications, EC2 + S3 + SimpleDB + SQS was probably architecturally the right way to go anyway; the sheer size of such applications might make exactly the same constraints necessary. The difference is in the area where I live: the web site that can fit comfortably on a single server, or even a single virtual server, with an SQL database on the same machine or on a different machine on the same network. That's to say, the space where the smallest to the medium sized database driven websites live.

These are well served at the moment by the numerous small hosting providers who'll give you a virtual server or two, or your own box. But if your web site does well, then the upgrade path can be difficult and expensive. And if your web site very suddenly does well then you likely won't be able to resource-up in time and it may fall over. And the pricing models are very coarse-grained in comparison to Amazon's.

For those web sites, Amazon EC2 wasn't an option because they would have had to rewrite their data layer and still end up with something that wasn't as flexible as SQL. But with EBS, those kinds of sites can be ported directly.

Compute cloud is the end for Microsoft on the server

Every so often I look at Amazon Web Services (AWS), and though the traffic on my web site doesn't justify even their smallest offering, it's still intriguing to think about how this offering will affect other peoples' businesses.

The most obvious is web hosting. There was a time, several years ago, when I thought that the hosting business was dead except for the largest players. Nobody else would be able to achieve the economies of scale necessary to compete. But there are a lot of hosting companies around, of all sizes. Absurdly many of them seem to offer the same combination: Apache, Linux or BSD, and MySQL for if you're really advanced :). It took me a while to find someone that could offer me both Postgresql and Java servlets.

I don't pretend to understand why it is that so many so similar hosting providers can coexist, though I suspect at least some of them are rebranding efforts, reselling services from the bigger boys. Even so, there seems to be money in it.

The latest thing to hit the world of the smaller hosting provider, at least as far as the somewhat glacial state of affairs at gedsguides is concerned, is virtual hosting. That's actually been around for some years, but about a year ago everyone started to offer it, as the virtualisation products matured (and, I suppose, as the open source ones became viable). Gedsguides.com will be moving from a simple hosting account to a real virtual server just as soon as I can be bothered to do it.

With a virtual server though, the competitive landscape changes. The model now is that you get administrator access to your own Linux server, and though it may well have the usual trio of Apache, PHP and MySQL installed on it as standard, you can install pretty much anything you want on it. Suddenly I don't have to go to California to find a hosting provider that supports the software I want to use. With virtual server products in other words, hosting providers are differentiated less by the software you can use for your web site and more by their pricing, reliability, knowledge and support.

And that's it, up to the limits of a single physical machine. But supposing, just supposing, gedsguides.com became wildly successful, on the order of a wowwiki or a thottbot. Would I order a second, a third, a fourth machine at my current hosting provider? Would they be interested in supporting a distributed database, a distributed application server, a distributed file system? What sort of support could they provide? And I would be sure to need to acquire a new set of programming skills for such a distributed, failover-prone world.

Much more likely, assuming the site was showing a profit, I'd finally bite the bullet and move everything to Amazon Web Services, where new servers and new storage are available at the drop of a hat; where the failure of a single box would be invisible to me, as it would be swapped out and another one prepped and swapped in in minutes.

So AWS stands to take the high end from the current crop of hosting providers. And because each AWS server is just another virtual server as far as the user is concerned, there's no worrying about whether it will provide the right software environment. You just package your website software up into an installable binary, and it gets distributed as necessary across machines.

Of course, there's no reason (other perhaps than using http as a data transfer mechanism) why only web sites and web applications should be using AWS. Sun has recently been talking about eating its own dog food by moving its in-house IT to its compute grid (Sun's version of AWS). I'm sure the idea will catch on, even if Sun fails there will be others who succeed.

For the purposes of a thought experiment, let's take this idea to its logical, if absurd conclusion. Let's say Amazon, Sun, Google and Microsoft all enter this market (Amazon and Sun are already in it, Google and Microsoft are rumoured to want to enter it). And then let's say that everybody — all businesses that is — rather than starting up their own IT and support department simply buy services from them. So, no server software sold to businesses any more, just billing for the computation done and storage used. Sure, some of this billing would cover the cost of server software, but in the form of capabilities available to your applications.

Now look at what software everyone would be using. For Amazon and Google it would be Linux (maybe BSD too?) and a software stack that runs on top of that, almost all of it open sourced. For Sun it would be Solaris, also open source and, if not blessed with developers to the same extent as the Linux world, at least largely compatible with it due to their shared *nix heritage, and able to incorporate any advances made in the Linux world fairly easily and quickly. Not so Microsoft. Microsoft would be the odd man out, using proprietary software all the way from Windows at the bottom to IIS and SQL Server in the middle to whatever in-house developed accounts, CRM, content-management etc. solutions they chose to supply at the top.

Microsoft suddenly looks awfully lonely there. What used to be a competitive advantage — user lock-in — suddenly becomes a liability: they are the ones locked in! They will have to do a lot of running to stay abreast of their competition. Nobody will be using their server software except them. They'll major on ease of use of course. Since everything is developed in-house, there is the potential for all the bits to fit together much more smoothly than with their competitors. Well, they'd better start coding all that now then, because that scenario is at least a couple of complete rewrites away. Vista, anybody?

The thing is, if you're providing a compute cloud environment to users, you need to provide either best of breed or cheapest (or a choice) at every level of the stack. For sure, Microsoft will be providing Windows at the bottom, but will they permit you to use alternatives to IIS and SQL Server in the middle? They could, but it would hurt their pride an awful lot. And what about areas where their offerings are complete also-rans? Who uses Microsoft Content Management Server anyway? Everyone uses Documentum. If you wanted to move your content management needs to the MS compute cloud, could you use Documentum or would they shove Content Management Server down your throat? It's easy to see that in the compute cloud scenario, Microsoft's less competitive offerings would be witheringly exposed.

Of course, such a massive and complete move away from in house IT to compute cloud IT may not ever happen. But something along those lines will, I think; the question is how far it will go, and how quickly. To the degree it does, Microsoft's ecosystem will shrink, its ability to compete on all fronts will be reduced, and its ability to be the first and the biggest, and to impose its standards, will diminish.

Oh, and if I was Documentum? Or SAP or Sage? I'd be talking to Amazon really nicely, right about now.