How many times have we heard this phrase?  “If I had a Dollar (or Euro, or Yen, or your currency of choice) for every time so and so did this, then I would be rich.”  Well I would like to propose that we change this to “If I had $10 (or Euros, or Yen, or . . .) every time so and so did this, then I would be rich.”  Hey, inflation happens right?  So for the rest of this blog post, I want to build upon my last post where I closed the post with the question “Does DevOps equal Automation?”

When I get home from the office, after a long day of helping our clients work to achieve shorter release cycles, and minimize their mean-time-to-recovery, I am asked that fateful question that husbands and fathers are asked all over the world . . . “How was your day?”  Most of the time, my response is something along the line of: It was good, fine, or busy.  But there are those times where I usually start my response with a head shake, an exasperated sigh, and a maniacal gleam in my eye where I start off by saying, “If I had a dollar for every time I have met with a client who thinks they are doing DevOps because they have implemented tool X . . .”

There is no denying that automation is a pillar of DevOps.  By automating we get the ability to ‘run-rinse-repeat’.  We as humans, and even at the organizational level, get good at what we do often.  The more often we do something, the more often we have the opportunity for a feedback loop.  We have more opportunities to discover what we are doing wrong, and fix it.  This is one of the key philosophies of DevOps, to iterate on our processes, find challenges within them, and fix them.

Does DevOps Equal Automation?

When we try to effect change within an organization, we really have two paths to do so.  The first way is by a fiat or an ‘Executive Directive’.  The second way we effect change within our organization is by bringing in new tooling to drive that change in process.  The major caveat here is, and is definitely worth noting, that just because you have brought in a ‘DevOpsy’ tool, doesn’t mean you are doing DevOps. “If I had $10 . . . “

This may be your first step in your DevOps journey, but don’t try and trick yourself into thinking that just because you purchased a 1000 node license for Chef that you are doing DevOps.  All you have done is started upon a fantastically challenging (and rewarding!) journey towards organization improvement.  Challenging it will be, no doubt about it.  But the benefits will far outweigh the costs of that journey.  For example, from Puppet’s State of DevOps report 2016, your journey will ultimately net you approximately $4.3 MILLION in savings on rework alone (on the low end) after completing your transition to being a high performing IT organization.

So how does DevOps equal automation, considering the fact that I just told you to not be delusional about your purchase of your Chef license?  Enter, the law of unintended consequences.  In order for you to maximize the utility of your purchase, you now need to make sure that you are effectively utilizing it.  Since DevOps philosophy tells us that we need to break down silos, I ask you, who is writing those Chef recipes and cook books?  How do you integrate them into your deployments?  Do you alter your deployment run-book to now say: Run Chef Recipe XXXXX? Or have you also introduced an automated deployment tool and you leverage this tool to run your Chef recipes?  Honestly, as someone who comes from a development background, I vote that someone within the development organization ‘owns’ the Recipes and Cook Books.

Personally, I view a DevOps journey as something that can, and even should be a highly fluid approach.  Over time, our (your) organizations have grown to look much like a spider web.  We have built a number of process over the years inside our organization.  Each one of those processes will integrate with one and another, in order to help us execute on the task at hand.

Let’s take a minute and beat up that Deployment Run-Book you have.  That run book contains many sub-processes within it.  There is the server configuration piece, a database deployment piece, even a code copy piece.  I am even willing to bet that there is a validation piece.  Each one of these steps have their own set of sub-steps, or in other words; the HOW do we do this step.

As we look towards our DevOps journey, and executing on this journey, it can get rather daunting.  You will have to understand each and every nuance around all of our processes within the organization, along with how they integrate.  This is why you have to bring the philosophy of continuous refinement to your journey.  It is impossible for any person to know everything about everything.  Where each one of the spider webs threads cross is a process to be picked apart and automated.  But once you “fix” that process, what intersection of threads (process) do you tackle next?

Automation to the rescue!

That Chef license you just bought is going to help you drive organizational change.  As you start to pick apart your ‘spider web’ you will find yourself automating every step along the way.  It is important to note, that the initial decisions that you made about your technical implementation may be . . . well . . . WRONG.  But that is ok.  As you continue to automate everything from your Continuous Integration builds, to you server configuration management, you will learn.  You will learn what challenges you have in your processes.  You will learn from any mistakes that you have made.  But since you have chosen to automate these processes, then the fix becomes easy (and even quicker).

But with automation comes another challenge: How do we get even better?  Have we looked at HOW we are working?  Are our applications broken apart into micro-services?  What is my Unit Test coverage like, and in that same vein, are my Unit Tests quality?  How are we preforming User Acceptance Testing?

Your journey to process improvement will be a challenging one.  But just remember . . . just because you have bought that Chef license, doesn’t mean you are doing ‘DevOps’.

“If I had $10 every time I heard . . . “