A Strange Death of DevOps

About 15 years ago DevOps was born: a movement that promised unseen improvements in time to market and software quality. It aimed to remove the silos between the development and operations teams, thus DevOps, and make the process of software delivery to the end user, which involved both, much more efficient.

Nowadays, “DevOps Engineer” (and some newer derivatives like DevSecOps and MLOps) jobs are an industry standard, and required skills usually include knowledge of cloud platforms like AWS, infrastructure-as-code tools, container orchestrators like Kubernetes, build-servers like Jenkins and monitoring solutions like Prometheus and Grafana. The actual job responsibilities usually include provisioning, configuring, and maintaining cloud infrastructure, build pipelines, and monitoring. Many roles require only minimal interaction with the developers, some close to none. But wait, we were supposed to get rid of the division between development and operations, weren’t we?

I call such roles “Cloud System Administration”, inspired by a book with almost the same name. Let’s see how Wikipedia defines “System administrator”:

An IT administrator, system administrator, sysadmin, or admin is a person who is responsible for the upkeep, configuration, and reliable operation of computer systems, especially multi-user computers, such as servers. The system administrator seeks to ensure that the uptime, performance, resources, and security of the computers they manage meet the needs of the users, without exceeding a set budget when doing so.

If you add the word “cloud” a few times here and there, you will get an accurate description of what the vast majority of freshly coined DevOps engineers do, despite in the cloud.

So how can we revive DevOps? Let’s remember a few things.

DevOps is not about tools, it’s about the process

DevOps is about making the delivery of the features to the end users more efficient. It’s about increasing the development speed and decreasing the number of bugs in production. It’s about decreasing the lead time (how much time has elapsed between committing code and deploying it to production), increasing MTBF - mean time between failures (elapsed time between inherent failures of a mechanical or electronic system during normal system operation), and decreasing MTTR - mean time to restore (the time it takes to restore service after production failure). As you work on improving these metrics, you will likely have to use the cloud and all other aforementioned tools, but tools are just tools, they are not the end goal.

For example, if your application suffers from a memory leak that your development team doesn’t have time to fix, you can increase the mean time between failures (MTBF) observed by the user by deploying a set of its replicas to a container orchestrator (e.g. Kubernetes, or AWS ECS) with a configured memory-limits. After a certain threshold, the application will be restarted and operational until the threshold is reached again. By having more than one replica we increase the chances of app availability when one of the replicas is restarted. However, deploying to the container orchestrator is just a tool to solve a problem, it’s not a goal in itself. To do DevOps you don’t have to be in the cloud or use any of the tools mentioned in the CNCF landscape.

You cannot outsource DevOps

DevOps is about improving your end-to-end process, and if you are not interested in that, no one is, especially the contractors you hire. The contractors can be an extremely valuable asset by bringing the expertise you may lack in-house, but why you need those assets has to be driven from the inside and continuously reconciled to make sure, that the contractors’ work is aligned with your initial goals. I’ve seen atrocious cases of ignorance that cost the company a lot. The contractors come, do their work, get paid and the company ends up with a hefty bill and a complex useless system that has to be thrown out.

Thus, understand your goals, focus on simplicity, and try to develop or hire the expertise in-house.

Summary

To sum up, there is no such role as a DevOps engineer, you are either a cloud system administrator or a software engineer practicing DevOps and it’s more interesting to be the latter, than the former.