Why I left Heroku, and notes on my new AWS setup

Re:Why I left Heroku, and notes on my new AWS setup by rschmitty on Monday May 20, 2013 @01:44PM (#5738886)

Depends on how fast you want new instances to be online. Sometimes you want to respond to demand very fast, it can take a few minutes for an instance to register with ELB, if you have to download/build/configure packages prior you are just adding minutes on time. The faster you can spin up instances the higher you can run your servers as you need to tell amazon at what threshold should I spawn more instances

There are 3 general levels you can take with AMIs:

1) Vanilla instance AMI, have puppet/chef install everything for you, then fetch your app code and configure that

2) Use another tool to have your instance built with puppet/chef and then capture that into an AMI. Once it spins up it just needs to get your app code. Idea here is your services arent likely to need updated as fast as your app code.

3) Same as two, but when your production code is in release/maintenance mode, bake everything into an AMI. When you need to deploy new code, you need to create a new AMI, but you are creating an AMI with scripts so its no big deal :) All you have to do now is update your cloudformation

[ Parent | on HN ]

Re:Why I left Heroku, and notes on my new AWS setup by druiid on Monday May 20, 2013 @01:49PM (#5738917)

Well this is why I suggested pre-running with Puppet and 'install' your code and dependencies into the AMI before saving it. That way you get the best of both worlds.

Obviously if you have a setup with rapidly deployed code changes you'll want to have your puppet manifest grab the latest version before deploying live when spinning up a new instance.

[ Parent | on HN ]

Re:Why I left Heroku, and notes on my new AWS setup by brown9-2 on Monday May 20, 2013 @02:11PM (#5739034)

I believe #3 is what Netflix does.

[ Parent | on HN ]