Amazon EC2 Experiences
I’ve been on a blogging tear lately, finally getting around to writing posts on topics that I’ve been meaning to write about for a while now. I have a series of posts that I’m working on in the category of virtualization, so I thought it might be useful to write about my experience with Amazon EC2.
I first became aware of Amazon EC2 when I was investigating rPath Linux and their rBuilder suite of appliance packaging tools. I first used EC2 at Startup Weekend Boulder because it was an easy way to instantly provision a server with pretty good horsepower (1.8 GHz, 1.8 GB RAM) while keeping costs low ($0.10 per instance hour per month), and didn’t require any contracts or setup fees. I also thought it would be great for scaling should Startup Weekend Boulder produce the SaaS hit of the century and all of a sudden get overwhelmed with traffic - Just start up a few more instances to handle the load and we’d be set.
EC2: A Great Service, Except For That Ephemeral Storage!
While I was setting up the instance at Startup Weekend, I quickly realized the biggest problem with EC2: The ephemeral storage. The ephemeral storage is the 250GB slice of storage that is mounted at /mnt of every EC2 server instance and is the only local storage available to an instance as the Amazon Machine Images (AMI) images have root filesystems that are limited to around 10GB. The problem with the ephemeral storage is that should the server instance get terminated for any reason (such as the recent accidental termination due to their management software upgrade), you will lose everything stored on the ephemeral store, and this usually includes your application and any databases it may be accessing, not to mention any server customization and configuration that you may have implemented.
I spent a lot of time at Startup Weekend figuring out how to save our customized AMI image and dump our database to Amazon S3, I figured worst case if we have the image and data saved we can get things going again in a reasonable amount of time (although “reasonable” probably doesn’t hold for very popular production sites).
Accidental Instance Termination
Speaking of this recent accidental termination of EC2 instances, one of my instances that I was using to temporarily host my (wah) cool “RaceBib” Facebook app (I didn’t want to be left out of the “Facebook is the new Internet” club) was shut down. This termination was my motivation to finally move this application over to something more permanent and less costly (see my previous virtualized hosting article). I knew eventually an unexpected instance termination would happen and took the basic precautions of copying the database to S3, so I didn’t lose any data, I just had downtime which while unfortunate wasn’t a huge big deal with only a handful of Facebook users.
Anyone who complains to Amazon about this accidental termination should have expected it in the first place. Amazon states clearly that instances are subject to termination at any time, and they recommend that users plan accordingly and implement redundancy and backup measures. If I recall correctly I think they even say to expect an average of 90 day termination or maintenance events. Anyhow, setting up redundant MySQL servers or brain damage of that nature seems to reduce the cost effectiveness of the service (having to setup multiple instances), and reduces the ease of implementation of the Amazon service. From what I’ve read I believe Amazon is aware of this weakness in the EC2 service and they’re actively working to create a more permanent “ephemeral store.”
Amazon EC2: What other VPS Providers Should Emulate
One of the main things that caused EC2 to quickly get my attention was the ability to bring your own virtual image (AMI) to Amazon and have them run it on EC2. This was one of the build options that rPath’s rBuilder provided and what sparked my initial investigation into the EC2 service. Currently most VPS providers will offer you a wide array of stock VPS operating system images that they’ll let you run. Pick one, load it up on your VPS, customize it to your application’s needs, but if you ever decide to leave one VPS service for another, you have to leave your image behind with all your configuration.
Additionally if you simply want to replicate your application’s configuration to additional servers on the same service, you have to start with the stock OS image and reconfigure everything manually. But then maybe some of you out there actually get a kick out of repetitive server configuration. Regardless, Amazon EC2 is perfect for all of these. Once they get their ephemeral storage issues resolved, it will be in my opinion, the perfect hosting option (especially with it’s integration into the S3 service) and I will continue to recommend it as a hosting option to others.
All the servers I’ve been provisioning lately are packaged in a virtualized form. If a VPS service can’t afford the flexibility to host my pre-built image, or allow me to download a server image I’ve customized either to move it somewhere else, scale it, or keep it for backup purposes, then they’re missing the some of the greatest benefits of virtualization. If you’ve come across this post, and you’re looking for someone to host pre-built virtualized images, I offer VMware image hosting through my company, Obility, LLC. Contact me and I can work with you to help you realize and take advantage of everything virtualization has to offer.