Why EC2 isn't yet a platform for "normal" web applications
June 20, 2007 - by jason
In a previous article, On Grids, the Ambitions of Amazon and Joyent, I made a few premises:
- The autoprovisioning and account management (and therefore the accessibility) is the improvement over a service like Sun’s Grid
- There’s no way that Amazon.com is literally coming off of S3 and EC2 (one datacenter and no CDN abilities? I don’t think so).
- That it’s a PR case study in flipping from real technical reasons (the world could use this) to bogus reasons (selling excess capacity, in which there is no such thing).
- The webmail.us case study is a perfect use case and people should recognize it as a moment in our industry when someone started using a “true grid service” to augment their own servers (and did so with a credit card).
- That evangelists beating the same drum again and again is a powerful thing
Let’s be clear, EC2 is fine when you’re doing batch, parallel things on data that’s sitting in S3. In line with the economics favoring compute being by data (Jim Gray’s Distributed Computing Economics), and is definitely an improvement over other publicly available batch systems. I can see why it would be attractive to those working on science grids, one just has to overcome the large data set in proximity to compute issue.
However, the promise of unlimited scalability (at least in the “scale up” direction) for normal web applications has no basis and is not technically possible beyond normal limits with EC2. A “normal” web application is that one that has to always be up and persistent.
And I get a bit irritated when I come across sentences like Jinesh’s at RailsConf: “infinity auto-scalable on-demand computing resource” (here)
I know that is has no basis because it lacks at least one critical thing: real application switches.
Yes, I’m now calling load balancers application switches because I think one has to distinguish software on a general purpose server from dedicated, high-end switching hardware. For example, OpenBSD is a great operating system and has OpenBGPD, and while I could slap it onto a couple of one unit servers to function as my routers, I wouldn’t do that above a certain level.
There is a difference in the horizontal scalability for how many rails processes you can hit in the backend (previous joyeur). The limit is typically <1000 req/second and not that many mongrels, so it’s pretty easy to know that any Rails application on EC2 is not pushing a lot of traffic.
While you might think I’m biased because we do have the Accelerator product line, let me make it clear that we have that product line because we’ve also had to scale some of the oldest Rails applications around, and that constantly feeds back into the design.
I’ve also said what I think is valid about EC2, but let’s be clear about the list of deficiencies for multi-tiered applications:
- No IP address persistence (they all function as DHCP clients and are assigned an IP). One has to use dynamic DNS services for a given domain.
- No block storage persistence. When the instance is gone, the data is gone. Yes I know you can send this back regularly to S3, but isn’t that actually a “hack”?
- No opportunity for hardware-based load balancing (which happens to be the key to scaling a process based framework like Rails and mentioned above).
- No vertical scaling (you get a 1.7Ghz CPU and 1 GB of RAM, that’s it). So like the block storage problem, this hits databases, we run about 32GB of ours in memory.
- Can’t run your own kernel or make kernel modifications so there’s no ability for kernel and OS optimizations, and no guarantee that they’ve been done.
- Images have to be uploaded and then moved around their network to find a launching point. This can take several minutes, if not more. Move 100 GBs around a busy gigabit network sometime and see.
(I’ll leave out ones like having to learn and program against proprietary API and commands like “ec2-run-instances ami-5da964c3 -k websvr-key”, that’s usually what’s called vendor lock-in).
In conclusion, EC2 is fine for batch on S3 data and for interacting with the Simple Queue Service (see the webmail.us example), but I wouldn’t put a multi-tiered web application on it.