Live data from Hacker News

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

holovaty.com

41–50 of 231 posts

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

#41

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.

A month or so ago I thought about starting a hosted Postgres service on top of EC2, since lots of people seem to want "RDS for Postgres." I think if you specialized you could beat Heroku's offering, but ultimately I decided there was too much risk of Amazon simply adding Postgres themselves. But if anyone is more daring than me, perhaps there is an opportunity here.

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

#43
Two quick Heroku recommendations that wouldn't fix all (any?) of these issues, but would at least make them more palatable.

1. Change your default heroku error pages. From this: http://s3.amazonaws.com/heroku_pages/error.html and this: http://s3.amazonaws.com/heroku_pages/maintenance.html to something else (in the app settings tab).

2. Keep a staging instance up and running with a cloned database so that you can avoid random heroku-created errors in production.

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

#44

Earlier quoted context omitted.

Did you consider using Heroku Postgres?

I'm not the OP, but the thing that's always scared me off from those types of services is that I think there would be high latency, where in a DB you really need low latency. Is that not true?

Since Heroku runs on EC2, as long as OP kept his servers in the same availability zone as the DB, latency shouldn't be any worse than running it himself. But yes, in general I'd be wary of a database far away from my app servers.

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

#45

> 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 get itself ready while also integrating configuration management (which really you should be doing these days). Just some suggestions from a sysadmin.

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

#47

On my end I get a complete crash once a week when running with one dyno. The official response for support I got was to upgrade to two dynos. Apart from the PostgreSQL hosting, I'm not really happy with Heroku. Add to the random deploy breakage I've experienced mid-launch (not to mention it's slow as hell), I'm going to move back to my own servers.

Heroku docs do say (and I'm afraid the link to it is escaping me) that if you run only 1 dyno, it will shut down after something like 6 hours of inactivity. So if no one hits your site for 6 hours, the next time someone does it has to boot the dyno up again, which can take enough time for the request to time out. Not saying this is a great policy, just explaining in case you weren't sure. When you go to 2 dynos they…

My app is pretty highly trafficked, there isn't a 6 hour window of inactivity anywhere from my logs. What about it running out of RAM?

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

#48
post #8

Earlier quoted context omitted.

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.

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.

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

#49

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…

I really want to use Salt for something one of these days given I work with Python quite a bit... but basically at this point my investment with Puppet is relatively significant, so I'm not sure if the pain of switching would be worth it. I'm sure eventually I'll find a use for it though! I like what I've seen before.
Post reply on HN