1–10 of 43 posts
Considering I only have experience with setting up dedicated servers, I was wondering if someone with experience setting both up could comment on whether the difficulties of using AWS outweigh the benefits.
AWS is daunting at first -- but then so is Debian. Once you figure out the keys thing and your base image it's fairly easy (also see ElasticFox, S3Browser). You might as well learn it, even if you stick with dedicated hosting for other reasons.
Things not to sneeze at: * elastic: start up a dozen servers in a few minutes * free access to s3 storage * crazy awesome pay-as-you-go bandwidth (250mbps) * expensive for the CPU/RAM you get * virtual disks can be slow on random seeks * sorry, no cPanel (though see RightScale) * poor locality of servers
That said, if you have no problems setting up dedicated servers, than you won't have any problems with EC2. Use rightscale's free interface to manage instances, the rest is what you already know.
"Dedicated server" sounds like you're asking about one or maybe a few machines. If that's the case, you're better off with dedicated hardware from a vendor you're familiar with.
AWS is an entirely different way to build an application infrastructure. You don't keep state on any one instance because you plan for redundancy. Rather than have 1 or 2 front-end machines, you're running 1 or 2 load balancers in front of N front-end machines. If something goes awry with a front-end instance, you take it out of the loop and start another to add to the loop without downtime. It's the kind of power that up to now only companies with large IT budgets have enjoyed.
I've done AWS, dedicated, and colo. Each one has their own tradeoffs. AWS is daunting at first -- but then so is Debian. Once you figure out the keys thing and your base image it's fairly easy (also see ElasticFox, S3Browser). You might as well learn it, even if you stick with dedicated hosting for other reasons. Things not to sneeze at: * elastic: start up a dozen servers in a few minutes * free access to s3 storage…
Snapshots are also useful for testing new ideas, out of band processing (spin up an instance that processed data from a snapshot instead of hitting the main DB).
Amazon consistently improves their offerings - so if it doesn't fit right now it might next month.
In the end I chose to run Xen on top of dedicated hardware, which has essentially bought us the best of both worlds: simple scaling and low costs. Granted, it would probably take me a couple hours to start up a dozen more VMs (I'd need to requisition new hardware) as opposed to a few minutes and S3 is still cheap for mass storage, but neither of these points had any relevance to our situation.
As mentioned by others, it all comes down to what your project needs.
AWS isn't that hard to configure. ElasticFox puts a nice GUI to it and while it will take a short while to get used to the AWS way of doing things, you're better off.
With AWS, you have a nice spray files everywhere storage in S3, EC2 provides lots of RAM and CPU muscle, EBS provides RAID-level reliable persistent storage for EC2 that can be backed up to multiple data centers with a single API call, CloudFront even gives you the chance to have static files served from 12 different locations in the world making your latency very small. If you need more servers, no problem just wait a few minutes for them to boot. If you need more bandwith, it's automatic. If you need more storage, S3 is infinite and EBS can always give you more (you can even stripe the drives so that you could have terrabyte after terrabyte of storage as a single drive).
Dedicated servers have little upside. You're relying on physical hardware in a very acute fashion. While AWS runs on real hardware, there's an abstraction level which helps a lot. Let's say you're small and want a single box. That box fails, you call your host and get a new one in a couple hours, you restore from backups for another couple hours maybe and you're back online. Of course, many often don't test their disaster recovery scenarios that well and are often met with little problems. With AWS, you simply boot another machine off that image and you're good. Worst case, your EBS gets trashed and you say, "hey, S3, rebuild that EBS drive". Easy by comparison.
Real boxes are a pain. You have to deal with RAID, backups, how fast your company can provision new boxes, bleh! AWS (or even Slicehost and Linode) isolate you from a lot of that mess. There's a reason virtualization is the hot new topic.
AWS isn't that hard to use. It's definitely different, but it makes so many other things so much less painful. If you want some of the benefits of AWS with a "simple as dedicated" feel, try Slicehost. You can get instances with as much as 15.5GB of RAM and they just give you the instance with your choice of Linux on it. From there, you can install Apache, MySQL, other. And you get benefits like cheap and easy backups - they just store an image of the machine. Then, if you need more capacity, you can boot one of those images as a new instance, now you have another server. If one of their servers fails, they can easily migrate your instance to another box. RAID10 is already set up. Easy.
If you're worried about AWS' management being a little different, don't worry too much. It's not that bad once you start using it - just a tad hard to imagine without trying it. If you're still worried, Slicehost will give you instances that will work like you're used to dedicated hosting working, but with many of the advantages of AWS.
Hosting on EC2 is stupid, it's way more expensive than linode or slicehost. I accidentally left one of their extra large slices running for a month, and it cost almost $600. You can get real metal for those prices. That said, if you have no problems setting up dedicated servers, than you won't have any problems with EC2. Use rightscale's free interface to manage instances, the rest is what you already know.
I'm currently a customer of Amazon, Softlayer, Serverbeach and few cheap VPS elsewhere. I find that each has their advantages.
Need cheap bandwidth - nothing beats Serverbeach (youtube ran their CDN on serverbeach boxes until they went to google). If you need a small number of dedicated boxes, Softlayers support is worth the extra money (I usually get softlayer boxes for about $50+serverbeach costs -- and softlayer includes private net in that cost).
EC2 is great if you are going to be scaling up/down or have interesting synergies with S3. (filesystem snapshotting, free bandwidth, ...)
Small VPSes are great when you are building to prove an idea - a couple bucks a month while you have no traffic.
I also find using EC2 for one time tasks preferable. Spin up 10 instances to do a massive amount of computation or to do load testing.
Configuration should be the least of the reasons to make the decision. The many other factors are much more important than configuration.
That said, $75 a month or so can get you a small dedicated server in some places that includes a fixed amount of bandwidth, or more predictably priced hosting at slicehost or somewhere similar.
If your application doesn't need to scale, then AWS probably doesn't make sense. If you do, then it does.
As an AWS noob myself, the only confusion I had were with the very initial setup (in using the keys provided to authenticate and whatnot) -- and in the initial server configuration. The major differences you'll need to be aware of are as follows:
- The AMI image (basically just a virtual image) is static. You can't save files to this and expect them to exist after a reboot. That took a second to get my head around, after configuring apache and rebooting, wondering where it all went.
- Set up your base OS, then save the AMI. It was confusing to me figuring out exactly what needed to go where, and remapping my server between 'fixed' and 'dynamic' content and making sure that they were in appropriate places. This includes your web server configurations, disk mounts, /var/ directories, etc. User generated data, SQL data, and (probably) your website data will be stored on either an elastic block or to an S3 bucket. The important thing to note here is that you configure your OS to look how you want it to be every time you wipe it clean. Perhaps you put your web application on it, perhaps you don't. I could see using AMIs as a sort of version control for your apps, but I don't know your use case.
- The elastic IPs threw me. Don't release them on production instances. lol. Effectively, it maps an IP address to your machine virtually, which means it can be moved around. Your DNS points at the EIP which can be a single apache instance, or later, a load balancer -- all configurable within a couple minutes.
Other than that, it took me less than $10 worth of AWS resources to configure a couple servers, deploy my app and get it configured to how it would be in the real world if I were to migrate, so you should definitely check it out. There's no major upfront commitment like there is with dedicated hosting, so there's really no excuse not to familiarize yourself with it.
Also, you definitely want the elasticfox plugin if you're going to do anything with it. I'd point you at the following resources, which got me up and running within a few hours.
- ElasticFox Plugin - http://developer.amazonwebservices.com/connect/entry.jspa?ex...
- ElasticFox Owner's Manual (PDF) - http://ec2-downloads.s3.amazonaws.com/elasticfox-owners-manu...
- Configuring MySQL to use ElasticBlock storage - http://developer.amazonwebservices.com/connect/entry.jspa?ex...