Preamble
I started this week sorting out some widgets for a couple code bases that I am looking after at work. One's a legacy CMS app (Ruby 1.8.7/Rails 2.x) that's extremely mature and the other is a 'Refinery based CMS' that I put together myself.
"Wait, what?", I hear you ask. Refinery is a CMS. Well, mine's an effort to bake in features that most of our clients expect, and these 'engines' (extensions in Refinery parlance) are aspects I've added. Of course, I digress.
Yes, the start to my week was a whole lot of yak-shaving tedious work. I wasn't creating anything new. There was very little 'architectural' design on my part. The bulk of this widget related work ultimately boiled down to faffling with markup/CSS.
Looking to maintain my sanity, I found myself taking a look at a tool a colleague had pinged me about — Terraform.
At work, provisioning and deployment are, for the most part, handled by an ageing Chef server (10.x) and about 20 nodes running close to 80 sites/apps. My title is 'Senior Rails Developer' and it's already rather apparent that I do a fair bit of 'DevOps' in my role.
'How 'DevOps' is Killing the Developer' by Jeff Knupp
Having set the stage, I urge you to read a blog post by Jeff Knupp, where he details reasoning for his loathing of DevOps and the notion of the "full-stack" developer.
This fact: not every company is a start-up, though it appears that every company must act as though they were.
He couldn't have hit the nail on the proverbial head any better. I don't work for a start up, but a small(ish) design firm; my daily interactions involve at most seven other people where I'd be coding features usually for a minimum of 5-6 hours per day. And when I'm not coding, it's usually attending to bug fixes, or putting on my 'Chef' apron and doing some infrastructure management.
Jeff's post takes things to the extreme where he's asserting that DevOps means that we don't get much time to 'develop', but we've found a decent balance and that's not entirely the case.
As long as our Chef stack remains resilient to any failure, our productivity continues. Therefore, we are highly reliant upon safeguards to prevent such a catastrophe. Therefore, at this juncture it comes down to 'number of bodies' problem, and I am starting to agree with Jeff to a certain degree.
Quick, what are the benefits and drawbacks of the following such systems: Puppet, Chef, Salt, Ansible, Vagrant, Docker. Now implement your deployment solution! Did you even realize which systems had no business being in that list?
Recall my mentioning Terraform? Well, it turns out there's been a boom in the ALM (Application Lifecycle Management) space where Terraform is one the more recent tools launched (sometime within the last two-weeks).
Another important tool of note is Docker which recently crossed v1.0 (yay, for production use!) allowing for "immutable infrastructure" and testing when coupled with Vagrant.
Packer is another tool by HashiCorp (Mitchell Hashimoto, author of Vagrant, Terraform, et al.) that has piqued my interest as of late.
…and I haven't even gotten into more complicated setups such as Chef/Puppet/Ansible.
Conclusion
There are lot of tools out there and various means for skinning the same cat. One could argue there's a steep learning curve in the DevOps space, and guess what, they are right!
I enjoy specialising in DevOps as this ties in quite nicely with my passion for Rails. Like any speciality, they need to be embraced and honed to perfection. The 'perfection' that I seek at this stage is exposure and experience with various tools, those that'll fit various use-cases that'll meet my clients needs as well as my personal interests.
A developer can either be productive or do DevOps; whenever one's focussing on the latter, they are lacking efficiency in the former. I beg to ask the question, "Is that such a bad thing?"
The answer comes down to the way you work, the kind of team you have, and the number of bodies you have to throw at a given a problem.
The "full-stack" developer mindset has its benefits; someone who's flexible and not afraid of getting their hands dirty, acquiring knowledge that's outside their primary domain. It does not necessarily translate to 'Jack of all trades, master of none'. In my experience, any knowledge I've gained in another domain, has always been useful.
Stay tuned for my followup post on how these tools can be leveraged and pointers from my personal hacking sessions.