Whatever Happened to the Dev in DevOps?

DevOps is a term that comes full of controversy. A lot of people are on the bandwagon, while others are waiting for the term to jump the shark, and eventually go back to business as usual.

Regardless of where you are along the spectrum of loving or hating the term DevOps, one thing is certain. More and more people are using it to describe a system administrator who uses scripts, or tools like, Chef, Puppet or Ansible, in order to provision infrastructure. There is also usually an expectation of being able to deliver this in 100% cloud, or hybrid cloud environments.

How Things Fall Apart

The problem with defining a “DevOps Engineer” in such narrow terms, is that someone like that doesn’t bring much to the Dev side of the equation. An infrastructure engineer often has the ninja skills to take care of the network. But if the application itself has problems, such as memory leaks or problematic dependencies, they may not even realize that.

When things fall apart, the first things to go are processes and methodologies. All of a sudden, all of those lofty goals get set aside, in order to respond to the latest emergency. What then, is the solution for building a DevOps culture, something that will serve you when things are running smoothly or you hit a snag?

Short of throwing a monitoring report over the wall  to the Dev team, the system engineers can’t do much to help developers and QA to replicate and troubleshoot an issue. God forbid that a production issue comes up, various teams end up working in silos, even though there may be a concerted effort to triage the issue.

On the other hand, try asking the average developer for a plan to improve network latency.  You would rightly be met with the hairy eyeball. Why would you expect them to do this?

A Comprehensive Approach

The more likely person to ask is an engineer who has straddled both Dev-oriented and Ops-oriented roles. Such a person can wear different hats, but also has the wisdom to know when it’s better to leverage the skills of either Dev or Ops to solve a particular problem.

The best advice I would give as you consider a journey into DevOps, is to take stock of where you are now. Are you willing to address the low-hanging fruit that has been making you inefficient for too long now? Take inventory from the top down, because a feedback loop will only succeed, if it doesn’t need a lot of babysitting, each time a stakeholder wants to know what’s going on.

Benefits of Adopting a DevOps Approach

1. Let’s start with the product. Without adequate product management, does it really matter how fast you bring it to market?
2. Make sure that there is an accessible way for interested people to understand what clients (internal or business) want. That means your project managers can’t be the only ones with a golden copy of the plan. Democratize it!
3. Allow for a way to enable developers to collaborate and develop their skills. This would include things like making code analysis a standard part of your code review procedures.
4. No more cowboy builds. Even if all the software builds are not yet automated, have a small team of people rotate the responsibility to standardize the builds. Otherwise, you are creating a nightmare that will only be magnified when it comes to packaging your product.
5. Incorporate QA testing, and maybe even environment provisioning, as part of your build process. This is no small feat, but try it out on a small, inconsequential project.
6. Give Infrastructure and other pure Systems folks some visibility into your release timeline. Allow them to properly plan for continuous deployment.
7. Don’t forget to set up user-friendly dashboards for business analysts, and other such client-facing folks. The easier it is for them to understand your message, the easier it will be for them to relay it in unambiguous language. If they have to translate for you, you’re doing DevOps wrong.

How we Can Help

At DevOps Advisors, we are here to help. We have engineers whose experience spans the roles, and can help you craft the right strategy. We also have engineers who can focus on specific areas where you need help the most.

As someone who has occupied in the various hot seats that many of your staff occupies; I can understand their fears, frustrations, and reluctance. I also know how to weave their individual visions into a cohesive process that different constituencies can buy into.  It takes more than words, more than creating a catchy phrase to name your team. You a plan, and someone experienced in implementing change, to help bring transformation your culture.