6 ms·

Why We Don't Use Heroku

71 points by whather 14y ago

deleted 14y ago
[deleted]
- whather 14y ago
  Is the site loading slow for you? Seems to be chugging along fine on my side
  - switz 14y ago
    Yeah, I apologize. Ghostery[0] appears to be breaking the page. [0] http://ghostery.com http://ghostery.com
    - jlgreco 14y ago
      Looks like it is just broken now. (no ghostery installed in this browser)
    - ratherbefuddled 14y ago
      I can't open it in Chrome (custom privacy settings & extensions) or either of FF or IE10 both of which are pretty clean with OOTB settings.
  - bullfightonmars 14y ago
    it's back up!
ryanong 14y ago
I like heroku, I like metal more. But don't use chef... seriously... It is poorly tested, and lets you do way too many stupid things. Same with puppet. Check out salt stack http://docs.saltstack.com/ http://docs.saltstack.com/
- themckman 14y ago
  I'd really be interested in hearing about the stupid things puppet and chef let you do. I'm a puppet user and quite happy with it at this point. Chose it over Chef because I don't want to write Ruby anymore and like the language. Glancing at Salt Stack, I'm certainly interested right off the bat because it's python and will probably take a deeper look. Still interested in your gripes against chef/puppet, but probably more puppet.
- ceejayoz 14y ago
  Well, that's the first time I've seen Puppet and Chef criticized for being poorly tested... You say "lets you do way too many stupid things" and I hear "you can't necessarily do everything in Salt if they didn't anticipate it"...
  - ryanong 14y ago
    For context I am a ruby developer first, DevOps second. The last cluster I managed was while I was working for Pivotal Labs. Out client had 50 VMs on top of about 30 Metal servers. We used OpenVZ, Scientific Linux (because centos didn't have ipv6 firewalls, WTF?) and chef-server. We had to add a few patches to get features we wanted such as graceful shutdown and fix up the way the CLI api worked. Chef was tested, but the way the tests were implemented were done extremely poorly. When testing a class they stubbed their own internal classes. Basically what ended up happening was none of the interaction between the methods were being tested. I was amazed that this class worked at all. This happend quite a bit too. I understand that what chef is trying to do is very difficult but maybe the problem is that they are trying to do too much. I don't want my ops tool doing everything, I only want it to setup my servers and make sure that they are all the same. Groupon has a pretty good internal solution that they are trying to open source soon. They released the client a few days ago. Now if only they had some documentation and the server. https://github.com/groupon/roll https://github.com/groupon/roll
- deleted 14y ago
  [deleted]
Kaedon 14y ago
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. 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. 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.
- AznHisoka 14y ago
  I actually thought deployment was a very challenging, nightmarish thing to do. Heroku, and EngineYard are charging me an arm and a leg - of course it must be hard as hell, right? But I took the afternoon to learn how to actually deploy, and the next day, I cancelled my EngineYard account. It's not trivial, but on a scale of 1-10, it's a 3 or 4. And even if you can't afford the time/energy to learn it (ie if you're a startup and just need to launch), you can easily do "poor man's" deployment just by sshing, "git pull", "bundle exec unicorn restart" (or something like that). Deploying an app on production is almost the same as deploying on your development machine. Why give Heroku your money when you can do it yourself?
  - Kaedon 14y ago
    That's true. For me, I view redundancy as one of the values of Heroku. If you're deploying on your own, that may still require provisioning additional servers as needed, manually backing up databases periodically, etc etc. It can be a time cost beyond just deploying it once in some cases. Still, is the cost of Heroku worth it? It's an important question and a personal one for most I think. I tend to think of deployment as a challenging thing too but the more I discuss it the less I think of it as a mystery. Thank you for sharing.
