Amazon is Utility Computing
The cover story for last week's BusinessWeek magazine described how Amazon is launching a set of new technology services that enable other businesses to use Amazon's computing infrastructure. The tone of the article was a bit skeptical, but we use the services here at rPath, and we like what we see. We are particularly excited about the Elastic Compute Cloud (EC2) service because it is the first large scale utility computing offering to come to market based upon Xen virtualization technology.
Our first experience with Amazon's computing services was when we migrated all of our virtual appliance images from our NAS at our datacenter site to Amazon's Simple Storage Service (S3). We transferred 1.7 terabytes of images (it has since grown to over 2 terabytes), redirected all of our web services that control access to the images, and our rBuilder Online users began receiving their disk images from Amazon instead of from rPath. Our first monthly bill from Amazon was about $300, which includes the cost of the bandwidth to serve the images. We eliminated the need to purchase a very expensive NAS disk array (about $80K), and freed up our existing NAS storage for other uses. Amazon is amazing.
EC2 promises to be even more interesting than S3 because it has historically been very difficult to offer CPU capacity in a utility model due to the inflexibility of the general purpose operating system. Unlike file storage, where it is easy to decouple the application from the data due to well codified access protocols and file system standards, CPU services have been hamstrung by the lack of standards for application system services at the level of the operating system. For example, in order to use the Sun Grid Compute Utility, your application must be ported to run natively on Solaris 10 and be scripted to work with N1 Grid Engine Software. And the service cost $1/CPU-hr. With EC2 from Amazon, your application can run any Xen enabled, x86 guest OS at any version level. And the service costs just $.10/CPU-hr. No operating system constraints and one-tenth the cost. Another bummer for the folks at Sun. . . .
1 Comments:
How is making my application "Xen" enabled be less painful than making it "Solaris 10" enabled?
At least with Solaris I know I have a rock solid company and OS whereas with Xen I dont want to spend my effort and time making it Xenidified.
Why should not I use Solaris 10 containers instead of Xen?
Post a Comment
<< Home