7 ms·

Heroku Isn't for Idiots: developer time and comparative advantage

237 points by bennylope 14y ago

zbowling 14y ago
It's why it's the goto for hackathons these days.
reedlaw 14y ago
> 512MB of RAM, 1GB of swap. Total = 1.5GB RAM What!? Swap is considered equivalent to RAM? From my experience, a single Heroku dyno performs better than a micro EC2 instance (613 RAM) but significantly worse than a small EC2 instance (1.7GB RAM). The first Heroku dyno is free, making it ideal for small sites, but as soon as you want to add anything outside of Heroku's sandbox, the prices are extremely inflated compared to AWS. For instance, adding an SSL cert to a Heroku app is $20. A small EC2 instance costs as little as $17.69 a month with 3 year buy-in (this is the average monthly cost with a 3 year heavy utilization reserved instance). Even if you pay monthly for an on-demand instance ($57.60/m) it's still much cheaper than Heroku considering you can comfortably run several services such as Redis, PostgreSQL, and Resque workers alongside your app. Each of those services will cost extra on Heroku. Of course, the trade off is the relative ease of deployment. Heroku is the easiest place to deploy, until your app grows more complicated. AWS is 2nd easiest, until you need even more control over hardware configurations. The most difficult deployment is on your own hardware, but it should also be the cheapest option.
- zeeg 14y ago
  Also these numbers are not accurate. I was consistently hitting the 512MB "limit" immediately, even with lightweight processes (not sure how tbh), and I frequently would see processes complaining that they were at 450% or more of their memory usage. I'm pretty confident that Heroku virtualizes EC2 instances which potentially makes them more resource strapped than they appear.
  - bri3d 14y ago
    They do; if you look at Herou's "dedicated" database instances the RAM numbers correlate perfectly with EC2 instance sizes. Even a "dedicated" Heroku database instance runs on shared EC2 hardware, making both its latency and throughput very unpredictable under any kind of serious workload. Combined with limitations in how their dyno instances work, like the inability to have more than one slug version deployed at once to take advantage of Heroku's routing fabric for hot-deployment, I only recommend Heroku for early-stage systems. Thankfully it's not very hard to migrate off of and still offers an awesome time savings in the early stages - it's just not something to build out on IMO.
    - zeeg 14y ago
      Those are not database instances that the specs are listed for
      - mgkimsal 14y ago
        Why did I read that in Obi-Wan's voice?
    - shykes 14y ago
      dotCloud (http://dotcloud.com http://dotcloud.com) offers the hot-deployment feature you describe with its new "granite" system. It works for an arbitrary number of parallel containers, too, so you can hot-deploy even when scaled out horizontally.
  - rdegges 14y ago
    So, I verified these numbers via `free -m` on my dyno. It's also referenced multiple places in the Heroku documentation. How were you monitoring the memory? Oo I'm curious to know as I actually run a ton of stuff on there, and haven't had any sort of memory issues (even with high usage background tasks).
  - moonboots 14y ago
    Heroku virtualizes dynos with linux container (lxc) [1]. The good thing is that lxc is very lightweight because it shares the host's kernel, so dynos aren't slowed by another virtualization abstraction in addition to ec2 xen. The bad thing for heroku users is that memory does not need to provisioned upfront for dynos, so spikes in memory usage of neighboring dynos can eat up all the memory in a physical machine. [1] https://devcenter.heroku.com/articles/dyno-isolation https://devcenter.heroku.com/articles/dyno-isolation
- jarcoal 14y ago
  Quick note on SSL: it's highly likely those prices will drop significantly once AWS supports multiple physical IPs per instance. Right now they have to provision an ELB to sit in front of your app to gain that extra IP.
  - grourk 14y ago
    AWS provides this now with VPC.
- moonboots 14y ago
  > 4 CPU cores (Intel Xeon X5550 @ 2.67GHz) The cpu specs are disingenuous as well. A heroku dyno may run on an intel xeon cpu, but I would never say a dyno "has" a 4 core cpu.
  - rdegges 14y ago
    Heya--not trying to be disingenuous. I was actually just copy/pasting stats from /proc/cpuinfo. I assumed the audience would realize that everything is virtualized and shared. Sorry if that gave off the wrong impression :o
Andys 14y ago
What people are waiting for is a set of tools that lets them run their own "mini Heroku" across multiple IaaS providers. I should be able to glue together my own cloud-based load balancer, deploying my app to webservers on different continents, with a monitored master-slave database set up -- all with freely available open-source software tools.
- chuckp 14y ago
  Have you checked out Nodejitsu? http://nodejitsu.com/ http://nodejitsu.com/ You still have to implement in app load balancing but this is easy via Hook.io, by the same group.
- zrail 14y ago
  Check out Dokuen[1]. If enough people are interested I might start taking it in that direction. [1]: https://github.com/peterkeen/dokuen https://github.com/peterkeen/dokuen
- trotsky 14y ago
  https://openshift.redhat.com/app/ https://openshift.redhat.com/app/ OpenShift is Redhat's open sorce PaaS. Ruby, node, python, java, php, etc. They run a free service on top of AWS, and you can deploy it on top of AWS, rackspace, hp, or anywhere on top of fedora or RHEL 6.2.
  - grk 14y ago
    I looked at OpenShifts codebase and I would throw this away after 15 minutes of code review. Looks like they wrote it in Rails because it was cool at the time, but had no idea how to build Rails apps.
    - andrewem 14y ago
      Would you mind adding more specifics? I'm curious about what bad Rails practices you found in the OpenShift codebase. (I've never worked on it, used it, or looked at the code, so my question comes from simple curiosity.)
