DevOps: Standardizing The Journey

Sometimes I come across an article which is narrowly focused, but has applicability throughout the universe.  OK, maybe not that all-encompassing, but almost.  For instance, just the other day I was reading an article entitled “DevOps and the DBA“.  Kind of a narrow focus, but a couple of sentences really stood out for me.

Operations staff take the view that speed invites chaos, resulting in instability, downtime, and a lack of sleep.  The reality is that chaos, instability and downtime are not the result of speed, but the result of variance.

The goal is to enforce consistency, and to manage our resources so that the software is deployed in the same way that a car factory builds an automobile.

Wow.  That kind of sums up the DevOps movement in general.  In order to automate something, you need to standardize something – the tool, the approach, the steps – and the more you standardize the more you can automate and the fast you can automate.  I was attending a Forrester conference call a couple of weeks ago and the presenter was talking about how Amazon has seven different templates to move things into production.  Just seven.  Now, by any stretch of the imagination Amazon is a big company.  If they can do it, why can’t we?  Why is it that we have to customize all of these deployments for our deployment tool instead of using just a few templates?

But the idea of standardization is not new, nor is it restricted to just deploying applications into production.  The entire software development lifecycle is full of standards, but sometimes not the correct standard.

Back in the good old days, we used Excel for project management.  (Yes, some of you still use Excel, but there are better tools out there.)  It was a standard template for how we built applications.  The template remained the same and we just added line items for the exact pieces that we were building.  If we were building two web pages, one low complexity, and one medium complexity we added two lines into the Design section, two lines in the Build section and we were done.  We told the spreadsheet what complexity the web pages were and it used a lookup table to pull back the numbers for the spreadsheet.  Testing?  It was a set percentage of the Design and Build estimate.  It was standardized.  It was simple.  It was accurate. We used previously executed projects to populate the lookup table and we had years worth of information that we could mine.  By standardizing on a template we were able to make effective use of the data that we accumulated doing the last project and the one before that and the one before that and …

Now, imagine a world where you could go to a single site and tell it that you are starting a new project.  You give it a name, an acronym, the people on the project and by pushing a button you get:

  • Servers created
  • Active Directory groups created
  • Accounts created
  • Databases Created
  • Project Plan created
  • Automated workflows created

This is possible through standardization.  This is the dream of DevOps, this is the target that we should be striving for.  The fewer decisions that need to be made on mundane things (Where do I go to get servers created?  What databases do I need?  What should I call them?  What security needs to be set up?  What do I need to put in my Project Plan?  When should I get the automation workflows created?) the more effort can be spent on building a system that exceeds everyone’s expectations.

We shouldn’t be lulled into the idea that DevOps is restricted to just the technology pieces of development and operations, it is pervasive in nature and covers the entire SDLC, including the management of projects.  DevOps isn’t a thing, it is a culture shift that is both invasive and inclusive.  It will change how you plan and develop applications and it requires that information be fed back into the process in order to continually improve and to ensure that the process is advantageous to the organization.

DevOps, from planning to executing to implementing, is about making things easier.  It’s a long road to get there, but the more we look at the entire SDLC the more advantages we can discover on the DevOps journey.

Leave a Reply