Dear IT Pros: what I didn’t get about DevOps – and why you shouldn’t make the same mistake

Hi. I’m Adam Carter, a technical evangelist at Dynatrace. I’ve spent my career working with IT Pros – trying to understand what their needs are and what we can do to make their job easier. One of the topics that comes up in this space is around adopting DevOps – a new way to handle the operational tasks of deploying, managing, and updating software. I took a brief look at it a few years ago, got a handle on what it meant, and decided it wasn’t going to do anything to make work easier for IT Pros, so I put it on the back burner as something to check up on once in a while and see if it was getting traction. This blog is to help you NOT do what I did. Here’s why.

In the early days of DevOps momentum, a colleague explained DevOps to me this way:

“DevOps means adopting development philosophies and practices in your IT Operations.  This means adopting agile / sprint concepts in managing projects to bi-weekly goals, and writing code to automate as many IT tasks as possible.”

I didn’t understand why IT would want that. Adopting sprints didn’t make much sense to me since so much of IT operations is reactionary. We deployed major versions of software only a few times a year. As for coding automation, I think most IT folks are willing to fire up PowerShell and write some scripts. The idea of IT or ops firing up an IDE to script every deployment task they needed seemed unlikely to me.

Of course, this was all back in the day when a business unit would buy or build, a software solution – and then hand it off to IT to deploy and manage.  This was always a pain point for us in IT because the software nearly always came with a bunch of questions that the business unit couldn’t answer, like:

• What platform does this run on?
• Does it need a database backend?
• Which products and versions are supported?
• How much storage/CPU/RAM does it need?
• Does it need load balancing? Redundancy? Backups?

The quality of these answers was mixed. Typically, we just bought the biggest server we could afford that seemed like it would have enough capacity, get it up and running, and cross our fingers. It worked out most of the time, but it was frustrating for everyone involved. We also ended up with a datacenter full of servers running at 10-20% of capacity because we’d over-purchased to make sure all the apps would run well.

Fast forward to today and the trends of virtualization and cloud computing. IT ops doesn’t have to guess at server capacity anymore, because added capacity is just a few clicks away. Development has moved from the monolith to microservices because it’s easier to scale out individual app components.  But IT ops still has to deal with developers (or business units) dropping code over the wall to deploy.  Software running in the cloud produces different questions to ask, like:

• Is the data secured/protected?
• Does the cloud provider/application meet our compliancy requirements?
• What are the availability/uptime/performance thresholds for the app?
• Is there an SLA that needs to be maintained?

We’d solved the capacity problem with new deployments, but that just really enabled a bunch of new questions, that again, the dev team (or business unit) may not have answers to.  To me, DevOps just sounded like asking IT to do more work, so developers could push out patches faster for their sloppy code.  Today I can see how I was not correct in that thought.

But, in my defense, I can see how I got it wrong.  I was missing a key piece of the DevOps pipeline story: it’s not the Ops adopting sprints and automating deployment, it’s the developers.  A better definition of DevOps, now embracing hybrid to cloud, might be:

“You built it –  you deploy and manage it.”

DevOps, now embracing cloud, is not about asking IT to do more deployment work.  It’s about building Dev into the release and management pipeline (and there are plenty of tools to help automate this).  If you haven’t seen my colleague, Andi Grabner deliver his “Building an Unbreakable Delivery Pipeline” presentation, take a look.  He demonstrates:

• Building out an environment with staging and production deployments
• auto-deployment to staging when the code is updated
• monitoring the app with Dynatrace to compare performance with previous releases
• automatically pushing the app into production if it runs and performs as expected

Dynatrace then continues to monitor the app in production.  If any of the metrics aren’t meeting expectations, it automatically triggers a roll-back to the previous, better performing build.

From the workshop: the unbreakable pipeline in action

So that’s really cool.  Instead of throwing code over the wall and asking IT to deploy it, developers do that themselves.  In addition, they also take care of scaling it to support the capacity needed.

“Hmm,” you may be thinking to yourself “if the dev team is now responsible for making sure the app is deployed and operational, what’s the IT guy’s job now? Is he out of a job?”

Not at all. I like to think of it as Leveling Up and it adds new opportunities for every single IT professional.  Ops still knows the definitions for SLA’s, uptime and capacity requirements because they’ve been delivering it.  Instead of Ops being the over-the-wall-code-catchers, they are now more of a consultant or advisor to the business unit and dev teams.  They collaborate to help dev understand what the ops requirements are for the application (e.g. availability, fault tolerance, response times) and getting these requirements build into the dev pipeline.  Plus Ops is still the expert on security and compliance, and they can help dev in that area, too.

All of this increases the value of IT to business as you team up and deliver better software faster.

So, to my Ops friends: what I didn’t get about DevOps, I do now!  And, not only don’t make the same assumption I did on DevOps but take it as an opportunity to Level Up:  learning, lending your expertise, and fine-tuning your own “performance “skills.  Get out in front of projects, dig into business requirements, team tightly with dev and help build and deploy.  All of this increases the value of IT to business as you team up and deliver better software faster.

For more information on leveling up and other interesting new trends in Dev and Ops, see “Trades of a Performance Engineer in 2020”.