Slashdot Mirror
Amazon EC2 Now More Ready for Application Hosting
For months now, I've been geeked about Amazon's EC2 as a web hosting service. But until today, in my opinion, it wasn't ready for prime time. Now it is, for two reasons. One, you can get static IPs, so if an outward-facing VM goes down you can quickly start another one and point your site's traffic to it without waiting for DNS propagation. And two, you can now separate your VMs into "physically distinct, independent infrastructure" zones, so you can plan to keep your site up if a tornado takes out one NOC. If I were developing a new website I'd host it there; buying or leasing real hardware for a startup seems silly. If you have questions, or especially if you know something about other companies' virtual hosting options, post comments -- let's compare notes.
Nice, don't suppose there's any chance of IPv6 support - give each instance, running or not, a unique address.
Is this a Slashvertisement?
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
So here's a little about what EC2 actually is, for those of you who don't know. You don't have to reply here, start your own comments ;)
The Elastic Compute Cloud was originally designed as a way to host applications that needed lots of CPUs, and the option to expand by adding more CPUs. It's a hosting service that lets you start up virtual machines to run any software you want: they have a wide variety of pre-packaged open-source operating systems you can pick to start up your VMs with.
Starting up a VM takes just a minute or two, and it's point-and-click thanks to the Firefox extension. Each VM comes in one of three sizes: small (webhead), large (database), and extra large (bigass database). They cost respectively $72, $288, and $576 a month (billed by the hour), plus bandwidth ($0.18/GB out, somewhat cheaper for data going in and there's a price break at 10 TB).
One of the concerns everyone raises with hosting on virtual machines is that if a VM instance goes down, you lose everything on it. It comes with hard drive storage (160 GB on the small size), but if something goes wrong, that data's gone.
I think the rejoinder here is that, on real hardware, if something goes wrong, your data's gone. You never set up an enterprise-level website on the assumption that any particular hardware has to survive. Single points of failure are always a mistake, and backups are always a necessity. When any machine explodes - real or virtual - the question is how fast your system recovers to "working well enough" (seconds, hopefully) and then how long it takes you to get it "back to normal" behind the scenes (hours, hopefully). Those answers shouldn't depend on whether there's a physical drive to yank out of a dead physical machine that may or may not retain valid data.
Which brings up what I think is one of the selling points of EC2: free fast bandwidth to S3, Amazon's near-infinite-size, redundantly-replicated data storage platform. That's a nice backup option to have available. That's part of why, if I were starting a new web service, I wouldn't host it on real hardware. I'd like not having to worry about backups, tapes, offsite copies... bleah, let someone else worry about it.
Slashdot hasn't run many stories on EC2 (none that I know of) because until now it's been a niche service. Without a way to guarantee that you can have a static IP, there had been a single point of failure: if your outward-facing VMs all went down, your only recourse was to start up more VMs on new, dynamically-assigned IPs, point your DNS to them, and wait hours for your users' DNS caches to expire. That meant that while it may have been a good service for sites that needed to do massive private computation, it was an unacceptable hosting service.
Now with static IPs, you basically set up your service to have several VMs which provide the outward-facing service (maybe running a webserver, or a reverse proxy for your internal webservers), and you point your public, static IPs at those. If one or more of them goes down, you start up new copies of those VMs and repoint the IPs to them. No DNS changes required.
I know there are other companies offering web hosting through virtual servers. Please share information about them, the more we all know the better.
I do think that another host using an automated provisioning system that is compatable with EC2 would be a good thing- If I wasn't absolutely swamped by my dayjob, I'd try to implement such a thing.
I use Mosso - they are inexpensive and are hosted and owned by Rackspace. Therefore the service is fantastic!
The more I learn about Amazon's AWS offerings... the more confused I get. I've read a TON of material, reviewed the APIs, looked at sites built on this platform and have read many blog entries. I feel like I "know" a lot, but understand very little. Someone help?
1. What is a perfect "typical" application for AWS? (And don't answer, "one that needs to scale...". I'm looking for a realworld example.)
2. Anyone here on Slashdot using these services? Nervous about single point of failure? (And I don't mean just technical, but also financial, legal, security, business continuity, etc.)
3. EC2 / S3: is there any value in using just one? I've noticed there are additional services now, too
4. In the days of SOx / PCI / CISP compliance, is it even possible to set up a financial app on AWS?
5. Also, finally, maybe a question to Amazon... why? Someone did the financials recently and it was a fascinating study. The short of it is that at max capacity, the net income from all of AWS for Amazon is so tiny, you have to wonder why they even bothered... [need citation]
A classic case of wanting to like the technology, but not really sure how to use it. Thanks.
Cheap, affordable, reliable VPS solutions: www.slicehost.com
I have been with them for a few months, and their interface's ease of use, and the level of support they provide are just what I was looking for.
There's still one glaring problem. There is no persistent storage (other than shuttling data to S3). That means that if your website is database-backed, you need to figure out what to do should your instance crash. Hourly backups? Mounting S3 as a slow FUSE filesystem that you can put your database on? It's all ugly.
And it's still not a great value. It seems cheap. $72/mo for a 1.7GB RAM server. Well, look at Slicehost and you can get a 2GB RAM Xen instance (same virtualization software as EC2) for $140 WITH persistent storage and 800GB of bandwidth. That doesn't sound like a great deal UNTIL you calculate what EC2 bandwidth costs. 800GB would cost you $144 at $0.18 per GB bringing the total cost to $216 ($76 more than Slicehost). That 18 cents doesn't sound like much, but it adds up. The same situation happens with Joyent. For $250 you get a 2GB RAM server from them (running under Solaris' Zones) with 10TB of bandwidth. That would cost you $1,872 with EC2. Even if you assume that you'll only use 10% of what Joyent is giving you, EC2 still comes in at a cost of $252 - and without persistent storage!
EC2 really got the ball rolling, but it just isn't such a leader. Other operations have critical features (persistent storage) that EC2 is lacking along with pricing that just isn't more expensive. I want to like EC2, but their competitors are simply better.
Because having your own hardware you can't scale up to 50 server instances for half an hour and then scale back down to 1 when traffic decreases, just as one example.
Your comment makes it apparent that you really don't understand how hosting a website works.
My company uses EC2 (plus a few other amazon services, which I find to be spectacular) for hosting our application. If we wanted to move to another server or company or datacenter, it's just a matter of setting up the new server and repointing the DNS. Also what is nonstandard about their servers? You basically set them up however you want. You want to run linux? cool. FreeBSD? awesome. Basically you can run any *NIX clone you please. Fortunately lots of people provide excellent templates, so rolling your own is not really necessary.
'When the going gets weird, the weird turn pro.' -HST
My company uses EC2 + S3 + SQS + Rightscale (http://rightscale.com) to manage our infrastructure.
First off, Amazon has an excellent product. It is essentially Hardware As A Service, and the tools they provide abstract it as such.
The most common argument against using EC2 for hosting is that if your server goes down, you will lose any data created since the last time you saved a snapshot. While this is true, it forces you to bring a backup + recovery plan to the front of the table. Provided you have a backup + recovery plan in place, you no longer have to worry about fixing a server ever again. If something goes wrong with one of our application servers, I would simply fire up a new instance, link it in with DNS, and terminate the old server. With rightscale, this is all pushbutton.
Consider that scenario with running your own colo server. You could potentially spend hours diagnosing + fixing an issue with a server before you could bring it back up. Ok fine, the way to mitigate that is to have a hot backup running. But now we're talking about a ton of cash to support 2 servers on a month-to-month basis. We have found that amazon's costs to run EC2 instances are very competitive for the specs.
Note: I'm not a shill for either rightscale or amazon, I just find that these 2 companies are the forefront of where hosting is going, and their products are awesome. It's all about virtualization!
'When the going gets weird, the weird turn pro.' -HST
Yes and no. Since it's not persistent, you have to set up some kind of backup/replication from day one -- S3 being the common choice here. My startup uses EC2+S3, and just getting a Linux image serving a webpage is completely standard (yay), but setting up all the replication and monitoring and whatnot that a real server actually needs is kind of a pain. You end up with a lot of EC2/S3-specific fun, at least on the administration side.
As just one example, we don't do full backups, but rather have our images install everything on startup (which is rare, and fast anyway), and simply hot-sync our RDBMS while it's running. Simple and fast! Then we wanted to install a blog, so we installed Wordpress. Later we discovered that Wordpress uses our database for posts (so it replicated them just fine), but *also* writes to the filesystem for file uploads. So we needed to install the "Wordpress S3" extension, so file uploads got backed-up to S3 too.
Were we stupid to assume that web apps that use an RDBMS use only the RDBMS? Or to use Wordpress? Or to hotsync only and not do full backups of our image? Maybe all of the above. But it seems about equal to me to say "EC2 is standard Xen" as "Perl is cross-platform": it's certainly possible to use it that way. You can also tie yourself down to a platform really easily, if you don't make portability a priority. We don't think EC2/S3 is going away soon, so we took the easy way.
True, we could just move our image somewhere else. It would probably run, mostly. Things like "back up EC2 to S3" we'd need to spend time changing, because I don't think anybody else in the world uses the same interfaces there. That, I assume, is what the GP was speaking of.
That depends a lot on the scale of your operation and the scale of your hosting service. The value of an SLA is that you can sue to recover damages in case of non-compliance. But it may not be possible to recover real damages in court: Your provider may not have pockets that deep, you may not have pockets as deep as your lawyers' thirst for money, and the law may not allow for full recovery in your circumstance.
EC2 is up and stays up. Reliabilty counts for a lot more than legal recourse, in my book. SLAs don't create reliability, they *help* (hopefully) to create legal recourse, which is a very poor substitute.
-I like my women like I like my tea: green-