Amazon.com's rent-a-grid

29.08.2006
Amazon.com is on a roll. In March, the company launched the Simple Storage Service (S3), a metered disk in the cloud that I praised here (http://www.infoworld.com/article/06/03/22/76555_13OPstrategic_1.html)and discussed in more detail (http://weblog.infoworld.com/udell/2006/03/22.html#a1411)on my blog. So in July, when the Simple Queuing Service (SQS) emerged from beta (http://www.infoworld.com/article/06/07/19/30OPstrategic_1.html), developers were so busy with S3 that they hardly noticed.

Nobody was satisfied with just a disk in the cloud. Everybody wanted services in the cloud, too. Openfount's Queued Serve (http://www.infoworld.com/4298)r skinned the cat one way, by parking AJAX applications on S3 and implementing a simple protocol for communicating with services elsewhere. The ever-inventive Les Orchard (http://www.infoworld.com/4447)skinned the cat another way, creating an AJAX/S3 Wiki (http://decafbad.com/blog/2006/04/21/an-s3-ajax-wiki)that has both code and data residing on S3.

Could true services in the cloud be far behind? Sure enough, they weren't.

This morning I fired up my first instance of a Xen-based virtual Linux box on Amazon's just-announced grid (http://www.infoworld.com/4448), the Elastic Compute Cloud (EC2). I logged in as root and copied over a little Python-based search service that I run on my own server at home, along with the several XML data files that it searches. I fired up Python, pointed a browser at the domain name that EC2 had assigned to my virtual server, and ... it just worked. As I wrote on my blog, where I also posted a screencast showing my service running on EC2 (infoworld.com/4446): Wow! (http://www.infoworld.com/4446)

Although EC2 operates under the rubric of Amazon Web Services, by the way, I suspect that the only Web services many developers will use in connection with Amazon's grid are those encapsulated by the Java-based API toolkit used to provision, launch, and terminate virtual instances of Linux. My search application on EC2, for example, used Python's built-in HTTP server. Alternatively, it could have used the Apache server that's built into all standard EC2 images. Or I could have built a custom Amazon Machine Image including some nonstandard server.

As the blogosphere quickly noted, the EC2 rate of a dime per instance-hour works out to $72 per month for the equivalent of a 1.7Ghz Xeon CPU with 1.75GB of RAM and 160GB of local disk. And that doesn't include bandwidth, billed separately at the S3 rate of 20 cents per gigabyte. So for now, if you want to park one box on the Internet and leave it running indefinitely, better deals can be had from dedicated hosting providers. As the service's name suggests, though, if you need an elastic capability that can nimbly grow or shrink, EC2 is the only game in town.