- grey-area 14y ago
  To extend your analogy, if I may, Heroku is like an ORM which charges per month, and where it costs more to use relational finders. You're paying extra for each convenience and giving up some control, and this is an ongoing cost. For some people this is a great fit and they really don't want to know about this stuff, are building a demo, or working on a smaller site where you don't want to have to babysit the server and are willing to pay a little extra for that. For others who are on a tight budget, or have an ops person or willing devs who would prefer to control the server setup, heroku is not such a good idea. I think people overestimate how hard it is to get a typical stack up and running and keep it up - for a small server or vps (i.e. most startups) it's probably only a few hours a month work plus a few hours learning setup, if that. The second one you set up can be up in minutes, and it gives you greater control in the long term, plus obviously it's cheaper. If the amount you pay heroku is less than a few hours of your time, then why not use heroku? However if you grow and are spending a lot of money with them, you've probably outgrown them IMHO. I do like their service, and have tried it out, but the convenience comes at a cost, which increases rapidly the busier your site is.
peregrine 14y ago
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. That said I haven't been happy with the way things are going with Heroku and plan on looking at alternatives. 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. 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. 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. I'll probably continue to use Heroku Postgres, its been the best part of Heroku for quite sometime and only continues to get better. 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.
- bullfightonmars 14y ago
  Frankly not every team has the time money or talent for sysadmin. I work for a tiny 4 man company, and we each build apps mostly on our own. We just don't have the bandwidth for sysadmin work. Heroku relieves us of that. Sure if I was working on a single app full time with 2-3 other devs and a dev who was in love with sys-ops I would go with chef/puppet/vagrant and ec2 no question. I'm definitely with you that sometimes unexplained exceptions of failed rake tasks occur and that is a little disappointing. Most of this is ameliorated by time to deploy. But as it is, despite it's limitations, Heroku has and continues to be fantastic.
  - peregrine 14y ago
    I don't disagree with you, I just point out that I'm not happy with the direction it has been taking lately.
facebiff 14y ago
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) 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? 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.
- ghempton 14y ago
  DevOps doesn't imply constant maintenance. A basic configuration on a site with low/constant traffic will probably not require many updates. If anything, using something like Chef will make it easier to perform those updates if the need actually arises.
  - jaggederest 14y ago
    Easier than having someone else maintain it? The bar is 'If I never ssh into this box and leave this app alone for 3 years, how likely is that box to get rooted?'
    - ghempton 14y ago
      If you have left your heroku app alone for 3 years, you are definitely at risk of getting rooted: https://blog.heroku.com/archives/2013/1/11/rails_security_vulnerability https://blog.heroku.com/archives/2013/1/11/rails_security_vu...
      - jaggederest 14y ago
        Who says it's a rails app? I run a couple raw-rack apps that hum along just fine with very, very occasional updates.
bullfightonmars 14y ago
a.k.a Why our app crashes from an hour on hacker news. </sarcasm> P.S. It was back up ~5 min after I posted this.
ratherbefuddled 14y ago
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.
- ghempton 14y ago
  Seems to work for me.
  - ratherbefuddled 14y ago
    Yes, it's back now. The irony was fleeting.
auctiontheory 14y ago
Isn't this a simple build (aka invest time to learn and operate) versus buy decision?
jguimont 14y ago
Have you looked at http://cloud66.com http://cloud66.com ? Seems to be between heroku and bare bone ec2.
gfodor 14y ago
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.
encoderer 14y ago
Why WE don't use Heroku: it's f'n expensive!
steveklabnik 14y ago
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." 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. 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. (and when I tried to load the article, none of the body text loaded, I had to refresh the page...)
- ghempton 14y ago
  It also comes down to how much you value learning new technologies. I started a project in Rails 4 a few months ago and it took several hours just to get compass working again... but it was still worth it.
  - siong1987 14y ago
    Same here. Was working on a rails 4 project last weekend for fun. Ended contributing a few patches here and there.
