DevOps according to me

We've all read definitions from countless sources, gone to Wiki, talked to peers and industry thought leaders...we all have an opinion formed based on how much angle our daily lense lets us see. Its my turn now. Let me explain what I think DevOps is

Posted by Miguel Pereira on Mon 15 August 2016

Why do we need another post defining DevOps?

To be honest, you probaly don't need one. But I did. I needed to discipline my writing and finally jot down the reasons why I am no longer just a DBA, a release engineer, or a software engineer.

The catalyst

I had recently read an article by Ken Mugrage, entitled My New Definition of Devops. It (mostly jokingly) provoked this reaction on my part...

Frist things first. Its a very good article. Very thoughtful and thought provoking in a very condensed package. I loved it for what it triggered, not so much for its conclussions.

Ken's opening & closing statements gave me pause...

I heard the term DevOps Engineer one two many times in the past few days and felt like I needed a better way to explain what it is (and isn’t).

A job title of “culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system engineer” would be pretty silly. I believe “DevOps Engineer” is just as bad.

They struck a dissonant chord in me. I consider myself an engineer, regardless of function; i.e. sales egineer, QA engineer, software engineer, release engineer.

Wouldn't it be just as silly to say, for instance "person who talks to prospective clients and takes down objection walls ultimately facilitating the sales process egineer" or how about "someone who puts together a discordant collection of unit, regression and integration tests together using multitude of tools to ensure quality products are released egineer."

Point being, if we trully dissect Ken's argument, he is ultimately playing with semantics. He is not wrong, but neither should we raise our pitchforks looking for "those" engineers.

Why a DevOps Engineer?

But How can we engineer something that is intended to be a cultural fingerprint, not a trade or techne?

Are there not intrinsic crafts that actually do make up the fabric of the DevOps cultural movement itself? Well...let's see:

  • Build sound infrastructure
    • You must be familiar writting code or codifying your infrastructure design, documenting it and ensuring its continually improved upon using software design and agile principles
  • Facilitate the delivery of code from development to production
    • You must be at ease automating and leveraging automation frameworks and overcoming the challenge of adapting tools and workflows to your needs_
  • Ensure only quality working code gets delivered
    • You must be familiar with unit testing, regression & integration principles and practices to ensure quality code at all stages and all layers
  • Monitor and measure how systems impact the user experience
    • You must be able to determine what and how to best measure the behavior and performance of the product being delivered at every layer
  • Enable and amplify the feedback loop between user and all other groups
    • You must have the ability to convey and communicate, continually, the lessons and information that is gleened from monitoring and measuring the system

I attempt to deliver on the above 5 points every day. More often than not, I am unsuccessful -but I keep trying.

A job title of “culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system engineer”

All of a sudden, the above doesn't sound so silly anymore. But I do prefer the more compact "DevOps Engineer" version.

At the end of the day

I really like these 4 bullet points (ain't life grand when you can sum things up into 3 or 4 points?)

Spike Morelli was quoted as saying that anyone attempting to slap the term DevOps on their profile, should ensure to have the following qualifications at a minimum:

  1. Can communicate with more than his middle finger
  2. His or her concerns span the organization, not the immediate technology and product he or she is in charge of
  3. Understands the business and the user he or she is supporting, including internal users (dev, QA, sec, ops)
  4. Understands and has practiced Lean and Agile and can combine gut instinct with data

I try really hard to incorporate 2, 3 & 4 everyday. And I can say I often times, can mostly achieve #1.

Until next time.

Comments !