rmoriz 14y ago
my suggestion: 1. Rent a cheap box at http://hetzner.com http://hetzner.com (32GB RAM/59€ per month; 64GB RAM/109€ per month) or http://OVH.ca/ http://OVH.ca/. 2. Install Proxmox VE 2.0 from http://proxmox.com/products/proxmox-ve http://proxmox.com/products/proxmox-ve Create virtual instances via RESTful API on demand: http://pve.proxmox.com/wiki/Proxmox_VE_API http://pve.proxmox.com/wiki/Proxmox_VE_API 3. use chef or puppet. => unbeatable price/value and it's up to you if/how you lock into technologies/abstractions/dynos/...
- halayli 14y ago
  hetzner problem in U.S is latency.
  - charliesome 14y ago
    In which case I find Interserver to be a good US host that's just as good and almost as cheap as Hetzner
    - doh 14y ago
      For real? The same HW costs like 8x more.
      - pbrumm 14y ago
        best I found in the US is reliablesite.net http://reliablesite.net/v4/ http://reliablesite.net/v4/ their twitter account has big discounts maybe only 4x more expensive, and they don't charge a monthly fee for a private network.
    - namidark 14y ago
      Interserver is much much more expensive
- jlawer 14y ago
  Yeah, but for that price your storage is backed by 7200RPM SATA disks... If you need speed it will cost you more for 15K SAS disks w/ a sizable battery backed RAID controller, but it will be worth every cent. You don't want to put too many VMs on them or you'll quickly go through your IO bandwidth. This is the problem so many devs don't understand. You run out of IOPS for your DB and your app is going nowhere. Managing storage in a reliable, fast and cost effective manner isn't easy. Consumer SSDs are starting to change that, but you will be still struggling to find many dedicated server offerings backed with SSD storage, and there are still questions about long term reliability (4 years or so) which is typically the period your leaving hardware provisioned for to pay it off.
latchkey 14y ago
Wow, this is awesome, so I must be an idiot. I've been playing around with Heroku with a simple NodeJS app that I don't care about the performance of for the last week. I've been scouring their website for information exactly like this and I couldn't find anything this comprehensive. Thanks so much for figuring this stuff out. Just answering the simple question of "Is the 750hr's free for each app or is it per account?" is golden. Anyone have an example of a simple NodeJS worker dyno? The web one is easy, now I'd like to see the other. I've been searching around and haven't found any good examples. Thx.
- jarcoal 14y ago
  It took me a while to realize that it was 750 hrs per app. That was a good day.
  - rdegges 14y ago
    This is one of the things I actually quite enjoy about Heroku--not to mention that with their new heroku-postgresql:dev plan, you can have up to 30 (yes, 30!) free databases PER APP! You can have like, 5 masters, with 5 readslaves each, etc. It's super awesome.
    - pvh 14y ago
      Two quick points. First, please don't abuse the free databases. Second, the free "dev" plan does not support fork or follow, nor do we plan to support those features on that plan in the near future.
  - mping 14y ago
    I didn't like it that much when I spinned 3 dynos and was hoping that when the 750hrs would be consumed, the service would be disabled. Worse, heroku asked for credit card info for account validation, and I never expected that I would be billed when using the free tier service, even when spinning extra dynos. I opened up a ticket and they said that they would look to improve this some point ahead. Luckily, I only use "virtual" credit cards (specially for "validation" purposes) and mine was expired before I was billed.
