Curiosity is dead – A take on Heroku
When Heroku launched in 2007 it stirred the web deployment industry in a way that I have never seen before. The worry free, scalable and easy to deploy solution created waves in the Rails community and got noticed in almost every tech circle.
The “black box” approach to deployment was very controversial and there is still a fair amount of criticism for the system since most people who are deploying to it don’t understand what is going on under the hood. That said the deployment system of just “git push heroku master” makes it so easy for a developer to deploy an app that it’s hard to blame anyone for using it.
After multiple (failed) attempts in the past, I decided that I would make Heroku work this time and, after a few hurdles, I was finally able to deploy a small Rails app to Heroku. Once everything is in place re deploying is so easy and quick that I started to wonder why I had delayed using it.
Basically any developer can outsource the operations department at a very low cost while he can focus on creating the code. David Ricardo’s theory applied perfectly. You can even outsource other services, like DBs, search or emailing, as plugins.
That said when you deploy to Heroku there is a feeling of using an appliance that you don’t have when you deploy to a regular server. Everything is out of your control, if you had to fix something you wouldn’t even know where to start. It has been over 10 years for me since I started placing web applications online and even though I am not an operations expert I know my way around a server. On Heroku there is nothing to do, no settings to tweak, no man pages to read. There are probably some optimizations you could do but most likely people just add more dynos to their configuration and that is it.
My main concern though is not that, but the fact that you have to work within the Heroku ecosystem. Do you want Mongo? Use mongohq or mongolab (and pay extra). Do you want to compile it from source? Good Luck! Do you have your own fork of a project? Deploy it somewhere else, this is an appliance.
So, what is the problem? you may ask. The problem is that by limiting the exposure to the underlying systems and reducing friction on deployments, developers don’t feel the need to improve the back-end projects. Why would I work on the Redis core if I can’t even deploy my changes?.
The worst part is this change is a piece of a whole movement to become an industry of abstractions. I would bet that most of young developers don’t even know how to assemble a server or how the network is connected to them.
Curiosity outside our comfort zone is dead. If you are a developer you should try to learn as much of the whole ecosystem as you can. That makes you a better engineer. If after playing around with multiple systems you still want to deploy to the black box, great. The good thing is that it won’t be a black box anymore.
Here is a relevant TED Talk:
