advertise
« Paper: Memory Barriers: a Hardware View for Software Hackers | Main | GOV.UK - Not Your Father's Stack »
Wednesday
Jun052013

A Simple 6 Step Transition Guide for Moving Away from X to AWS 

If you just want to visit Rome and not go full on Cloud Native like Netflix, then Soundslice's Adrian Holovaty in Why I left Heroku, and notes on my new AWS setup provides a simple guide for helping make your first trip a good one.

First, let's dispose of why Soundslice left Heroku. The essence is because of various issues "Heroku lost my trust." YMMV, but once a fact, what do you do?

After a consultation with Scott VanDenPlas, former director of dev ops for the Obama reelection tech team, they came up a simple transition guide that I think is quite good and generally useful (full details in the original post): 

  1. Bake an AMI. Install all the stuff you need on an AMI and use that as your deployment unit. This works well for Netflix and for users who value a certain sort of simplicity more than flexibility. There were a lot of comments saying how it's better to use Chef/Puppet and configure instances on the fly, but there's a confidence that only a baked image provides.
  2. Set up auto-scaling rules. To treat Amazon as something other than a fancy hosting service you have to hook into the auto-scaling system. Amazon monitors your systems and starts/stops  nodes if certain conditions are met. Of course your application has to be structured such that adding/removing nodes in response to scale makes sense.
  3. Change app not to use shared cache. Where do you put session state? They moved to cookie based sessions, which is often recommended against because large cookies increase message sizes and reduce performance. Many people recommended using ElastiCache instead (or something similar). HTML5 local storage is another interesting option.
  4. Migrate to MySQL. Originally on PostgreSQL they had to migrate to to MySQL so they could use RDS to scale. This is heresy to many, but they like RDS as it makes scaling and high availability quite simple. Some recommend hosted services versions of PostgreSQL or really wanted Amazon to offer a hosted version of PostgreSQL. If you want more information on RDS Airbnb has a good article on how they run MySQL in the cloud.
  5. Add nice API with Fabric. You can't talk about the cloud without talking automation. This is often a two sided debate between Chef and Puppet, by they found Fabric matched their needs quite well. While not as simple a deployment processes as Heroku, the result works well enough.
  6. Software updates. A new AMI is created with the new software, tested, frozen, and then associated with the load balancer. Existing instances are terminated and the scaling rules bring up new instances using the new AMI. While there's some downtime it's a pretty robust system.

The result: "Put all this together, and you have a very powerful setup that I would argue is just as easy to use as Heroku (once it's set up!), with the full power of root access on your boxes, the ability to install whatever you want, set your scaling rules, etc. Try it!"

Is AWS cheaper than Heroku? Surprisingly, the price is basically the same because of the multi-AZ setup.

If you are trying to work out these problems for yourself you might find the comment section of the post useful and there's also a good discussions on Hacker News.

It would be excellent if the next step could be taken on the article and all the details could be provided. That would be very useful, if someone is up to the challenge.

Related Articles 

Reader Comments (2)

The ElastiCache link points to the same URL as the previous link to Django session cookie information. Guess it should point to http://aws.amazon.com/elasticache/

June 5, 2013 | Unregistered CommenterWill Thames

I'd like to see the complementary guide on moving away from AWS to some other platform 'Y' - somehow I have an inkling it will consist of more than just 6 simple steps.

Some of things you'll need to do only to move your server instances:
* Translate AWS instance types to their 'Y' equivalents - you won't find an exact match for the instance you had on AWS
* Decompose your AMI, identify the required components / configuration for your app and pray that 'Y' has some sort of server image customization
* Learn to manage DNS on the fly if 'Y' doesn't have an Elastic IP-like mechanism
* Persistent storage isn't available at all 'Y's - learn to live without it
* and the list goes on..

Many of us love AWS's strong feature set, rightfully so, but users must keep in mind that the more features they rely on, the more difficult it will be to migrate away from AWS some day in the future.

July 11, 2013 | Unregistered CommenterItamar Haber

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>