4 ms·

I'm still not sure what market Heroku is addressing. It's great for free apps, but as soon as you start to have to pay money, it doesn't seem competitive compar

by swombat 17y ago

I'm still not sure what market Heroku is addressing. It's great for free apps, but as soon as you start to have to pay money, it doesn't seem competitive compared to other options... Am I missing a trick here? Are paid Heroku accounts actually the best thing ever?

dcurtis 17y ago
How is it not competitive? It scales almost perfectly linearly with user growth, from a few dollars a month up to a few thousand a month. When there's a surge of users to one of my sites, I just add a dyno which handles the load perfectly well for a few days, and then I get a bill for 3 dollars at the end of the month.
- amock 17y ago
  Heroku says that four dynos is one CPU. So you pay $106 per month for one CPU. So for $121 per month you get 20GB of storage and one CPU, which seems really expensive once you consistently need resources. Before you consistently need resources you can just get a cheap VPS to handle the load.
jackowayed 17y ago
It's a convenience thing. There's a lot of value to just not having to worry about your servers. You spend 0 time setting up your hosting, and it scales pretty much infinitely in seconds.
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 ago
  Great answers to the questions I've been wondering about. I might have to give Heroku a try. How's the database performance?
  - andrewvc 17y ago
    It'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 ago
      Yeah, 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.

by swombat 17y ago

dcurtis 17y ago

How is it not competitive? It scales almost perfectly linearly with user growth, from a few dollars a month up to a few thousand a month. When there's a surge of users to one of my sites, I just add a dyno which handles the load perfectly well for a few days, and then I get a bill for 3 dollars at the end of the month.

amock 17y ago
Heroku says that four dynos is one CPU. So you pay $106 per month for one CPU. So for $121 per month you get 20GB of storage and one CPU, which seems really expensive once you consistently need resources. Before you consistently need resources you can just get a cheap VPS to handle the load.

jackowayed 17y ago

It's a convenience thing. There's a lot of value to just not having to worry about your servers. You spend 0 time setting up your hosting, and it scales pretty much infinitely in seconds.

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 ago
Great answers to the questions I've been wondering about. I might have to give Heroku a try. How's the database performance?
- andrewvc 17y ago
  It'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 ago
    Yeah, 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.