- thibaut_barrere 14y ago
  I tracked my time when initially learning chef, and it took me ~100 hours to be comfortable with what I needed (2.5 years ago roughly if I remember well). The learning curve was fairly steep for me, but then I don't regret it, since I got to use it as a freelancer just right after on multiple gigs, and that I can now extend EngineYard recipes or think about using AWS OpsWork without much sweat. From a purely single-person building app for yourself kind of perspective though (with one or two servers), it's a deep investment IMO... People should have a look at http://ansible.cc http://ansible.cc for an apparently much lightweight alternative.
  - danso 14y ago
msmith 14y ago
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. You really shouldn't underestimate the amount of work that it takes just to keep a product running. For example, dealing with hardware & network failures, maintaining data backups, keeping up with OS-level security, & scaling up. That's a huge part of the value that Heroku provides for us.
- ghempton 14y ago
  The deployment pipeline is a small portion of it. Even capistrano can provide the same. The problems you describe are definitely real and non-trivial, but Chef helps with this. Heroku is also not a silver bullet for scaling up.
tlrobinson 14y ago
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.
- opdemand 14y ago
  If you're looking for a Heroku-like environment with buildpack compatibility, you should check out OpDemand: http://opdemand.com/ http://opdemand.com/ The application stacks are basically a collection of open-source Puppet modules that replicate a Heroku-like environment on EC2, compatible with most Cedar buildpacks (Node, Ruby, Python, Java, Clojure). Real-time logging is piped through the web console. Workflow is to push code to your GitHub repo, press deploy and your code is pulled onto the instances, Puppet policies applied, etc. Command line `opdemand deploy` is available too. It's also more than just app stacks, you can also deploy/integrate your own custom EC2 "addons" alongside your app stacks and manage them all as a unit (Redis, Mongo, PostgreSQL, custom services, whatever). There's also native support for Heroku apps via the web console which makes it easy to migrate to/from Heroku and EC2.
Perceptes 14y ago
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.
zalew 14y ago
as an alternative to relatively complex chef/puppet solutions there is also http://ansible.cc/ http://ansible.cc/ - language agnostic and push based over ssh, so no need to install stacks and run resource-wasting clients on the server.
gingerlime 14y ago
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. 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. With all of these providers I know I can switch away from in a moment's notice (if the need arises). 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.
- onemorepassword 14y ago
  I've been doing IT for over 25 years, and I can assure you there's nothing irrational about fearing vendor lock-in. I'm all in favor of using services like Heroku if you're in a very early start-up phase with less than a handful of people or for weekend side-projects, but once you start building a serious business depending on a PaaS is just as suicidal is letting your business depend on someone else's API. This invariably ends in drama.
  - dimzava 14y ago
    >> is just as suicidal is letting your business depend on someone else's API. Well, I would tend to agree with you for APIs such as LinkedIn's and Twitter's, but not sure whether this would be the case with GitHub for example. What's your view/experience on this?
    - onemorepassword 14y ago
      There's a reason I'm running full nightly mirrors of all of our private and public GitHub repositories... The same applies to services. They can end tomorrow. Well, maybe not that fast, but how fast can you shift your business to an alternative without paying a terminal penalty? We can't run without GitHub for more than a week, so we have to be able to get out in less. Same goes for AWS. Besides snapshots we run old-school backups to ensure we can recover on old-fashioned bare-metal if necessary. Using those services, great. Letting our business depend on them? Never.
codesuela 14y ago
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.
- whather 14y ago
  Maybe you don't have the default font we're using? Are you on Windows?
  - codesuela 14y ago
    yes I'm on Windows and I get to see the Nimbus Sans font. But looking as to how my comment has a rating of -2 I suppose people disagree. Honestly I didn't mean to be a dick, just hoped to provide a little constructive criticism. Here is how it looks with Win 7 Chrome: http://imgur.com/EAZ7DBk http://imgur.com/EAZ7DBk
    - whather 14y ago
      Yeah that's pretty bad. We need better support for Windows users, including IE.
bhauer 14y ago
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. That said, font-weight: 400 please.
- halcyondaze 14y ago
  AGREED. So much
