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):
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
