Year in review – DevOps in Danger

Let me tell you a story.  There was a man.  He had a great idea.  He told his friends who listened and agreed it was a great idea.  He began to tell other people his idea who also thought it was a great idea.  One day he held a conference to tell the world, and he gave it a jazzy title.  The people came and the man tried to tell the people his idea, but the people had stopped listening.  All they were talking about was the jazzy title and what a great title it was.  The idea became lost and all the people remembered was the title.

Welcome to the state of DevOps at the end of 2016.

I was asked an interesting question recently.  What was my view on where DevOps is heading.  Was it progressing or would it stagnate?  My answer was neither.  It’s a bubble that’s ready to burst.  The issue is that the original intention and problem DevOps was seeking to solve is being forgotten and the focus has been shifted to new tools that want to jump on the band wagon hoping to claim they are the DevOps tool of the future.

What was the problem originally?  Software development!

There was a time when Agile was not as common place as it is today.  Most people used Waterfall to manage their projects.  Development cycles were defined into a long periods of development time to add all the features which was then passed to the test cycle, then the UAT cycle, then the NFT cycle, then pre-prod and finally after months of cascading down the rock face of QA to production.  This cycle could take months and result in companies only being able to produce software at most in bi-annual updates if they worked hard and didn’t hit any issues on the way.

As the world changed and customers began to expect new features yesterday, market demand began to be driven by trends and new starters popped up threatening larger companies market share it became clear that something had to be done to help developers produce features in smaller chunks so Agile began to become accepted.  But that wasn’t the only issue.

Many organisations faced issues releasing those updates so new methods of managing software releases had to be analysed and defined.  Sometimes the issues weren’t so much technological but down to the culture of the organisation, so ways of getting Dev teams and Ops teams to work together in parity became the key to making it all work together.  And thus DevOps was brought to the world.

So how has the focus of DevOps shifted from being about developing software to managing Infrastructure?

There are many factors but probably the main one is the explosion of the internet and connected devices.  At it’s concept, the internet was not what it is today and many of the tools created to support DevOps were geared towards desktop application development and server environments.  But then new devices came about.  Smart phones and other mobile devices became common place. The internet began to be something you could carry around in your pocket so web development began to gain a larger market share in application development.

As web traffic grew, it became clear that single dedicated physical servers could not cope on their own so load balanced clusters of web, application and database servers began appearing.  But these took up physical space and cost a lot of money to run, maintain, upgrade or replace, so those physical machines began to be migrated to Hypervisors, larger servers capable of hosting many virtual machines at the same time.  Organisations began to cluster their Hypervisors and ended up back at square one where they were with the dedicated servers so cloud companies formed, offering warehouses of clustered Hypervisors for customers to host their equipment on without the problem of worrying about upgrades.  Want more RAM? No problem.  CPU cores?  Here you go.

Then some bright people looked and thought, hey, why are we wasting so much overhead on the host emulating hardware and devices on Virtual Machines?  Can’t we just have a single mega computer and run processes and applications direct on the host in simple shipable containers?  Thus tools like Docker came about.

While these are all great tools for Ops and managing Infrastructure, they don’t help a great deal with developing and delivering software which is what DevOps should be doing.  How do containers aid Continuous Integration and continuous testing processes?  How does hosting on the Cloud help to ensure the integrity of the code base and that customer requirements are being met?  Configuration Management may help to streamline the deployment, but how does it help to ensure that the code being produced is always of a high quality and as bug free as possible?

These are the questions that DevOps should be seeking to answer.

As a DevOps specialist whether the client hosts on physical boxes, cloud VMs or containers should be irrelevant.  These are questions for the client to focus on depending on their business need.  They are entirely in the realm of Ops, and I certainly don’t get overly excited because a new container system or method of hosting VMs comes about.  What we need to focus on in our role as DevOps specialists are to ensure that the organisation is creating software that is driven by market demand, meeting customer requirements and can be quickly shipped out to said customer when QA deem the software fit for purpose.

We’re not super Ops people or sysadmins.  Infrastructure is a concern only when it becomes a problem to delivering software but should never be our main focus.

When we stop focusing on the Dev, we become Ops and this is why I see the bubble bursting very soon, when the world wakes up and asks the question, “What happened to the Dev?”