Git Push Heroku Master: Now 40% Faster
blog.heroku.com
blog.heroku.com
I remember the pain of deploying Huckberry [2] on Rails 3 a couple of years ago. Each deploy took ~6 minutes, and it'd drive us crazy. A whole lot of "Compiling!"-type [3] moments. (Back then, the Asset Pipeline compiled all of your assets twice: once with the real filename, once with the digest-filename: 'filename--f74c093df554be59d45d3c87920eba1f.js'. As you can imagine, this was quite slow.)
This is one of the reasons I really love Heroku as a development platform. We're a 4-person shop—we can't spin off a resource to spend 2 weeks speeding up our deployment process. But with Heroku, we wake up one morning, and our processes our 40% faster. It's fantastic.
[1] https://github.com/heroku/heroku-buildpack-ruby/pull/96
[2] https://secure.huckberry.com/
[edit: formatting]
My biggest problem right now in term of deployment time is to sync with amazon for the assets. It literally takes 5 minutes for a small website..
[1] http://guides.rubyonrails.org/configuring.html#rails-general...
[1]: https://devcenter.heroku.com/articles/using-amazon-cloudfron...
I've been doing it, but got some uncomfortable knee-jerk reactions from other developers, e.g. "But you should NEVER serve static assets directly!!!".
...but it's only served once!
As with music, painting, and architecture, any development-related NEVERS require that we understand the why, so we can know when to break the rule.
(Using mixed http/https was not an option.)
This is not entirely clear from the Heroku docs, I'll ping the maintainer for an update.
This is a huge cache boost in Rails because you don't have to cache your pages twice (once for HTTP once for HTTPs.)
Upworthy, you've broken me.
I basically never think about deploying assets. It nearly always just works.
Make sure you have your cache store set to dalli (production.rb)
config.assets.cache_store = :dalli_storeSeriously people, DIY, it isn't hard. Let the "180 websites in 180 days" [1] girl use Heroku, she's giddy to get anything working. Real hackers should not be satisfied with lock-in, ridiculous prices that correlate with the ineptitude of the user-base, potential downtime on top of AWS normal downtime (what Heroku uses in the background.) If you're serious about your business, Heroku makes no sense at all, lest you be a non-technical cofounder, and it makes you feel 'safe.'
As to the point of DIY not being hard, getting something working may not be hard. But handling fault tolerance, logging, backup, downtime, etc. is non-trivial. And as mentioned in other comments, this takes time. Even if you're a l33t ub3r h4x0r, that will always be true. For some teams, the DIY investment will make sense, others would rather spend their time building features than dealing with ops.
Heroku is not a replacement for a sys admin. In fact, you get less with Heroku because you can't even access the systems running your code.
$35 for a measly 2 dyno application, and another $50 for a production postgresql database.
Our use case is REALLY simple, we aren't building some freak sideshow redis golang nonblocking nodejs mongodb ravendb nqueue sync rabbit hyperthreaded monster. We're just building a Rails 4 site, with a PostgreSQL database backend. That's ENOUGH for our use cases. For what we need it's infinitely cheaper to just rent a Linode/DigitalOcean server, use something like Chef to spin up the services we need and voila. We probably won't have to touch the servers for a very long time. Again: We're doing simple things - CRUD basically.
I love Heroku for it's simple usage but it's just too darn expensive for us.
What is your alternative that will give you as useful a deploy environment (for whatever kinds of 'useful' you need, everyone has different needs)? How much will it cost, in direct costs or your time? Do you or someone on your team have the expertise and time to provide and maintain such a deploy environment?
If there's something that is good enough but cheaper, than by all means use it.
The reason heroku is so succesful despite not being cheap is that for many people, there isn't. Which means while it may not be cheap, for many people it's a pretty darn good value.
To be fair, all of that takes time (and therefore, $$). For side projects it's probably not a big deal--the learning process itself is valuable--but if you're actually talking hard sums, Heroku isn't always as expensive as it seems.
You'll need to manage:
- Chef cookbooks and testing (this is a big one) - Deployment (using Chef standalone? Fabric? Git server + post-receive hooks?) - Backups (are you pushing WAL logs to S3? Have you tested recovery?) - System resourcing (didn't write a logrotate config for that custom service? Out of disk space?) - Monitoring (Pingdom, New Relic, etc.) in case it does go down? - etc, etc.
It all adds up. For my own side project I went down the DO + Salt + Packer path, but my day job isn't as a dev/programmer so I had to spend a little time learning the idiosyncrasies of Salt and Upstart. These skills are valuable (for the next project down the line), but if I was part of a small team with a deadline then taking "detours" isn't always an option.
That said, I'm pushing my developers to use Middleman [2] for mostly-static sites these days. No moving parts means nothing can go wrong, and we host on GitHub pages for free. Not sure if this fits your use case.
I'm a bit of a Rails performance nut, feel free to ping me at nj@thirdprestige.com if you'd like to ask me more specific questions.
Until somethings fucks up. If you are on Heroku they will handle DB, routing and server problems. On Linode you have to deal with that yourself or hire a sysadmin.