As a ‘DevOps’ engineer I often get asked “What is DevOps?" Honestly, I struggle to answer. I usually come out with some spiel about automation and automating myself out of job. Which of course is next to impossible, which is why I don’t mind saying it.

But really, what is DevOps?

DevOps is a term that rose from the car crash that was Development and Operations working in silos. Colleagues batting for the same team, working towards the same goals, but at the same time, enemies, convinced of, and cursing, each other’s incompetence.

Dev would code the application. When they deemed it ‘production ready’ they would throw it over the proverbial fence to Ops to deploy. A trivial but typical scenario might play out like this…

Dev: Application is ready. We’ve got some great features in this release, but nothing nasty. Should be a doddle to release.

Ops: (Roll of the eyes). Cheers, thanks. We’ll get to work.

Hours later…

Ops: Ummm… Dev, we’re having problems deploying. There are errors in the logs indicating we’re missing an API token. Something about a messaging service.

Dev: Oh yeah, we needed to use a new API to send emails and SMS.

Ops: Right, thanks for the heads up. How did you authorise against the API in development?

Dev: We didn’t have to do anything really. The SDK must have picked up the credentials from user config in our home directories.

Ops: Well, we’re going to need to get that secret to the application some other, more secure way. We can’t have API tokens lying around on the file system.

Business: Meanwhile the business is breathing down Ops’ neck because Dev notified everyone the application was good to go.

DevOps was the term coined as people realised this complete separation of responsibility was not an optimal way of working, and that the two teams would do a better job working closer together.

When you think about it, DevOps encompasses such a gamut of knowledge and capability it’s a wonder anyone is able to confidently say they’re a DevOps engineer. A good Dev needs to know their language(s), patterns and best practices inside out to be able to build robust, reliable software quickly. Ops need to be good system administrators, infrastructure and site-reliability engineers at the same time, as well as know the intricacies of the build and packaging tools of Dev’s language(s) of choice.

But all of it is incidental complexity. Prod-like development environments, prod-like data, build pipelines, branching strategies, versioning strategies, tagging strategies, secret management, containers and the explosion of frameworks and tools to manage the complexity that containers introduced… the list goes on and on. And it’s f***ing overwhelming.

For me, DevOps is about removing as much of that as possible. It’s core principles are speed and safety, reliability and repeatability, getting code from development into your users’ hands as fast and as safely as possible. But I think most importantly it’s about trying to do more with less. Reducing the percentage of time you spend on incidental complexity so you have a greater percentage of time delivering value to your customers.

A good DevOps engineer will squeeze every last bit of value from a tool or framework or service already in use before introducing another one. Why? Because he understands that every new tool, every new framework, every new service, introduces even more incidental complexity. More time installing, managing, upgrading, integrating, troubleshooting.

In an ideal world you could write your code not in a production-like environment, but in production. You wouldn’t be creating prod-like test data and conditions, you would have real data flying through your code in real time.

The folks over at Dark are onto something…

Your thoughts? I'd love to hear them. Please get in contact.