The term “DevOps” has been floating around for a few years now.  It’s gone from relative obscurity to being “that thing” that organizations need to survive and thrive. 

What is DevOps?

At it’s heart, DevOps is about culture and process.  The DevOps mindset draws from manufacturing thinkers like Demming and Goldratt, as well as modern day thought leaders like Allspaw and Humble.

The focus of DevOps culturally is to bring IT in line with the business objectives.  This is accomplished by defining and controlling the flow of work, shortening feedback loops (getting new software into production sooner), and continually experimenting and improving.

These cultural objectives are backed by technological trends.  Standardizing workflows (automation, checklists, kanban boards)  provides IT a way to provide a baseline of service, as well as a platform for improving the quality of that service in an incremental fashion.  Building and surfacing dashboards provide the business with more immediate feedback as to the state of the IT systems, as well as uncovering potential bottlenecks or unaccounted for issues.  Leveraging version control systems for all aspects of environmental configuration make customizing or changing the environment a safer, more stable operation.

There are a lot of great books (more posts to come on those..), web sites (like IT Revolution), and podcasts (like DevOps Cafe and The Ship Show).  More content, thoughts, and applications are coming out regularly in a variety of media sources.

That sounds good.. Why am I upset?

I am totally on-board with the DevOps philosophy.  I love Goldratt’s “Five Focusing Steps” and the Gene Kim’s “Three Ways” and I think they are integral to how the IT field progresses in this day and age where downtime is not tolerated, new features must be surfaced regularly, and budgets and personnel are harder and harder to come by.

To me, a lot of this stuff sounded like things I read and studied (Peopleware, Release It!,  and The Practice of System and Network Administration,   amongst others) as I learned to be a sysadmin.  I’m glad the DevOps movement has garnered attention for these concepts and the tooling around them, but I’m somewhat saddened that we needed a movement to do so.  I thought it was just part of being a professional sysadmin that we talk to developers, find common ground, and work to streamline processes.  I thought it was just part of being a professional to want to understand the business processes that rely on our IT systems and how we can continually improve the service.  But it was obviously a big enough issue that a counter culture had to rise up and show the world that there is a better way.

But that’s not what really has me steamed…

What’s really got me worked up is the absolute failure of people who claim to support DevOps to have a clue as to what it actually is.  I will have to hang up if I’m on another conference call and hear something to the effect of “I’ve got to hire me a DevOps”, or “here’s some tooling for the DevOps”.  DevOps is NOT a guy, a team, or job description (well, maybe part of a job description).  A person can work in a DevOps environment, embrace DevOps principals and tool chains, but is not this mythical “DevOps” person.

DevOps has become a buzzword band-aid.  

  • Are your teams in a rut?  Re-org and call them DevOps teams.
  • Need to hire new personnel?  Post an add for a DevOps guy.
  • Want a new reason for CIO’s to buy your product?  Advertise them as tooling a DevOps would use.

When I hear someone say “a DevOps”, what I’m really picturing that person meaning is a person performing developer and IT operations work.  Those people exist, but to say that they are “a DevOps” totally ignores the core cultural and process components of DevOps, which is the existence for the movement.  The other scenario is when the term “DevOps” is applied to a cross-functional team of developers and operations staff.  While this can be a good thing, it is not necessarily a DevOps team.  

By focusing the term on a role the person or team is playing, the cultural and process components are ignored.  Those are the true value in the DevOps movement and should not, no wait, cannot be ignored.  Just having a person who performs the roles of a IT operations person and a software developer or having a cross-functional developer/operations team does not guaranty that you will have an automated build and deploy process, nor will it mean the IT is focused on the business, nor continually striving for improvement.  That is the real value of DevOps. 

In summary, if you hear a person say, “I need to hire me one of those DevOps guys,” or “Let’s set up a DevOps team,” and there is no organizational willpower to change operating practices and culture, smack them.  Well, don’t smack them, that could cause all sort of legal issues, but think about smacking them, smile, listen politely, and start looking for another place to work, or another vendor to buy from, or new friends, as that person really hasn’t done their homework and is just looking for a quick fix by applying buzzwords.

In summary of the summary -

To all those using and abusing the term DevOps, words mean things.  Research what you are talking about before opening your trap (creating your marketing material, etc..).  Stop making my life harder by confusing things for people.  DevOps can help people make their environments better, but only if they know what it really is.