DevOps is complex

https://pixabay.com/en/fractal-sphere-steel-3d-structures-1118515/
HypnoArt

Does DevOps make things simpler?

That all depends on which side of the fence you are standing.  If you are developer things are simpler.  If you support DevOps, if you are one of those people that is trying to automate processes or make things simpler for others, then your life is more complicated.  Instead of one tool you’re dealing with many tools all hooked together with bubblegum and twine.

In the article “DevOps Introduces Complexity.  Really” the author, Don MacVittie, goes on to explain his hypothesis.  But more than that, he goes on to talk about how the whole DevOps tooling needs to be a project.  Just like anything else IT is working on for the business, working on DevOps for IT requires a project.

In our environment we have it quite simple with Visual Studio and BuildMaster.  We use Visual Studio to build and test and when we want to move it up the development food chain we drop off the version we want to move into a drop folder and let BuildMaster take it away.  But what happens in the background?  What could happen in the background?  Well, right away we’ve got integration with DaveBot to verify that things are the way they are supposed to be.  For web apps we need to stop/start application pools.  We need to potentially deploy to multiple servers, either in parallel or serially.  If we want to ensure no application downtime we need to go serially with an appropriate wait between servers to ensure that the traffic is moved from one server to another.

And if you throw in what we could be doing:

  • integration with our load balancer
  • integration with SCOM
  • email/sms notification of changes
  • automated smoke testing on each server
  • updating the application list
  • updating the CMDB

But to the developer, to the person using the tool, it’s a simple thing:  pushing a button.  But to the people supporting the backend, it’s complicated.  And getting more complicated.  A lot more complicated.

I would change the author’s wording a little.  We think of project too easily.  DevOps is a process.  DevOps is a cultural change.  DevOps is a set of tools.  But, most importantly, for the clients, DevOps is a product.  We need to think of the entire toolchain, the set of processes and procedures, as part of a product and manage the product.  Give it funds for growth and even keeping the lights on.  TANSTAAFL.  (There Ain’t No Such Thing As A Free Lunch).  As the author says:

So there is a cost. The cost is not small. But the benefits still far outweigh the costs, and I’m not arguing otherwise. What I am arguing is that it needs to be a cost that is accounted and planned for. “When it breaks, we’ll fix it” is too relaxed for the toolchain that will run your software factory. Once it’s right, take the time each week to keep it right. Set up the policies, processes, and time to keep it clipping along smoothly.

And keep kicking rear. This is just a cost of doing business, much the same as database maintenance.

Leave a Reply