aoetr 14y ago
$120/month for a server management tool? Is this a joke or what? Maybe the submitter is the author? Obviously any such tool needs not only to be free, but also open source.
dagi3d 14y ago
>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. Nothing prevents you to use your own solr(or any other server) of your own inside your application deployed in heroku if you want
senko 14y ago
A recent good alternative to Chef and Puppet is Salt. 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. 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.
Vitaly 14y ago
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 properly configure all the services to play together, with monitoring, restarts, and all.
Vitaly 14y ago
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 properly configure all the services to play together, with monitoring, restarts, and all.

71 points by whather 14y ago

deleted 14y ago

[deleted]

whather 14y ago
Is the site loading slow for you? Seems to be chugging along fine on my side
- switz 14y ago
  Yeah, I apologize. Ghostery[0] appears to be breaking the page. [0] http://ghostery.com http://ghostery.com
  - jlgreco 14y ago
    Looks like it is just broken now. (no ghostery installed in this browser)
  - ratherbefuddled 14y ago
    I can't open it in Chrome (custom privacy settings & extensions) or either of FF or IE10 both of which are pretty clean with OOTB settings.
- bullfightonmars 14y ago
  it's back up!

ryanong 14y ago

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

themckman 14y ago
I'd really be interested in hearing about the stupid things puppet and chef let you do. I'm a puppet user and quite happy with it at this point. Chose it over Chef because I don't want to write Ruby anymore and like the language. Glancing at Salt Stack, I'm certainly interested right off the bat because it's python and will probably take a deeper look. Still interested in your gripes against chef/puppet, but probably more puppet.
ceejayoz 14y ago
Well, that's the first time I've seen Puppet and Chef criticized for being poorly tested... You say "lets you do way too many stupid things" and I hear "you can't necessarily do everything in Salt if they didn't anticipate it"...
- ryanong 14y ago
  For context I am a ruby developer first, DevOps second. The last cluster I managed was while I was working for Pivotal Labs. Out client had 50 VMs on top of about 30 Metal servers. We used OpenVZ, Scientific Linux (because centos didn't have ipv6 firewalls, WTF?) and chef-server. We had to add a few patches to get features we wanted such as graceful shutdown and fix up the way the CLI api worked. Chef was tested, but the way the tests were implemented were done extremely poorly. When testing a class they stubbed their own internal classes. Basically what ended up happening was none of the interaction between the methods were being tested. I was amazed that this class worked at all. This happend quite a bit too. I understand that what chef is trying to do is very difficult but maybe the problem is that they are trying to do too much. I don't want my ops tool doing everything, I only want it to setup my servers and make sure that they are all the same. Groupon has a pretty good internal solution that they are trying to open source soon. They released the client a few days ago. Now if only they had some documentation and the server. https://github.com/groupon/roll https://github.com/groupon/roll
deleted 14y ago
[deleted]

Kaedon 14y ago

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. 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. 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.

AznHisoka 14y ago
I actually thought deployment was a very challenging, nightmarish thing to do. Heroku, and EngineYard are charging me an arm and a leg - of course it must be hard as hell, right? But I took the afternoon to learn how to actually deploy, and the next day, I cancelled my EngineYard account. It's not trivial, but on a scale of 1-10, it's a 3 or 4. And even if you can't afford the time/energy to learn it (ie if you're a startup and just need to launch), you can easily do "poor man's" deployment just by sshing, "git pull", "bundle exec unicorn restart" (or something like that). Deploying an app on production is almost the same as deploying on your development machine. Why give Heroku your money when you can do it yourself?
- Kaedon 14y ago
  That's true. For me, I view redundancy as one of the values of Heroku. If you're deploying on your own, that may still require provisioning additional servers as needed, manually backing up databases periodically, etc etc. It can be a time cost beyond just deploying it once in some cases. Still, is the cost of Heroku worth it? It's an important question and a personal one for most I think. I tend to think of deployment as a challenging thing too but the more I discuss it the less I think of it as a mystery. Thank you for sharing.