kenrikm 14y ago
I have my own server that I keep in a colo for a reasonable fee; I run small sites for family members and my email off of it. However for things that actually get traffic I go to Heroku or AWS, I don't need the headaches that come with a traffic spike on my server it's just not worth the hassle. git push heroku master FTW!
rubyrescue 14y ago
Inaka has two clients (of many), that are particularly comparable. One used a very "cloudy" Heroku stack with SimpleDB, Ruby, Rails, and Redis. It a number of scalability problems mostly related to the different components not performing predictably under load. A lot of time spent debugging this custom stack that was supposed to be seamless. Another client was (boxes running on a hosted server provider),using Erlang, Riak, some Rails, deployed w/Puppet. Comparable data volume; similar "Rails w/Dynamo" architecture, but -- much, much less magic. Much smaller operations bill, less time spent working around cloud platform issues, like inconsistent IO, expensive Amazon charges, lack of visibility into what is happening behind the scenes, etc. In some cases, Heroku is great; for us, particularly prototyping. But it's not always so clear when it's better to just boot some boxes and deploy some puppet or chef.
jlawer 14y ago
Really Heroku is a fine product but your paying a substantial cost for the service to manage some of the systems work. I say some because everyone using services like this should have a strategy to exit should some major event happen (prices raise, service becomes unreliable, company is acquired / folds) Most of the arguments against running a dedicated server was a straw man argument. YES High Availability is expensive if your talking an app that fits on a single server, but once you can get most services running with a N+1 reliability making it substantially cheaper. >His harddrive / memory / NIC / etc fails? Most dedicated hosting providers have an SLA to replace. Rackspace is 1 hour. If this SLA isn't suitable you setup a cluster. >He accidentally runs OS updates, and breaks versions of his packages? Welcome to backups... you should have them. Yes its expensive, yes its a pain in the arse... but you should have them anyway even if your on heroku. Lets be professionals here. > He wants to instantly rollback to a previous release of his codebase? Welcome to code deployment tools... Just because your not on heroku doesn't mean you can't have them >He wants to add another server to handle incoming HTTP requests? Its called resource planning... You know what those pretty little graphs are for. Again you should be doing this regardless of the service you are on. > He needs to spin up a database read slave to handle a high amount of read requests? See capacity planning. > His load balancer fails? Fail to wire modules, Clustered load balancers, virtual load balancers on a cluster... many options > His Fabric script stops working because he renamed his project or reorganizes his application directory tree? Testing... read about it... It really helps. You can also mess up any codebase by messing with the directory structure and not testing. > Or one of an infinite amount of other possible problems? Ok... and Heroku has a bunch of other problems. edit: fixed typos and Load balancer quote
- erikpukinskis 14y ago
  All of that is obviously possible (wonderful even!) to learn. But the thing is, it takes time. And on a small team, you really have to pick your battles. I don't know shit about load balancers. It's a hole in my knowledge. Eventually, I'm sure I'll get there. But I'm really glad I don't have to learn it right now. Because honestly I have my hands full putting out other fires without having to think about it.
  - 14y ago
bradgessler 14y ago
Heroku gets you into big trouble when their abstraction starts leaking and you need to dig deeper. If you never get to that point, this article makes sense, but when you turn that corner, expect a lot of pain.
- erikcw 14y ago
  Can you share a specific example?
Porter_423 14y ago
Good debate, and at the end, if u plan to write software for ppl to use, then consider use heroku, if u plan to work on hardware site like heroku company, then learning those manage and slove problem skill.one last thing is, it still not bad to learn those skill, after all, it's a knowledge
cardmagic 14y ago
Note my bias: I am the founder of AppFog.com which deploys CloudFoundry to public clouds as a service. "Heroku is Just Unix" No. Heroku is not "Just Unix". This statement is completely 100% wrong. To claim that what Heroku or any other PaaS does is "just VPS" or "just Unix" is so far off. People vastly underestimate how difficult it is to run a PaaS and how much technology it takes to pull it off at scale. I speak from experience, having built one PaaS from scratch and having used CloudFoundry to build a second one. The technology to get "just unix" into a fully managed, n-tier, scalable system is incredibly complex. I have heard people complain that CloudFoundry is overly complex, but these people judge a piece of open source code that does something that for so long has been hidden behind the curtains. Heroku is at least as complex if not more so, you just never see that part of the equation because you don't have to.
- fdr 14y ago
  > "Heroku is Just Unix" Well, I'll take the blame for this one. I often say this (in a positive light, which I believe is shared by the article) as someone who works at Heroku, and I think I said it to someone else (who had not used Heroku) while in the author's presence; other people might say this as well. The reason I say this is because a lot of people expect a lot of unique APIs or locked-in ways of doing things on Heroku, and it can be quite a while -- if ever -- before they find "heroku run bash" and sort of understand how little magic there is that they have to put in their application. For some people, it makes the idea of getting on and off the platform less scary. I also happen to like that my local machine models the remote environment in broad strokes quite closely.
