Why We Don't Use Heroku

I think a lot of folks who argue "you should learn how to be a DevOp" are working on a single product that's always in active development. And they tend to see the problem through that lens. (maybe I'm wrong about about the OP, but that's my sense)<p>If you're a consultant or work on multiple projects, the equation changes significantly. What if you're building a web app for university, for example, with a fixed budget, and once it's feature complete, it goes into "maintenance mode" with very few updates for the next couple years?<p>Do you want to continually be in charge of DevOps for something that isn't actively being developed for several years, having to ramp back up when issue arises every three months? Is that the best value for the client organization? Or would you rather outsource that? I'd usually choose the latter, and in my experience, it's been a better value for clients.

I am simultaneously kinda embarassed and also not that I've never actually been able to get Chef to actually work. I've tried two or three times, put two or three hours into it each time, and then said "fuck it" and either did it by hand or "git push heroku."<p>My time is more valuable than manually managing servers. It's an incredibly basic tradeoff: some people are more price-sensitive, others are more time-sensitive.<p>In my case, if I end up working on an app that reaches the scale where Heroku isn't appropriate (for cost or 'omg I need metal' reasons) again, I'm sure there will be someone else on my team who lives and breathes ops. I can manage, but I'd rather be doing almost anything else.<p>(and when I tried to load the article, none of the body text loaded, I had to refresh the page...)

To me, the article boils down to an argument that says "You should learn how to be a DevOp. It's not that bad." I don't think that's a trivial thing to pick up. I think it's important to develop some of these skills but I wouldn't describe it as easy.<p>I think the key argument for Heroku is that it enables you to delay (sometimes indefinitely) learning the skills required to deploy a production application and managing it. In some cases, such as security, it can be a real bear to keep up with the latest developments in addition to managing the application itself.<p>Ultimately, I view Heroku as similar to an ORM. With an ORM, it will get you most of the way most of the time, but there's some instances where it starts to make sense to dig into the raw SQL below it and get the performance you want.

OP has a good point about deployment. DevOps tools have made huge strides in the last few years and it's feasible to build something that approaches the convenience of Heroku's fully-managed deployment pipeline, but that's not the only value that a PaaS provides.<p>You really shouldn't underestimate the amount of work that it takes just to keep a product running. For example, dealing with hardware &#38; network failures, maintaining data backups, keeping up with OS-level security, &#38; scaling up. That's a huge part of the value that Heroku provides for us.

There's a sad irony in an article presumably advocating running your own deployment infrastructure that spirals into a miserable re-direct loop when you try to load it.

I like heroku, I like metal more.<p>But don't use chef... seriously... It is poorly tested, and lets you do way too many stupid things. Same with puppet.<p>Check out salt stack<p><a href="http://docs.saltstack.com/" rel="nofollow">http://docs.saltstack.com/</a>

as an alternative to relatively complex chef/puppet solutions there is also <a href="http://ansible.cc/" rel="nofollow">http://ansible.cc/</a> - language agnostic and push based over ssh, so no need to install stacks and run resource-wasting clients on the server.

We use Heroku a ton with many of our clients because its quicker, cheaper, and easier to get something setup that is "good enough" for most projects. Informing our clients of the pros and cons is part of the job. Most agree that the pro's out weight the cons initially and we tend to agree. We also use it for many of our own projects and have been happy for a while and will continue to use it.<p>That said I haven't been happy with the way things are going with Heroku and plan on looking at alternatives.<p>First it was the Heroku toolbelt that wants to install its own git and foreman, tried the standalone and it just fails before installing. Seriously don't understand this decision, I get that its easier for a new person to get started and that they are moving away from ruby only.<p>The fact that cedar still doesn't support websockets, we gave up having a seamless varnish cache and nginx in front of our machines in hopes of more options. We got more languages but still limited to basic web technologies.<p>Support is good but can be super shotty, we've had times where our scheduled tasks fail with cryptic error messages. Simple things like a Rake task that has been running for months just starts failing. We send them the trace and then we hear back "that shouldn't happen" then nothing else. Who knows when it will fail again or why.<p>I'll probably continue to use Heroku Postgres, its been the best part of Heroku for quite sometime and only continues to get better.<p>I think its time to look into chef/puppet/vagrant and ec2 or maybe dotcloud. Not to mention I don't want to be stuck with Heroku when Salesforce gets sick of them.

I generally agree with the article. We deploy apps to EC2 instances and physical servers. It seems fairly effortless these days, so I don't get the appeal of Heroku, especially considering the cost and price/performance ratio.<p>That said,<p><pre><code> font-weight: 400 </code></pre> please.

What I'd really like is a collection of Chef recipes to replicate a Heroku-like environment, complete with git deployment, buildpack compatibility, logging, etc.

for me, one of the most important aspects are vendor lock-in. Maybe it's irrational, but I don't like to depend on a single vendor, however good it might be.<p>I use Linode and AWS, and used Rackspace and probably half a dozen smaller VPS providers in the past. Most of them I ditched, some I still use occasionally, some I might use more in future.<p>With all of these providers I know I can switch away from in a moment's notice (if the need arises).<p>If PaaS became standard / compatible across vendors, I would definitely consider Heroku, Engine Yard or whoever else in this space. Until then, I'd rather have this sense of freedom, even if irrational.

A recent good alternative to Chef and Puppet is Salt.<p>I first had a look at it about a year ago, when they just introduced state management, had lousy docs and rathe small community. It's massively improved in the past year, the docs are plentiful and useful, and the community is growing.<p>It took me around a day to get started and prepare a masterless (ala chef-solo) config for a typical django setup we use (nginx, postgresql, standard django/pil deps, virtualenv), and a few less-standard things (node, less, apache fop) to try my hand at something a bit more challenging than a trivial setup. Definitely an easier learning curve than Chef, IMHO. There's also a Salt module for Vagrant.

This article does not present a good argument against using Heroku. Yes, you can learn to do for yourself what any given service provides for you. That doesn't mean it is necessarily something that interests you or is worth your time.

Isn't this a simple build (aka invest time to learn and operate) versus buy decision?

&#62;Need a production solr instance? The Heroku way is to use a 3rd party add-on such as websolr. This means creating yet another account to keep track of, adding another bill to your credit card statement, dealing with one more mediocre web interface, and creating an even larger divide between your development and production environments.<p>Nothing prevents you to use your own solr(or any other server) of your own inside your application deployed in heroku if you want

What a load of crap! We've been setting up our ec2 slices with puppet for a while, and we literally saved tens of IT hours after moving most of our new client projects to heroku. The one constant thing about maintaining configurations is the never ending change. Versions change, requirements change, etc. Not to mantion it's really not easy to <i>properly</i> configure all the services to play together, with monitoring, restarts, and all.

Have you looked at <a href="http://cloud66.com" rel="nofollow">http://cloud66.com</a> ? Seems to be between heroku and bare bone ec2.

I've been using the new AWS OpsWorks service for my latest project. It's great. You still have to learn chef if you want to write custom recipes, which I did, but overall for just deploying stuff to the cloud it's hard to imagine Heroku coming out on top when you really back out the costs.

a.k.a Why our app crashes from an hour on hacker news. &#60;/sarcasm&#62;<p>P.S. It was back up ~5 min after I posted this.

Why WE don't use Heroku:<p>it's f'n expensive!

Im sorry for the OT but looking as to how a developer/designer working at/on Grouptalent could read this: I really dislike the typography on the site, the font is way to thin, small and low contrast hence I had a hard time reading it, even when zoomed. It made me only skim this article even though it seems interesting.