4 ms·
Maybe I can provide some insight, I'm a current paying Heroku customer, our monthly bill's in the hundreds/mo and I think it's a great value. I've been a user o
by andrewvc 17y ago
Maybe I can provide some insight, I'm a current paying Heroku customer, our monthly bill's in the hundreds/mo and I think it's a great value. I've been a user of Engine Yard Cloud in the past as well (same app). I like EY Cloud just fine, it's a great product, but Heroku's got a moderately more awesome experience, and I like their architecture and the granularity of their billing better.
To put it in simple terms, if you want a host with deep Rails knowledge that will manage systems administration for you, Heroku and Engine Yard Cloud are great offerings.
I actually have a reasonable amount of experience provisioning bare metal and virtual servers from the ground up and I still opted to go with Heroku and pay the premium for convenience. I just don't have the time to deal with hosting issues, my company can afford it, and I'd rather spend all my time developing. Additionally, compared to managed hosting from a company like Rackspace both options are much better. The Rackspace techs I spoke with, that would've been on my team didn't have much Rails specific knowledge, so I didn't see how they'd be able to offload as much work as a Rails specific host.
The Heroku workflow beats every other develop/deploy workflow I've ever seen. You could achieve the same stuff yourself, but it'd take a ton of work.
Want to send emails through sendgrid? 'heroku addons:add sendgrid', mailing just works, no reconfiguration.
Want pull your production db down to your dev machine? 'heroku db:pull'.
Want to deploy your app?
'git push heroku master'
Want to scale up the number of Dynos?
heroku dynos 6 #Scale to 6 Dynos
Want to make a backup of your DB and Code, then download it?
heroku bundles:capture
heroku bundles:download
Want to reset your application to the state it was in when you snapshotted a bundle?
heroku bundles:animate BUNDLENAME
Yeah, I could set up an approximation of this, but the fact is keeping stuff running is a chore that I'd rather not have, and my homegrown solution would have more warts and be funkier to use.
Additionally, their stack is pretty awesome, and you only pay for code that gets executed in the dynos, that means that rake tasks, cron jobs, and stuff cached by varnish is effectively free. This is important because it means those infrequently run CPU intensive tasks don't cause short losses of responsiveness.
Lastly, I've spoken at length with some people on the Heroku team, and I know them by blog posts they write. They're damn smart developers, and I definitely trust them to run Heroku right.
- ericd 17y agoGreat answers to the questions I've been wondering about. I might have to give Heroku a try. How's the database performance?
- andrewvc 17y agoIt's been reliably fast, our DB response times are typically between 3 and 4 ms, though at the moment our DB is overpowered as we haven't yet transitioned our truly DB intensive stuff onto it quite yet (we're on a Fugu, which is a High CPU Medium, and the dataset we're using easily fits in memory). That being said, working on Postgres has been noticably faster and more pleasant than MySQL. Complex queries in MySQL didn't benchmark as well as they did in Postgres. As far as the shared plans go, we use a cheap shared (koi) DB for our staging stuff, it's been snappy enough, even when re-syncing it with our production DB which obviously puts on a massive write load, but I couldn't really extrapolate much from that, and I have no idea how variable the performance winds up being with multi-tenancy on the DB. BTW, one of the joys of heroku really is db:push and pull. I can easily do: heroku db:pull #Pull production database onto local machine heroku db:push --app mystagingapp #Push the local DB onto the staging heroku db Just be sure to do this with a script, the last you ever want to do is push your dev DB to the production site.
- ericd 17y agoYeah, db:pull sounds pretty excellent - setting up a proper dev db mirror is more pain than it's worth, usually. Thanks again for the overview.