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.
Just in case you were serious... :)
Slashdot, and the company that runs it Sourceforge Inc., aren't using Amazon Web Services for anything that I know of. Slashdot runs on real hardware, not VMs, and we're not planning on changing that anytime soon. I don't know anyone using AWS, which is part of why I'm looking for Slashdot reader feedback. My experience with it is limited to starting up some instances and playing around with installing Apache to see how it all works, and I did that on my own nickel. I chatted with someone at Amazon about AWS last year, but I didn't sign an NDA so I learned about today's news through their public mailing list.
If the prices are good I might go with them. I don't know if you guys know but I invented the roller blade. Someone stole the idea from me and get a patent on it before I could. I would have been rich beyond my wildest dreams. My new website will be for helping people get their ideas patented. If anyone has any information on who stole my roller blade concept, please let me know. Thanks and god bless.
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.
Amazon just has a very interesting service architecture. This is why you keep seeing articles all over the place about it.
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.
Doug Kaye from IT Conversations has been doing some pretty heavy stuff on EC2. He did a podcast with an Amazon guy on Technometria where they got in to a lot of detail have a listen.
more of the same on Twitter.
My major concern (last time i checked) was fail over & virtual ips. I think they fixed this with the new elastic ip. I will have to check again.
However, another issue i had was to send traffic between 2 EC2 nodes. They don't mention (maybe i missed) nor guaranty the bandwidth between the nodes in the same availability zone. This is crucial if you are trying to run a very fast performance tests between the 2 nodes and you need minimum delays. I am not sure if the bandwidth between the EC2 nodes is caped or no as well.
We looked at the EC2 solution when we started developing our hosted offering and didn't care for the new IP address when, and if, something went down. We went with a hosting company called LayeredTech. They offer public and private VPS and VPDC solutions. The really cool thing that has impressed me is they run 3Tera's AppLogic platform. It lets you visually (through a web ui) create "applications" based on "appliances". There is a standard portfolio of prebuilt applications (SugarCRM, etc.) and templates for LAMP, etc. So, we build our application by taking a firewall appliance, a CentOS appliance, a gateway, a MySql appliance, glue them together, customize them, and then create our own template. You can specify down to the appliance level, the amount of cpu, memory, disk, and bandwidth each are assigned which let's you scale up your capacity simply by tweaking values through the UI. We can now deploy our Rails/Java hosted offering for new customers in about 20 minutes on our grid. AppLogic has automatic failover so that if anything goes wrong, it reploys your application to a new node in your grid and restarts it. It's not as cheap as EC2, but much more powerful. It's definitely worth a look.
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
It seems like you answered your own question about persistent storage. S3 is persistent storage.
If you are running a database backed application on EC2 without a master/slave setup, and your master goes down, to me, that seems like a failure to plan for the worst on your end. It's really not an argument that even though you DO have persistent storage, your data is safe on that server. Your data is never safe. Hence, a backup/replication plan is ALWAYS needed. Services like EC2 force you to think about those plans and address them so that they are not a problem.
As for the slicehost option, we looked at them. We found that Amazon seemed to provide a much more robust service. Plus, Amazon has a LOT more resources to keep their service robust, as opposed to a startup with one datacenter.
'When the going gets weird, the weird turn pro.' -HST
"Software failure" in that case refers to a failure of Amazon's Xen software that runs your virtual machine.
Amazon doesn't know or care whether your software is "production quality code" or not. You pay $0.10/hr whether your code is debugged or not :)
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.
In fact, if you prepare for that, the cost differential is likely to grow, as if you have EC2 as a fallback you can afford to get closer to full load and bandwidth usage before you add more physical boxes...
EC2 is just too expensive to be worth it for normal use...