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.

It's too proprietary

[Animats]

If you're using Amazon for hosting, you can't switch hosting services; their system is too nonstandard. Do you want to be in a position where they can raise prices or cut off your air supply?

I have a question:

[Megaweapon]

Is this a Slashvertisement?

Re:It's too proprietary

[nacturation]

If you're using Amazon for hosting, you can't switch hosting services; their system is too nonstandard. Do you want to be in a position where they can raise prices or cut off your air supply?

EC2 allows you to setup your own servers on their infrastructure. Ultimately, this is as standard as getting a virtual or dedicated server at any one of thousands of other hosting providers. Switching is as easy as replicating the environment you've created for yourself (which is likely a standard LAMP stack anyways) and then doing a DNS change.
 

Re:IPv6

[tolan-b]

I suspect only tunneled over IPv4.

What I'm personally waiting for from EC2 is European datacentres, as I have an application that's latency sensitive. :(

Re:It's too proprietary

[Anonymous Coward]

Forgive me for being uninformed if that is the case, but aren't these simple virtual machines running linux ? It should be no harder to move to a different hosting place than it is to move any hosted linux. I have done "brute force" migrations by literally copying every file from a hosted system (RedHat) to an in-house server, and jumping through hoops with editing fstab and grub.conf and etc until it booted and ran, and then fixing driver issues. I have also done the same from a hosted system into a VMWare image. Of course you could do it "right", if a deadline wasn't breathing down your neck and your business had properly documented the initial setup, then you would take the opportunity to put all the latest versions on the new place, and migrate a module at a time doing what code and config updates were needed.

But seriously, what is the proprietary lock-in in a Linux virtual machine ?

Re:IPv6

[tolan-b]

Yeah I need low latency to the server running the app. Hopefully the fact that they've opened a Euro datacentre for S3 is an indication they might do the same for EC2 though.

Re:No

[Anonymous Coward]

Why would anyone choose to leave their data on someone elses server when the price of owning your own hardware has become so low?

The hardware is the least of my company's worries. The fact that ISPs like comcast and at&t are actively threatening "content providers" (that is: everyone with a server) over "using their bandwidth" (that the ISPs are being paid for by their customers, in addition to our ISP paying them (directly or indirectly) for transit, and for which we pay our ISP) make it more and more difficult to justify hosting any sort of serious application in a closet hanging off of a leased T1 line. Hosting with Amazon (or any other large consolidated data center, virtualized or not) at least brings collective bargaining power to the table when these large ISPs finally decide to break out the crowbars and say "ok, give us a million bucks or nobody will ever see your site again".

IPV6? How about an SLA!

[Jeremiah Cornelius]

"More ready" is wonderfully relative.

"Less unready" is just as accurate, and perhaps more precise.

Without an SLA, EC2 or SimpleDB, or "Head in The Cloud" is an experimental platform.

Re:No

[jamie]

For me, it'd be more about hassle than price. If I'm developing a new service, it starts with just one server and I don't want the hassle of figuring out where the best host is. I want the flexibility to cancel the whole thing with no contract (billed by the hour) and just walk away if it turns out not to be a good idea. I also want the flexibility to scale quickly from 1 machine to 10 and 100 without having to worry about picking out the hardware, billing, power, cooling, network architecture, backup, fixing dead machines, and of course whether the host has room for me to scale.

When the VCs want to know what issues are involved with my service scaling to 100x its current size, they would much rather hear that the single hardware issue is "dollars," rather than that whole long list of unknowns. Dollars are easy.

And from what I can tell, EC2/S3 would scale from one server up to Slashdot size and beyond without much problem. Probably not to Wikipedia size, but I wouldn't be surprised if it could get close. And as someone else noted, they don't have data centers anywhere but the East Coast... but I wouldn't be surprised if they're working on that too (I don't have any inside info, I didn't sign an NDA).

Re:No persistent storage; not great value

[dubl-u]

Well, look at Slicehost and you can get [...] WITH persistent storage

The Amazon machines offer storage that persists for the life of the virtual instance. That's until you kill the instance or until the hardware fails. (It does persist through reboots and OS crashes.) And unless Slicehost is running some crazy magic beyond the RAID-10 setup they mention, a hardware failure could still wipe out your data, and will certainly cause downtime during which you will have an opportunity to wonder when and whether your data is coming back.

If you run some stats, it could well be that the Slicehost "persistent" storage does indeed persist longer. That'd be my guess. But it's possible that the Amazon "non-persistent" storage is actually more stable. That depends on the quality of hardware and maintenance at both companies, factors that you cannot know. Meaning that if reliability is really important to you, you must plan for either kind of storage eventually failing. And if reliability isn't that important to you, then you're planning to depend on your backups anyhow, in which case Amazon doesn't seem so bad either.

I think the main difference between Amazon and the more typical providers regarding persistence is that Amazon's experience has taught them to assume that everything fails, and so you should engineer for that. EC2 and S3 are built around that, and are very frank about what they provide. It seemed weird at first, but now I like it better.

Re:No

[vidarh]

Yes you can. Nothing stops you using EC2 for "overflow". EC2 for instances you use most of the time isn't cost effective compared to a number of other hosting providers, which is no surprise since you pay for Amazon to keep a huge amount of spare capacity to handle surges.

Re:IPV6? How about an SLA!

[aminorex]

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.