Amazon and Hardware As a Service 53
sioux_chance writes to recommend an article up on ReadWriteWeb comparing Amazon's S3 and EC2 services with Google AdSense. (They are not the first to coin the term "HaaS" for hardware as a service.) The analogy is that Google increased the granularity of (the article invents the term "fragmentized") the revenue side of the Web business, whereas Amazon's HaaS does the same for the cost side. A comment to the blog posting points out that NearlyFreeSpeech.net has been selling fine-grained hardware capacity for years, but Amazon does bring a greater scale to the business.
IBM introduced "Hardware as a service" around 1920 (Score:5, Informative)
For many decades, IBM only rented machines; they didn't sell them. Not until they lost an antitrust case did they sell hardware. Rented machines came with IBM service, which was excellent. Now that was "hardware as a service".
What Amazon is offering is called "time-sharing".
Remember Sun's "grid computing" [alibaba.com]? Big dud. The number of people who want to pay to run huge batch jobs but don't want to buy their own hardware just isn't that big.
There are two players in this space who are known to make money: Akamai and ResPower Render Farm. [respower.com]
Re:IBM introduced "Hardware as a service" around 1 (Score:5, Informative)
Akamai is a different beast altogether -- they're not a generic computing center, but a finely-tuned cache that gets your (mostly static) data as close to the user as possible. In fact, Amazon uses Akamai [akamai.com] (PDF press release) to host some of their content.
The difference between Sun's Grid Computing and EC2 is that EC2 is connected to the net. This doesn't mean you can't run huge batch jobs on EC2; however, there's a lot more you can put on there (read: hosting for the Web 2.0 company you've founded in your garage, mom's basement, ...). However, EC2 doesn't give you a load balancer (yet); getting the traffic from www.your-spiffy-domain.com to the EC2 instances is still your problem.
S3 is, IMHO, the more interesting of the technologies today. Buying storage capacity these days is cheap; maintaining it, however, is as expensive as ever (perhaps moreso as clients expect higher availability, geographic distribution to minimize risk, etc.). And, if I'm too small for Akamai yet need to host some static content over a fatter pipe than I have, I can even expose it to the rest of the world through the REST interface./p.
Re:Persistent storage? (Score:4, Informative)
Re:Persistent storage? (Score:4, Informative)
Basically, your server can go down at any time and any data on it will be unrecoverable. Precious data must be stored off the EC2 instance (e.g., on S3).
The implication is that you need to architect your application with this in mind. It has to be deployable and bootstrappable from a master image (typically the EC2 machine image). It either has to be stateless (generally preferred) or be able to recreate its state upon startup and periodically checkpoint its state while running. This is generally true whenever you're working on a large, distributed application and are properly treating your application servers as substitutable commodity machines. However, many people take shortcuts and depend on the reliability of the running hardware; EC2 is can be very unforgiving if you do this.
Re:Needs more transparency for real uses (Score:4, Informative)
Not much but there is a SLA [amazon.com]