grey-area 14y ago
To extend your analogy, if I may, Heroku is like an ORM which charges per month, and where it costs more to use relational finders. You're paying extra for each convenience and giving up some control, and this is an ongoing cost. For some people this is a great fit and they really don't want to know about this stuff, are building a demo, or working on a smaller site where you don't want to have to babysit the server and are willing to pay a little extra for that. For others who are on a tight budget, or have an ops person or willing devs who would prefer to control the server setup, heroku is not such a good idea. I think people overestimate how hard it is to get a typical stack up and running and keep it up - for a small server or vps (i.e. most startups) it's probably only a few hours a month work plus a few hours learning setup, if that. The second one you set up can be up in minutes, and it gives you greater control in the long term, plus obviously it's cheaper. If the amount you pay heroku is less than a few hours of your time, then why not use heroku? However if you grow and are spending a lot of money with them, you've probably outgrown them IMHO. I do like their service, and have tried it out, but the convenience comes at a cost, which increases rapidly the busier your site is.

peregrine 14y ago

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. That said I haven't been happy with the way things are going with Heroku and plan on looking at alternatives. 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. 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. 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. I'll probably continue to use Heroku Postgres, its been the best part of Heroku for quite sometime and only continues to get better. 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.

bullfightonmars 14y ago
Frankly not every team has the time money or talent for sysadmin. I work for a tiny 4 man company, and we each build apps mostly on our own. We just don't have the bandwidth for sysadmin work. Heroku relieves us of that. Sure if I was working on a single app full time with 2-3 other devs and a dev who was in love with sys-ops I would go with chef/puppet/vagrant and ec2 no question. I'm definitely with you that sometimes unexplained exceptions of failed rake tasks occur and that is a little disappointing. Most of this is ameliorated by time to deploy. But as it is, despite it's limitations, Heroku has and continues to be fantastic.
- peregrine 14y ago
  I don't disagree with you, I just point out that I'm not happy with the direction it has been taking lately.

facebiff 14y ago

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) 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? 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.

ghempton 14y ago
DevOps doesn't imply constant maintenance. A basic configuration on a site with low/constant traffic will probably not require many updates. If anything, using something like Chef will make it easier to perform those updates if the need actually arises.
- jaggederest 14y ago
  Easier than having someone else maintain it? The bar is 'If I never ssh into this box and leave this app alone for 3 years, how likely is that box to get rooted?'
  - ghempton 14y ago
    If you have left your heroku app alone for 3 years, you are definitely at risk of getting rooted: https://blog.heroku.com/archives/2013/1/11/rails_security_vulnerability https://blog.heroku.com/archives/2013/1/11/rails_security_vu...
    - jaggederest 14y ago
      Who says it's a rails app? I run a couple raw-rack apps that hum along just fine with very, very occasional updates.

bullfightonmars 14y ago

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

ratherbefuddled 14y ago

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.

ghempton 14y ago
Seems to work for me.
- ratherbefuddled 14y ago
  Yes, it's back now. The irony was fleeting.

auctiontheory 14y ago

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

jguimont 14y ago

Have you looked at http://cloud66.com http://cloud66.com ? Seems to be between heroku and bare bone ec2.

gfodor 14y ago

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.

encoderer 14y ago

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

steveklabnik 14y ago

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." 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. 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. (and when I tried to load the article, none of the body text loaded, I had to refresh the page...)

ghempton 14y ago
It also comes down to how much you value learning new technologies. I started a project in Rails 4 a few months ago and it took several hours just to get compass working again... but it was still worth it.
- siong1987 14y ago
  Same here. Was working on a rails 4 project last weekend for fun. Ended contributing a few patches here and there.
thibaut_barrere 14y ago
I tracked my time when initially learning chef, and it took me ~100 hours to be comfortable with what I needed (2.5 years ago roughly if I remember well). The learning curve was fairly steep for me, but then I don't regret it, since I got to use it as a freelancer just right after on multiple gigs, and that I can now extend EngineYard recipes or think about using AWS OpsWork without much sweat. From a purely single-person building app for yourself kind of perspective though (with one or two servers), it's a deep investment IMO... People should have a look at http://ansible.cc http://ansible.cc for an apparently much lightweight alternative.
- danso 14y ago

