Devops?

Last Tuesday, The Unicorn Project was finally launched. This followup to The Phoenix Project doesn’t disappoint, and is as much a must read as its predecessor.

There are a couple of things I’d like to mention. The first thing is that the author Gene Kim has really fallen in love with Clojure and applies the principles of Clojure to the larger organization. As a side note, I’m wondering if The Unicorn Project will spawn a new interest in Clojure.

The second thing, and it’s more related to me, is the term “devops”. In my 25 years of working, I’ve always identified as a developer. Sure, I’ve configured my boxes, I know my way around bash, and I could probably run a small production enviroment, but I’ve never considered myself a true ops person. But I don’t reckognize myself in the stereotypical developer as he is portrayed in these two books, and in the few jobs I’ve had where I have not been allowed to take responsability for my own code in production has been the most frustrating. In fact, working in places where we’ve been forced to “throw code over the fence” to ops have been the worst places I worked.

So, I guess what I’m getting at is that to me the term “devops” is a bit too much focussed on the ops part, and that setting up CI servers, monitoring, and having access to logs is just all part of development.

Spinning up new servers in AWS, configuring network zones, and all that stuff is better left to the pros in ops :) Especially when it’s all done in YAML