- rdegges 14y ago
  Heya! It's extremely awesome to see a comment from you. I've actually been wanting to play around with appfog since I first saw it several months back. Anyhow--you're totally right. Heroku is definitely not 'just unix'. I really meant this in a different way than it may seem in the article. I was trying to get the point across that there's really no vendor lock-in, you can easily port your code back and fourth from a physical box or vps to Heroku, with almost no delay. Thanks again! Incredibly awesome to actually talk with you ^^
pg 14y ago
I wonder where he got that great picture of Adam Wiggins.
jay_kyburz 14y ago
So, I'm just a guy who makes video games. A one man operation. I'm mostly interested in interface and game design, I don't know, and don't really want to know anything about running the back end. Just the minimum to get the game running. Right now I'm running my games on Google App Engine and hosting is about 10% of gross. (Don't know if that's good but it's fine by me). For me, scaling means going from 3 or 4 instances to 20 or 30 in busy times. This all "just works" and I don't have to really do anything. I've been looking at Heroku because I've been working a little in node and there are some significant advantages to having js on the client and server. (rather than python on GAE) I was under the impression Heroku would just work too. I may not be an Idiot, but I sure am a n00b. Is Heroku not for me? Should I stick with App Engine?
- richardw 14y ago
  Rather focus on optimizing your GAE setup. It's a known entity and it's working for you, now just improve. There are almost always improvements that will reduce costs pretty significantly.
shykes 14y ago
(Disclaimer: I work at one of the companies in this list). In the interest of choice and healthy competition (and also in my own selfish interest, per the disclaimer above), I will point out that the arguments in this article apply to all good PaaS providers, of which there are plenty. As an insider in this particular crowd of vendors, I can tell you that the competition is fierce and it is entirely focused on delighting hackers - a trend which everyone here should be excited about. - cloudfoundry.com/appfog/stackato/tier3 are competing deployments of the cloudfoundry open-source project by VMWare - phpfog, pagodabox, orchestra: php-only - engine yard: ruby-only, also the leader in revenue, probably by a wide margin ($28m) - dotCloud: first multi-language paas, with a bunch of database services as well - Openshift: previously Makara, now part of Red Hat. Also available open-source - Djangozoom: django-only - Nodejitsu, nodester, no.de: nodejs-only - Cloudbees: Java only - Azure: solid .Net stack, impressive database service. Didn't use it directly but I've heard it's a great product. - AppHarbor: an alternate .Net provider - App Engine: much more restrictive than the others, but super cohesive and a great product if you don't mind the straightjacket
- kapilvt 14y ago
  sykes works at dotcloud.. phpfog is now appfog, and is cloudfoundry based. djangozoom is now appsembler also cloudfoundry based. all of the cloudfoundry based systems are multi-language, multi-db capable. openshift has no makara code remaining. its a fresh impl. its basically a simpler version of cloudfoundry. also multi-language, multi-db pass.
- rjsamson 14y ago
  Quick note - EngineYard offers PHP in addition to RoR.
deleted 14y ago
[deleted]
dagw 14y ago
My only real complaint with Heroku is that once you grow out of a basic no frills app, prices really rack up. For example I was looking to move an app I'm currently developing on a VPS to Heroku, but I use a ~200MB Redis database and just that will set me back $110/month. Heroku is great if you can fit your app within the free tier and great if you're happy to spend a few hundred bucks a month, but in between those two I'm often better off with on or two $20/month 1GB VPS.
- jshen 14y ago
  I feel exactly the same. I do a few hobby sites and I can't use heroku for this reason. People often reply that it's not meant for hobby sites, but I'll always bet on bottom up technologies, and cutting out hobby sites is not bottom up.
