This comes up all the time with my company. We make hosted Continous Integration (https://circleci.com), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where your tests fail because the IO is bad? What about when three people push at once and you want to get results ASAP? Are you going to manually compile Postgres 9.1? And again when you add a second box to you cluster?
I could go on.
:fingers crossed:
Heroku does make a lot of sense: it's an abstraction. You're using a system designed to do a lot of the heavy lifting so you don't have to deal with those details, and for many startups and small operations, it's a great value proposition.
But you have to admit that it is only a value proposition; and fundamentally a tradeoff. The truth is, especially from the perspective of a seasoned operations manager, all of the things above are just not that hard, nor are any of the complaints outlined in the OP article.
The more layers you put between you and your infrastructure, the harder it will be to control your availability. When EBS's start failing and you have no idea why and Amazon only shows a green dot on their status page with a cryptic message like "minor availability issues experienced in certain availability zones; investigating." Now that is hard.
Cloning a server and keeping a mirrored backup in another data center if you really need the availability? On hardware you have full control over? Not that hard. http://whoownsmyavailability.com/
First the UI could use some work, but it was really awesome seeing it pull down a Flask app and knowing to activate venv and install pip.
Also, not having an option to delete your account is a bit scary, seeing as I'm part of an organization on github and not comfortable with you having access to that code.
There is an option to delete your account. One option is to contact us (I know, that's not great, but we delete same day). The other option is to rip out Circle's authentication via GitHub, if you're worried about us doing it properly.
Heroku seems to be like a more useful Google App Engine, a good place to host a blog or experimental project if you're not into dev-ops.
If you have a knack (at all) for dev-ops, you're not saving yourself anything.
The downtime is pretty bleh too. The moment you start doing multi-provider to offset this, you'll end up doing all the dev-ops work you would've had to have done before. Except now, you have to do it all at once in a time of what is probably high stress.
If you do the dev-ops/automation yourself from the start, you can start small/simple and grow that as you go, deploying your services to arbitrary hosting providers (EC2, Linode, dedicated boxes, whatever).
This is why whenever anybody asks me my opinion of Heroku, I respond, "it's a great place to host that blog engine you wrote in Haskell/Clojure/{hipster_language_of_choice}".
There are a ton of real sites that never see more than a couple hundred thousand visitors a month. E-commerce sites, mobile APIs, SAAS apps, etc. I've used Heroku for higher traffic sites than this without any issues at all. Incredibly easy actually.
Saying it's only good for your hipster blog? C'mon man really? Have you even done anything commercial / critical on their platform?
Agree. Those people who tell horror stories about Heroku/EC2, usually give solid numbers, i.e. this was how much I spent, this is how much I save by moving away, and our response time is now X% faster.
On the other hand, we have article like this that shows pretty graph for a web app serving 16.2 requests per minute, and make bold claims that everything will scale.
Considering Heroku is single-homed, I find it hilarious that you say it's less of a toy than GAE.
1) If your app crashes it takes ages to restart dynos "automatically", there's nothing at all instant about it and if it's a bug and you have a high volume of requests it's going to hit every dyno which means you are offline.
2) Performance can be variable and it can be hard to be sure an optimization has done anything. This will be easier when New Relic supports NodeJS but right now you're stuck using less elegant solutions. It is shared hosting and it's not necessarily anybody's fault if something is slow, and I know this because the same requests frequently have orders of magnitude difference in response time for me.
dyno=web.10 queue=0 wait=0ms service=3ms status=200 bytes=25
dyno=web.7 queue=0 wait=0ms service=207ms status=200 bytes=28
Between Heroku and NodeJS I run my API server usually on just 8 dynos doing 6,000 - 10,000 requests per second and having come from C# and dedicated Windows servers it is a dream - nothing to maintain and easy deployment and easy debugging on Heroku's side, and NodeJS is just amazing once you start realizing what's possible with it.Maybe I misunderstood and your main app is rails with some of the other functionality in node.
I sent an email and got sent to this new link (not sure if it's launched) which I believe covers the entire Cedar stack rather than anything particular to NodeJS, it pings a provided URL.
That said, I'd be delighted if Heroku would introduce a high-memory dyno. I've been working on something for the past few days where their soft'ish 512MB cap has been biting me in the ass.
[1] Assuming you value your time at something around $0/hour.
edit: thanks for the link!
At its core, Heroku is just a simple unix platform; specifically, Ubuntu 10.04 LTS. </quote>
I just threw up a little
http://news.ycombinator.com/item?id=4062983
But let me try to frame it more carefully: at the time (and maybe still) a lot of providers expect you to use special APIs endemic to their platform, and you can't get the real-deal implementation or a drop-in replacement if you want to model the production environment more closely or move off the platform. Even if you get the real-deal implementation, running it may be infeasibly hairy.
Heroku very assiduously tries to avoid this, and there is a downside: we compromise with the problems in existing software that people like to use as-is, and to fix those problems we have to somehow get that software fixed, too.
I got what the author meant though, and it's not that big a deal.
512MB of RAM, 1GB of swap. Total = 1.5GB RAM. 4 CPU cores (Intel Xeon X5550 @ 2.67GHz)."
That is very interesting. So you get 200% of the CPU from a c1.medium but only 1/6 that memory? For 1/8 the price that Amazon charges? Maybe this is a the new math I keep hearing about.
Running this:
heroku run "netstat -l | grep lxc | wc -l"
...seems to imply that it's actually 100 ± 25 dynos per instance.(It's possible I could be entirely misunderstanding the netstat output, in which case someone please speak up.)