Devops: Tooling Over Processes

Devops is a set of technical and non-technical processes. I have talked about it previously here: What is Devops ?.

But how do we go about executing these processes ?

In engineering, a process is a series of interrelated tasks that, together, transform inputs into Automation system

Source: Wikipedia

A process can be encoded in a document, enforced by a human or automated by a tool. In this post, I claim that any process worth adopting must be done via a tool.

Encoded in a Document

A process written down in a document is a nice idea to hear but tough to follow through. One has a confluence or github wiki page, enlisting the steps required to perform a task, and the links to it are thrown to a client’s face everytime they ask for it.

But then comes the inevitable back and forth on the interpretation of the written word. In time, the document decays and its content become ineffective and sometimes downright dangerous.

Enforced by a Human

A process enforced by a human performs a little better than documents. A human is a dynamic entity and can responds to changes as necessary. But a human is a human. They get sick, go on a vacation or quit.

Tooling over Processes

A process is communicated A tool is programmed

If something isn’t automated as part of a tool, you’re going to have to keep communicating it over and over again

Source: Firstround.com article on Percolate.com

What is it ? What is Tooling ?

Bespoke cli’s, ui’s, libraries that are highly tailored to the processes of a company. They are built when there aren’t any cost effective market solution with equivalent features.

A few Devops processes

• Provisioning Resources

• Managing Permissions

• Hooking up Monitoring and Alerts

• CI/CD

• Spinning up Test Environments

• Oncall schedules and capturing incidents

• Many more

What to build ?

Measure the frequency of process related queries and the time spent to resolve them to find out which tools need to be built.

When to build ?

Instead of reinventing the wheel, we should first try and look for both free and paid tools which can perform the task. Affordability and integration with internal tools can be concerns here.

Avoiding Decay

A tool can become redundant too. But fortunately since it’s code, we can measure the progress of decay. They key is to treat a tool like a product.

• Measure visits to a tool’s features.

• Measure drop offs in the user journey

• Measure latencies and completion durations

• Take surveys to identify usability pain points

• Deprecate features/tools with embarassingly low usage

Is it worth the time ?

Although the above recommentations sounds like a lot of investment for something as pedestrian as processes, but the benefits are abundant.

• Stops repititive communication and prevents decay

• Makes stakeholders self sufficient

• Builds up a product mindset

Instead of writing or governing processes, building them into tools makes the collaborative contracts between teams highly visible and clear. For some companies it can be the secret sauce to success.

As is tradition, the closest XKCD reference I could find.