Why We Don't Use Heroku
grouptalent.com
grouptalent.com
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.
If anything, using something like Chef will make it easier to perform those updates if the need actually arises.
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?'
The thing you need to test then deploy are upgrades to your language and framework/app, and those present exactly the same problem on heroku or on say a vps. You can't just redeploy your app without testing on a new config, and deploys to heroku are no easier or harder than deploys to your own server once set up.
What heroku buys you is not having to deal with updating the web server and database, as they'll deal with all of that, but I wasn't aware that they provide a fully managed service like say wordpress.com, and I don't see how they could for custom apps.
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...)
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.
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 for an apparently much lightweight alternative.
As an example let's say you want to install MongoDB on a new Ubuntu machine, you have the following dependencies in approximate order;
* Add MongoDB Apt Repo to apt list. * Add MongoDB repository key. * apt-get update. * apt-get install mongodb. * Configure /etc/mongodb.conf to your liking. * Restart mongodb.
Depending on how you implement it CM will allow you to make the process cookie cutter.
Want a new test environment? Spin one up and run your CM against the servers. Want to try that hot new cloud provider? Ditto.
I think it's worth the investment unless you're just doing apps that have a very short shelf life (e.g. marketing apps that live for no longer than a few months).
Kind Regards, Nathan
This is key. When I first got into using Chef, I assumed things would be no problem because all the services I used already had community recipes.
The community recipes are often wrong, don't work correctly on "clean" first-time installs and have a lot of baked in assumptions about the config and modules to use.
Clone these recipes into your repo, you will be modifying them. Blindly relying on the built in functionality to pull in and update the community repos will lead to pain.
Chef is a powerful tool, but it is also evolving rapidly and requires careful attention and testing.
- Use chef-solo. (Edit: and use knife-solo to initially bootstrap Chef onto the machine.)
- Your first time, forget about cookbooks and just write a single site-cookbooks/myapp/recipes/default.rb. Use that to list packages, shell code, whatever.
This will get you started, and you can learn/improve from there.
Your second time, use librarian-chef, and as someone else said, freely clone cookbooks so you can adapt them to your needs.
If it's something that nobody on your team can tackle you can easily end up with completely disparate development environments (with devs running different ruby versions, app servers, even databases!) when there's no well documented system for setting up environments.
Heroku makes it dead simple to deploy and add services, but if your team can't manage to do that for local development anyway, things can end up in a really bad state.
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.
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?
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.
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.
Thanks for the amendment to the comparison. In a sense, an ORM can still have ongoing "costs" as it tends to run a little slower and require more processing, so it might require additional hardware eventually as the scale goes up. Maybe I'm belaboring the analogy too much at that point.
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.
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.
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
Still interested in your gripes against chef/puppet, but probably more puppet.
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"...
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.
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.
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.
That said,
font-weight: 400
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.
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.
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.
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?
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.
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.
Nothing prevents you to use your own solr(or any other server) of your own inside your application deployed in heroku if you want
P.S. It was back up ~5 min after I posted this.
it's f'n expensive!
Here is how it looks with Win 7 Chrome: http://imgur.com/EAZ7DBk