laundrysheet1 14y ago
"Yah--it isn't very hard to spin up some simple infrastructure services using Chef--pretty much anyone with a couple hours of free time can figure that out." This person has obviously never touched Chef. Chef's learning curve is steeeeeep.
anuraj 14y ago
Thanks, but no thanks! I am happy with the control an EC2 instance gives me in return for little more complexity in handling.
pbiggar 14y ago
We make a similar product to Heroku: Continuous Integration as a service (https://circleci.com https://circleci.com). I'm amazed at how many developers think their time is free. "I can just set up Jenkins" is the CI equivalent of the behaviour the OP rants against. And you're right, if your time is free. But it isn't free, and just like Heroku handles your security, scalability and lets you get back to work, so too does hosted CI handle machine setup, test speed, optimization and parallelization, without having to manage it all yourself. Long story short, developers significantly undervalue their time (and sometimes their bosses do too).

237 points by bennylope 14y ago

It's why it's the goto for hackathons these days.

> 512MB of RAM, 1GB of swap. Total = 1.5GB RAM What!? Swap is considered equivalent to RAM? From my experience, a single Heroku dyno performs better than a micro EC2 instance (613 RAM) but significantly worse than a small EC2 instance (1.7GB RAM). The first Heroku dyno is free, making it ideal for small sites, but as soon as you want to add anything outside of Heroku's sandbox, the prices are extremely inflated compared to AWS. For instance, adding an SSL cert to a Heroku app is $20. A small EC2 instance costs as little as $17.69 a month with 3 year buy-in (this is the average monthly cost with a 3 year heavy utilization reserved instance). Even if you pay monthly for an on-demand instance ($57.60/m) it's still much cheaper than Heroku considering you can comfortably run several services such as Redis, PostgreSQL, and Resque workers alongside your app. Each of those services will cost extra on Heroku. Of course, the trade off is the relative ease of deployment. Heroku is the easiest place to deploy, until your app grows more complicated. AWS is 2nd easiest, until you need even more control over hardware configurations. The most difficult deployment is on your own hardware, but it should also be the cheapest option.

zeeg 14y ago
Also these numbers are not accurate. I was consistently hitting the 512MB "limit" immediately, even with lightweight processes (not sure how tbh), and I frequently would see processes complaining that they were at 450% or more of their memory usage. I'm pretty confident that Heroku virtualizes EC2 instances which potentially makes them more resource strapped than they appear.
- bri3d 14y ago
  They do; if you look at Herou's "dedicated" database instances the RAM numbers correlate perfectly with EC2 instance sizes. Even a "dedicated" Heroku database instance runs on shared EC2 hardware, making both its latency and throughput very unpredictable under any kind of serious workload. Combined with limitations in how their dyno instances work, like the inability to have more than one slug version deployed at once to take advantage of Heroku's routing fabric for hot-deployment, I only recommend Heroku for early-stage systems. Thankfully it's not very hard to migrate off of and still offers an awesome time savings in the early stages - it's just not something to build out on IMO.
  - zeeg 14y ago
    Those are not database instances that the specs are listed for
    - mgkimsal 14y ago
      Why did I read that in Obi-Wan's voice?
  - shykes 14y ago
    dotCloud (http://dotcloud.com http://dotcloud.com) offers the hot-deployment feature you describe with its new "granite" system. It works for an arbitrary number of parallel containers, too, so you can hot-deploy even when scaled out horizontally.
- rdegges 14y ago
  So, I verified these numbers via `free -m` on my dyno. It's also referenced multiple places in the Heroku documentation. How were you monitoring the memory? Oo I'm curious to know as I actually run a ton of stuff on there, and haven't had any sort of memory issues (even with high usage background tasks).
- moonboots 14y ago
  Heroku virtualizes dynos with linux container (lxc) [1]. The good thing is that lxc is very lightweight because it shares the host's kernel, so dynos aren't slowed by another virtualization abstraction in addition to ec2 xen. The bad thing for heroku users is that memory does not need to provisioned upfront for dynos, so spikes in memory usage of neighboring dynos can eat up all the memory in a physical machine. [1] https://devcenter.heroku.com/articles/dyno-isolation https://devcenter.heroku.com/articles/dyno-isolation
jarcoal 14y ago
Quick note on SSL: it's highly likely those prices will drop significantly once AWS supports multiple physical IPs per instance. Right now they have to provision an ELB to sit in front of your app to gain that extra IP.
- grourk 14y ago
  AWS provides this now with VPC.
moonboots 14y ago
> 4 CPU cores (Intel Xeon X5550 @ 2.67GHz) The cpu specs are disingenuous as well. A heroku dyno may run on an intel xeon cpu, but I would never say a dyno "has" a 4 core cpu.
- rdegges 14y ago
  Heya--not trying to be disingenuous. I was actually just copy/pasting stats from /proc/cpuinfo. I assumed the audience would realize that everything is virtualized and shared. Sorry if that gave off the wrong impression :o

Andys 14y ago

What people are waiting for is a set of tools that lets them run their own "mini Heroku" across multiple IaaS providers. I should be able to glue together my own cloud-based load balancer, deploying my app to webservers on different continents, with a monitored master-slave database set up -- all with freely available open-source software tools.

chuckp 14y ago
Have you checked out Nodejitsu? http://nodejitsu.com/ http://nodejitsu.com/ You still have to implement in app load balancing but this is easy via Hook.io, by the same group.
zrail 14y ago
Check out Dokuen[1]. If enough people are interested I might start taking it in that direction. [1]: https://github.com/peterkeen/dokuen https://github.com/peterkeen/dokuen
trotsky 14y ago
https://openshift.redhat.com/app/ https://openshift.redhat.com/app/ OpenShift is Redhat's open sorce PaaS. Ruby, node, python, java, php, etc. They run a free service on top of AWS, and you can deploy it on top of AWS, rackspace, hp, or anywhere on top of fedora or RHEL 6.2.
- grk 14y ago
  I looked at OpenShifts codebase and I would throw this away after 15 minutes of code review. Looks like they wrote it in Rails because it was cool at the time, but had no idea how to build Rails apps.
  - andrewem 14y ago
    Would you mind adding more specifics? I'm curious about what bad Rails practices you found in the OpenShift codebase. (I've never worked on it, used it, or looked at the code, so my question comes from simple curiosity.)

rmoriz 14y ago

my suggestion: 1. Rent a cheap box at http://hetzner.com http://hetzner.com (32GB RAM/59€ per month; 64GB RAM/109€ per month) or http://OVH.ca/ http://OVH.ca/. 2. Install Proxmox VE 2.0 from http://proxmox.com/products/proxmox-ve http://proxmox.com/products/proxmox-ve Create virtual instances via RESTful API on demand: http://pve.proxmox.com/wiki/Proxmox_VE_API http://pve.proxmox.com/wiki/Proxmox_VE_API 3. use chef or puppet. => unbeatable price/value and it's up to you if/how you lock into technologies/abstractions/dynos/...

halayli 14y ago
hetzner problem in U.S is latency.
- charliesome 14y ago
  In which case I find Interserver to be a good US host that's just as good and almost as cheap as Hetzner
  - doh 14y ago
    For real? The same HW costs like 8x more.
    - pbrumm 14y ago
      best I found in the US is reliablesite.net http://reliablesite.net/v4/ http://reliablesite.net/v4/ their twitter account has big discounts maybe only 4x more expensive, and they don't charge a monthly fee for a private network.
  - namidark 14y ago
    Interserver is much much more expensive
jlawer 14y ago
Yeah, but for that price your storage is backed by 7200RPM SATA disks... If you need speed it will cost you more for 15K SAS disks w/ a sizable battery backed RAID controller, but it will be worth every cent. You don't want to put too many VMs on them or you'll quickly go through your IO bandwidth. This is the problem so many devs don't understand. You run out of IOPS for your DB and your app is going nowhere. Managing storage in a reliable, fast and cost effective manner isn't easy. Consumer SSDs are starting to change that, but you will be still struggling to find many dedicated server offerings backed with SSD storage, and there are still questions about long term reliability (4 years or so) which is typically the period your leaving hardware provisioned for to pay it off.

latchkey 14y ago

Wow, this is awesome, so I must be an idiot. I've been playing around with Heroku with a simple NodeJS app that I don't care about the performance of for the last week. I've been scouring their website for information exactly like this and I couldn't find anything this comprehensive. Thanks so much for figuring this stuff out. Just answering the simple question of "Is the 750hr's free for each app or is it per account?" is golden. Anyone have an example of a simple NodeJS worker dyno? The web one is easy, now I'd like to see the other. I've been searching around and haven't found any good examples. Thx.

jarcoal 14y ago
It took me a while to realize that it was 750 hrs per app. That was a good day.
- rdegges 14y ago
  This is one of the things I actually quite enjoy about Heroku--not to mention that with their new heroku-postgresql:dev plan, you can have up to 30 (yes, 30!) free databases PER APP! You can have like, 5 masters, with 5 readslaves each, etc. It's super awesome.
  - pvh 14y ago
    Two quick points. First, please don't abuse the free databases. Second, the free "dev" plan does not support fork or follow, nor do we plan to support those features on that plan in the near future.
- mping 14y ago
  I didn't like it that much when I spinned 3 dynos and was hoping that when the 750hrs would be consumed, the service would be disabled. Worse, heroku asked for credit card info for account validation, and I never expected that I would be billed when using the free tier service, even when spinning extra dynos. I opened up a ticket and they said that they would look to improve this some point ahead. Luckily, I only use "virtual" credit cards (specially for "validation" purposes) and mine was expired before I was billed.

kenrikm 14y ago

I have my own server that I keep in a colo for a reasonable fee; I run small sites for family members and my email off of it. However for things that actually get traffic I go to Heroku or AWS, I don't need the headaches that come with a traffic spike on my server it's just not worth the hassle. git push heroku master FTW!

rubyrescue 14y ago

Inaka has two clients (of many), that are particularly comparable. One used a very "cloudy" Heroku stack with SimpleDB, Ruby, Rails, and Redis. It a number of scalability problems mostly related to the different components not performing predictably under load. A lot of time spent debugging this custom stack that was supposed to be seamless. Another client was (boxes running on a hosted server provider),using Erlang, Riak, some Rails, deployed w/Puppet. Comparable data volume; similar "Rails w/Dynamo" architecture, but -- much, much less magic. Much smaller operations bill, less time spent working around cloud platform issues, like inconsistent IO, expensive Amazon charges, lack of visibility into what is happening behind the scenes, etc. In some cases, Heroku is great; for us, particularly prototyping. But it's not always so clear when it's better to just boot some boxes and deploy some puppet or chef.

jlawer 14y ago

Really Heroku is a fine product but your paying a substantial cost for the service to manage some of the systems work. I say some because everyone using services like this should have a strategy to exit should some major event happen (prices raise, service becomes unreliable, company is acquired / folds) Most of the arguments against running a dedicated server was a straw man argument. YES High Availability is expensive if your talking an app that fits on a single server, but once you can get most services running with a N+1 reliability making it substantially cheaper. >His harddrive / memory / NIC / etc fails? Most dedicated hosting providers have an SLA to replace. Rackspace is 1 hour. If this SLA isn't suitable you setup a cluster. >He accidentally runs OS updates, and breaks versions of his packages? Welcome to backups... you should have them. Yes its expensive, yes its a pain in the arse... but you should have them anyway even if your on heroku. Lets be professionals here. > He wants to instantly rollback to a previous release of his codebase? Welcome to code deployment tools... Just because your not on heroku doesn't mean you can't have them >He wants to add another server to handle incoming HTTP requests? Its called resource planning... You know what those pretty little graphs are for. Again you should be doing this regardless of the service you are on. > He needs to spin up a database read slave to handle a high amount of read requests? See capacity planning. > His load balancer fails? Fail to wire modules, Clustered load balancers, virtual load balancers on a cluster... many options > His Fabric script stops working because he renamed his project or reorganizes his application directory tree? Testing... read about it... It really helps. You can also mess up any codebase by messing with the directory structure and not testing. > Or one of an infinite amount of other possible problems? Ok... and Heroku has a bunch of other problems. edit: fixed typos and Load balancer quote

erikpukinskis 14y ago
All of that is obviously possible (wonderful even!) to learn. But the thing is, it takes time. And on a small team, you really have to pick your battles. I don't know shit about load balancers. It's a hole in my knowledge. Eventually, I'm sure I'll get there. But I'm really glad I don't have to learn it right now. Because honestly I have my hands full putting out other fires without having to think about it.
- 14y ago

bradgessler 14y ago

Heroku gets you into big trouble when their abstraction starts leaking and you need to dig deeper. If you never get to that point, this article makes sense, but when you turn that corner, expect a lot of pain.

erikcw 14y ago
Can you share a specific example?

Porter_423 14y ago

Good debate, and at the end, if u plan to write software for ppl to use, then consider use heroku, if u plan to work on hardware site like heroku company, then learning those manage and slove problem skill.one last thing is, it still not bad to learn those skill, after all, it's a knowledge

cardmagic 14y ago

Note my bias: I am the founder of AppFog.com which deploys CloudFoundry to public clouds as a service. "Heroku is Just Unix" No. Heroku is not "Just Unix". This statement is completely 100% wrong. To claim that what Heroku or any other PaaS does is "just VPS" or "just Unix" is so far off. People vastly underestimate how difficult it is to run a PaaS and how much technology it takes to pull it off at scale. I speak from experience, having built one PaaS from scratch and having used CloudFoundry to build a second one. The technology to get "just unix" into a fully managed, n-tier, scalable system is incredibly complex. I have heard people complain that CloudFoundry is overly complex, but these people judge a piece of open source code that does something that for so long has been hidden behind the curtains. Heroku is at least as complex if not more so, you just never see that part of the equation because you don't have to.

fdr 14y ago
> "Heroku is Just Unix" Well, I'll take the blame for this one. I often say this (in a positive light, which I believe is shared by the article) as someone who works at Heroku, and I think I said it to someone else (who had not used Heroku) while in the author's presence; other people might say this as well. The reason I say this is because a lot of people expect a lot of unique APIs or locked-in ways of doing things on Heroku, and it can be quite a while -- if ever -- before they find "heroku run bash" and sort of understand how little magic there is that they have to put in their application. For some people, it makes the idea of getting on and off the platform less scary. I also happen to like that my local machine models the remote environment in broad strokes quite closely.
rdegges 14y ago
Heya! It's extremely awesome to see a comment from you. I've actually been wanting to play around with appfog since I first saw it several months back. Anyhow--you're totally right. Heroku is definitely not 'just unix'. I really meant this in a different way than it may seem in the article. I was trying to get the point across that there's really no vendor lock-in, you can easily port your code back and fourth from a physical box or vps to Heroku, with almost no delay. Thanks again! Incredibly awesome to actually talk with you ^^

pg 14y ago

I wonder where he got that great picture of Adam Wiggins.

jay_kyburz 14y ago

So, I'm just a guy who makes video games. A one man operation. I'm mostly interested in interface and game design, I don't know, and don't really want to know anything about running the back end. Just the minimum to get the game running. Right now I'm running my games on Google App Engine and hosting is about 10% of gross. (Don't know if that's good but it's fine by me). For me, scaling means going from 3 or 4 instances to 20 or 30 in busy times. This all "just works" and I don't have to really do anything. I've been looking at Heroku because I've been working a little in node and there are some significant advantages to having js on the client and server. (rather than python on GAE) I was under the impression Heroku would just work too. I may not be an Idiot, but I sure am a n00b. Is Heroku not for me? Should I stick with App Engine?

