Ops is a UX discipline

The overall ambition of the DevOps movement, in my opinion, is to build collaboration between the Development and Operations teams.

As developers, their part of the deal is to build applications with deployment in mind, making their applications easily configurable, easy to monitor and streamlined dependency management.

For Ops we need to make it possible to deploy applications quickly, reliably and securely, and to make sure developers have the tools to understand their applications at a deep level.

When thinking about the Ops side of DevOps you can be forgiven for thinking that it is purely a technical exercise, if you have amazing tools that push bits around in more and more complex ways to deliver the holy grail of operations you will have succeeded, but, that isn’t really true.

Like any product, Ops tooling is only successful if its used. As an operations team a key metric you need to be looking it is how many developers in your organisation are interacting with your tooling. If it seems like you have a few expert user who “get” your way of working you should start investigating what is putting off your other potential users.

A good example of this problem comes from the bain of every operations (and security) teams, Secret storage. Every man and his dog knows that you can store your super secret access keys in git, so what should we do? For the purposes of this post lets keep it simple and avoid complex systems like Vault, they have their place but if you are a small team or just getting started on this journey it’s probably going to be overkill. We are going to use Sops, and because we are (hypothetically) using kubernetes we are going to simply encrypt a yaml file that works with k8s. We can then add the secrets to containers via helm charts.

Couldn’t be much more simple than that right? Job done? Not quite. Let’s put ourselves in the developers position. I want to edit one of the secrets for my application what are the steps i’m going to have to take.

1. Find where secrets for my application are stored
2. Decrypt the secret
3. Base64 decode my secret (k8s requires secret values be base64 encoded for reasons…)
4. Make the change
5. Base64 encode the secret
6. Encrypt the secret
7. Save the change

So as a developer i’m sitting here thinking, i just want to change our twitter client secret but i need to go through 7 steps? That seems like an awful lot of hassle, maybe this secret isn’t really secret and i can just hardcode it… nobody will notice, right?

Sure the developer shouldn’t have this attitude to security but really the problem lies with the secret solution, we thought we had something simple but when it comes to actually using the solution its a pain. But this problem is extremely easy to solve, write a small script which grabs the secret from its storage location (which could just be a standard location in each app repo) open the users $EDITOR with the already decrypted and decoded value pre-populated, when the editor closes after encode, encrypt and save the value automatically. Of course the steps are exactly the same but all the developer needed to do is run a script with a couple arguments.

This is a relatively straight forward example and can be made even more simple, perhaps using git hooks to automatically decrypt and encrypt values ready for the developer use for example. But the point is, remember that your customer is the developer, you need to put yourself in their shoes with every tool choice and solution you work on. At the end of the day UX is as critical to Ops success as it is to your companies product.