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.
Why I left Heroku, and notes on my new AWS setup
41–50 of 231 posts
Re: Why I left Heroku, and notes on my new AWS setup
#42Re: Why I left Heroku, and notes on my new AWS setup
#431. 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
#44Earlier 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?
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.
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
#46Re: Why I left Heroku, and notes on my new AWS setup
#47On 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…
Re: Why I left Heroku, and notes on my new AWS setup
#48Earlier 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.
Re: Why I left Heroku, and notes on my new AWS setup
#49If 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…