richardw 14y ago
Rather focus on optimizing your GAE setup. It's a known entity and it's working for you, now just improve. There are almost always improvements that will reduce costs pretty significantly.

shykes 14y ago

(Disclaimer: I work at one of the companies in this list). In the interest of choice and healthy competition (and also in my own selfish interest, per the disclaimer above), I will point out that the arguments in this article apply to all good PaaS providers, of which there are plenty. As an insider in this particular crowd of vendors, I can tell you that the competition is fierce and it is entirely focused on delighting hackers - a trend which everyone here should be excited about. - cloudfoundry.com/appfog/stackato/tier3 are competing deployments of the cloudfoundry open-source project by VMWare - phpfog, pagodabox, orchestra: php-only - engine yard: ruby-only, also the leader in revenue, probably by a wide margin ($28m) - dotCloud: first multi-language paas, with a bunch of database services as well - Openshift: previously Makara, now part of Red Hat. Also available open-source - Djangozoom: django-only - Nodejitsu, nodester, no.de: nodejs-only - Cloudbees: Java only - Azure: solid .Net stack, impressive database service. Didn't use it directly but I've heard it's a great product. - AppHarbor: an alternate .Net provider - App Engine: much more restrictive than the others, but super cohesive and a great product if you don't mind the straightjacket

