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

101–110 of 231 posts

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

#101

Post by ilink »

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.

Definitely!

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

#102

Post by brown9-2 »

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…

I believe #3 is what Netflix does.

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

#103

Post by dangrossman »

adrianh wrote: post #8
andrewgodwin wrote: post #3

Sad to see the recommendation to use MySQL - in my experience RDS hasn't been worth the effort - but I'm probably biased since I already invested the time in automating PostgreSQL replication setup.

Believe me, I am sad to stop using Postgres. What parts of RDS haven't been worth the effort? I didn't have to make much effort, beyond rewriting my Postgres triggers into MySQL syntax.

Inconsistent performance, significantly slower than MySQL on a real box, and failure of the ridiculously expensive automatic failover were the reasons I dumped RDS. I ate a big loss after reserving instances, but seeing the server fall off the planet, and no spare ever take over for it despite paying for MultiAZ, what other response would have been reasonable?

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

#104

Post by jcastro »

We're working on solving these sorts of devops problems in Ubuntu with Juju: https://juju.ubuntu.com/

As an alternative approach would be that a Juju charm (script) would handle the initial deployment of a stock Ubuntu AMI and the customization in one step (or with puppet/chef) and then allow you to add new instances based on scale (though currently not automatic). When you have changes to your service you update the charm and just `juju upgrade-charm`.

This would consolidate step 1, 5, and the "ongoing" into one tool and you'd get a cloud-agnostic deployment (openstack cloud or bare-metal).

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

#105

Post by RKearney »

the_economist wrote: post #48
andrewgodwin wrote: post #32

Earlier quoted context omitted.

I've seen RDS have significant per-query overhead, and some very, very variable read times - in particular, some simple SELECTs randomly taking > 10s every so often.

Is your ec2 instance in the exact same zone/region as your rds instance? An ec2 instance in us-east-1a will have extra latency dealing with an instance in any other zone, even us-east-1c.

Stating us-east-1a means nothing, since your us-east-1a is someone else's us-east-1d. They're not the same across AWS accounts.

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

#106

Post by coolsunglasses »

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.

It's not simple, AMIs are a pretty bad idea and not something you should rely on due to the statefulness and vendor lock-in unless you can reproduce it in disparate deployment environments from scripts.

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

#107

Post by adrianh »

killion wrote: post #65

I get a 500 when I go to the site. It seems like a bad omen for an article about your hosting setup.

Which site? My blog? The blog is still on Heroku, and it sounds like it was overloaded for a while there. I just upped the number of dynos, so it should be fine.

I don't have any indication that soundslice.com (which is the site I'm hosting on AWS) was returning any 500s, but if it was, please let me know.

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

#108

Post by adrianh »

nutmeg wrote: post #50

When exactly do you bake a new AMI? On every Soundslice deploy?

No, definitely not on every deploy! For a deploy, I just do a "git pull" on all of the production boxes and restart the web server.

Baking a new AMI only happens when there are new underlying dependencies, like a new package from apt-get or a new Python module from pip. In other words, it's rare.

Hope that helps!

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

#109

Post by adrianh »

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.

Heh -- my blog is still hosted on Heroku, and I forgot to up the dynos. Which I suppose is a nice (and ironic) argument for doing the AWS auto-scaling stuff!

The site I was writing about, soundslice.com, has not seen any blips.

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

#110

Post by ceejayoz »

gingerlime wrote: post #74
ceejayoz wrote: post #29

Earlier quoted context omitted.

You can just bump up to AWS's $50 paid support as-needed for one month, if you need to. They've been very responsive to us with the three cases we've opened - roughly an hour to resolution each time.

Thanks. That makes more sense, and I guess a reasonable price if you consider you don't need this every month. According to https://aws.amazon.com/premiumsupport/ - the developer support is within local business hours though... I still wish this could have been factored into your hourly AWS costs rather than as a monthly fee. Say, pay extra 10% for every EC2 instance-hour or something and get it included (without the…

It wouldn't be sustainable. The folks trying to build the next Amazon.com on a t1.micro would be paying a buck a month and expecting the same level of support Netflix gets.
Post reply on HN