msmith 14y ago

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. You really shouldn't underestimate the amount of work that it takes just to keep a product running. For example, dealing with hardware & network failures, maintaining data backups, keeping up with OS-level security, & scaling up. That's a huge part of the value that Heroku provides for us.

ghempton 14y ago
The deployment pipeline is a small portion of it. Even capistrano can provide the same. The problems you describe are definitely real and non-trivial, but Chef helps with this. Heroku is also not a silver bullet for scaling up.

tlrobinson 14y ago

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.

opdemand 14y ago
If you're looking for a Heroku-like environment with buildpack compatibility, you should check out OpDemand: http://opdemand.com/ http://opdemand.com/ The application stacks are basically a collection of open-source Puppet modules that replicate a Heroku-like environment on EC2, compatible with most Cedar buildpacks (Node, Ruby, Python, Java, Clojure). Real-time logging is piped through the web console. Workflow is to push code to your GitHub repo, press deploy and your code is pulled onto the instances, Puppet policies applied, etc. Command line `opdemand deploy` is available too. It's also more than just app stacks, you can also deploy/integrate your own custom EC2 "addons" alongside your app stacks and manage them all as a unit (Redis, Mongo, PostgreSQL, custom services, whatever). There's also native support for Heroku apps via the web console which makes it easy to migrate to/from Heroku and EC2.

Perceptes 14y ago

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.

zalew 14y ago

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

gingerlime 14y ago

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. 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. With all of these providers I know I can switch away from in a moment's notice (if the need arises). 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.

onemorepassword 14y ago
I've been doing IT for over 25 years, and I can assure you there's nothing irrational about fearing vendor lock-in. I'm all in favor of using services like Heroku if you're in a very early start-up phase with less than a handful of people or for weekend side-projects, but once you start building a serious business depending on a PaaS is just as suicidal is letting your business depend on someone else's API. This invariably ends in drama.
- dimzava 14y ago
  >> is just as suicidal is letting your business depend on someone else's API. Well, I would tend to agree with you for APIs such as LinkedIn's and Twitter's, but not sure whether this would be the case with GitHub for example. What's your view/experience on this?
  - onemorepassword 14y ago
    There's a reason I'm running full nightly mirrors of all of our private and public GitHub repositories... The same applies to services. They can end tomorrow. Well, maybe not that fast, but how fast can you shift your business to an alternative without paying a terminal penalty? We can't run without GitHub for more than a week, so we have to be able to get out in less. Same goes for AWS. Besides snapshots we run old-school backups to ensure we can recover on old-fashioned bare-metal if necessary. Using those services, great. Letting our business depend on them? Never.

codesuela 14y ago

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.

whather 14y ago
Maybe you don't have the default font we're using? Are you on Windows?
- codesuela 14y ago
  yes I'm on Windows and I get to see the Nimbus Sans font. But looking as to how my comment has a rating of -2 I suppose people disagree. Honestly I didn't mean to be a dick, just hoped to provide a little constructive criticism. Here is how it looks with Win 7 Chrome: http://imgur.com/EAZ7DBk http://imgur.com/EAZ7DBk
  - whather 14y ago
    Yeah that's pretty bad. We need better support for Windows users, including IE.

bhauer 14y ago

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. That said, font-weight: 400 please.

halcyondaze 14y ago
AGREED. So much

aoetr 14y ago

$120/month for a server management tool? Is this a joke or what? Maybe the submitter is the author? Obviously any such tool needs not only to be free, but also open source.

dagi3d 14y ago

>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. Nothing prevents you to use your own solr(or any other server) of your own inside your application deployed in heroku if you want

senko 14y ago

A recent good alternative to Chef and Puppet is Salt. 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. 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.

Vitaly 14y ago

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 properly configure all the services to play together, with monitoring, restarts, and all.

Vitaly 14y ago