kapilvt 14y ago
sykes works at dotcloud.. phpfog is now appfog, and is cloudfoundry based. djangozoom is now appsembler also cloudfoundry based. all of the cloudfoundry based systems are multi-language, multi-db capable. openshift has no makara code remaining. its a fresh impl. its basically a simpler version of cloudfoundry. also multi-language, multi-db pass.
rjsamson 14y ago
Quick note - EngineYard offers PHP in addition to RoR.

deleted 14y ago

[deleted]

dagw 14y ago

My only real complaint with Heroku is that once you grow out of a basic no frills app, prices really rack up. For example I was looking to move an app I'm currently developing on a VPS to Heroku, but I use a ~200MB Redis database and just that will set me back $110/month. Heroku is great if you can fit your app within the free tier and great if you're happy to spend a few hundred bucks a month, but in between those two I'm often better off with on or two $20/month 1GB VPS.

jshen 14y ago
I feel exactly the same. I do a few hobby sites and I can't use heroku for this reason. People often reply that it's not meant for hobby sites, but I'll always bet on bottom up technologies, and cutting out hobby sites is not bottom up.

laundrysheet1 14y ago

"Yah--it isn't very hard to spin up some simple infrastructure services using Chef--pretty much anyone with a couple hours of free time can figure that out." This person has obviously never touched Chef. Chef's learning curve is steeeeeep.

anuraj 14y ago

Thanks, but no thanks! I am happy with the control an EC2 instance gives me in return for little more complexity in handling.

pbiggar 14y ago

We make a similar product to Heroku: Continuous Integration as a service (https://circleci.com https://circleci.com). I'm amazed at how many developers think their time is free. "I can just set up Jenkins" is the CI equivalent of the behaviour the OP rants against. And you're right, if your time is free. But it isn't free, and just like Heroku handles your security, scalability and lets you get back to work, so too does hosted CI handle machine setup, test speed, optimization and parallelization, without having to manage it all yourself. Long story short, developers significantly undervalue their time (and sometimes their bosses do too).