Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

holovaty.com

Post reply on HN
Print view View original

81–90 of 231 posts

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

#81

Post by gazarsgo »

tomsthumb wrote: post #27
boothead wrote: post #16

If you think puppet/chef is too much complexity you might find saltstack worth some attention. I haven't used it in real anger yet, but I've really liked what I've seen so far. I see they've even got instructions specific to aws now too [1] Also worth mentioning cloud formation as well [2]. That might make the pain of chef/puppet more of a worthwhile investment! [1] https://salt-cloud.readthedocs.org/en/latest/topics…

Ansible is another alternative that is relatively simple.

I've been using Ansible for a couple weeks now and it is awesome how simple it is compared to Chef/Puppet (IMO)

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

#84

Post by rschmitty »

druiid wrote: post #45
bearwithclaws wrote: post #4

> The way we set up Soundslice is relatively simple. We made a custom AMI with our code/dependencies, then set up an Elastic Load Balancer with auto-scaling rules that instantiate app servers from that AMI based on load. Doesn't sound that simple to me (as a complete sysadmin noob). Somebody should write a book about this.

That's actually, honestly, a bad way to do it. It's fine to pre-load an instance with source and application/package dependencies. At this point though, you really should be backing those up with it being deployed by Puppet/Chef. Essentially you pre-run a puppet manifest and have it do all the first-run processing and then store THAT as the AMI/instance. This way you have an instance that only needs a few seconds to…

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

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

#85

Post by rschmitty »

deno wrote: post #83

Yet another post about scalability/architecture that goes down under load. There should be some rule for that. http://i.imgur.com/UEHzaOL.png EDIT: Back online, the site migrated to AWS is not the blog.

It also looks like the Heroku app error page to me

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

#86

Post by rhuppert »

toomuchtodo wrote: post #14
bearwithclaws wrote: post #4

> The way we set up Soundslice is relatively simple. We made a custom AMI with our code/dependencies, then set up an Elastic Load Balancer with auto-scaling rules that instantiate app servers from that AMI based on load. Doesn't sound that simple to me (as a complete sysadmin noob). Somebody should write a book about this.

Would you be interested in a blog post about it? I'm a sysadmin/devops with 12 years in, and build stuff like this on a daily basis. I wouldn't mind sharing how the sausage is made.

Hot dog! I am also interested. I hope your recipe is free of fillers and artificial ingredients. Looking forward to casing your blog site. Address?

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

#87

Post by topherjaynes »

deno wrote: post #83

Yet another post about scalability/architecture that goes down under load. There should be some rule for that. http://i.imgur.com/UEHzaOL.png EDIT: Back online, the site migrated to AWS is not the blog.

Heroku App Error page. Clever way to show why he left Heroku? I'm sure my constant refreshing isn't helping.

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

#88

Post by targusman »

deno wrote: post #83

Yet another post about scalability/architecture that goes down under load. There should be some rule for that. http://i.imgur.com/UEHzaOL.png EDIT: Back online, the site migrated to AWS is not the blog.

Isn't this guy one of the two best Django people around? Maybe heroku shut him down?

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

#89

Post by druiid »

rschmitty wrote: post #84
druiid wrote: post #45

Earlier quoted context omitted.

That's actually, honestly, a bad way to do it. It's fine to pre-load an instance with source and application/package dependencies. At this point though, you really should be backing those up with it being deployed by Puppet/Chef. Essentially you pre-run a puppet manifest and have it do all the first-run processing and then store THAT as the AMI/instance. This way you have an instance that only needs a few seconds to…

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 ar…

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.

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

#90

Post by rschmitty »

riffraff wrote: post #76
toomuchtodo wrote: post #17

Earlier quoted context omitted.

RDS is pretty expensive for what you get. You can't restore to a running instance from snapshots, you get very little control over the environment, and you can't replicate between geographic regions (only availability zones). I know you said you're a two man shop, but in this case it may make more sense to leverage other IaaS DB services instead of RDS.

I am not sure what you mean by "You can't restore to a running instance from snapshots" cause, well, I've done it a few times. Could you expand a bit maybe?

I have also used their snapshots with success
Post reply on HN