DevOps is not a function, it is not a team, it is not a role. There, I said it. Click bait deployed. I am by no means the first to express this sentiment (and I urge you to go and read There Is No Such Thing as a DevOps Engineer to get a far more cogent analysis than I will offer here), but having recently been involved with clients that have a DevOps Team and are hiring for DevOps Engineers, I feel it is a point worth revisiting.

Now, you might argue that if real companies that hire real people have DevOps Teams and DevOps Engineers then, actually, DevOps is a role and there are dozens of job listings to back this idea up. If I were being pedantic I might point out that a job title is not the same thing as a role - a role is combination of responsibilities, duties, actions, and tasks associated with a job title. But I don’t want to have that argument, I merely want to suggest that despite current connotations DevOps was never intended to be a role and giving people the title DevOps Engineer in no way helps an organisation to ‘do’ DevOps. That is not to say that an organisation can’t embrace DevOps culture if they have a DevOps Team, but I would argue they are not putting the best foot forward on the path to DevOps nirvana if they do.

So What is DevOps?

I suppose it is worth clarifying what I mean when I talk about DevOps. I won’t go into all the nitty gritty, but I will give the 10000m view so we are on more or less the same page. The term ‘DevOps’ itself has been around since the late 2000s and is a portmanteau, being derived from software development (Dev) and IT operations (Ops). DevOps can be thought of as a combination of practices, tools, and cultural philosophies that aim to integrate and automate the work of software development (Dev) and IT operations (Ops) teams to facilitate faster delivery of higher-quality products. Or even more succinctly: DevOps is a culture. There is, of course, much more nuance to it than that, but that is the essence of it. If you want to delve more into what that means, then please do go and read any one of these articles here, here, or Wikipedia; I’ll wait.

So, if you believe the broadly accepted definition, it seems irrefutable: DevOps is not a function (or team, or role).

The Rise Of The DevOps Engineer

So we have established that DevOps is not a role, but clearly the job listings say otherwise, so what is going on? Let’s take a look at a DevOps Engineer job listing and see if we can find any clues. This one was taken from LinkedIn and is pretty typical:

This organisation is looking for a very experienced DevOps Engineer to enhance and support the CI/CD build and deploy pipelines on multiple platforms. You must come from a software engineering background and be able to understand Python microservices in depth.

Key Requirements:

• Python software engineering experience
• At least 3 years commercial experience as a developer before moving to DevOps
• AWS
• Kubernetes
• Terraform
• CI/CD – GitHub
• SRE / Chaos engineering
• Observability, networking, monitoring, logging

The requirements ask for experience in software development and then list a set of tools the applicant should be familiar with - tools for automating the building of cloud infrastructure and reliably running software on that infrastructure. If we reduce this job listing down to its essence, it says they are looking for a Cloud Infrastructure Engineer who has experience with Python, or to put it another way a former Python Dev who handles Ops tasks. See what’s happening here? Because it’s simpler and perhaps more convenient, the term ‘DevOps Engineer’ has become a synonym for a Cloud Infrastructure Engineer that can code and it has stuck; it has fewer syllables than ‘Cloud Infrastructure Engineer’ and, to the non-techie, who might of heard of DevOps as a buzz word, it sounds about right. This is good old human nature at work. We are lazy and seek efficiencies all the time, this is just another example. Unfortunately, this mutation from the abstract to the concrete undermines the whole notion of DevOps, if you are looking to reduce silos, foster more collaboration and shift left then creating a new team is not the place to start!

Shift Left?

I casually dropped in some more terminology there, so let’s take a little sidebar to explain. Put simply Shift Left refers to the process of moving tasks earlier into the development cycle. If you imagine a project as moving left to right along a time line, moving things earlier on in the development cycle ‘Shifts’ that thing left on the timeline. These ’things’ can be anything from testing, code quality checks, and also security (and the integration of security processes is often termed ‘DevSecOps’). It could be as simple as running a linter on save to reduce formatting issues making it into the code and thus reducing the number of changes requested at code review, or as in-depth as vulnerability scanning, automated builds and deployments in a CI/CD pipeline, or even organisational changes, such as having UAT testers work more closely with developers to provide feedback early, rather than the traditional ’throw it over the wall’ approach. As a rule of thumb, anything you can move closer to the developer is shifting left and is a fundamental principle of DevOps.

Does it really matter?

Maybe I am just being too precious and gate keeping, words change meaning all the time, language evolves, people adapt. According to Reddit, I should just shut up and go shout at a cloud, and I understand the frustration conveyed there; having some random bloke on the internet telling you that your job is not a job isn’t going to make anyone feel good. So I don’t blame them, the DevOps Engineers, but I do blame their bosses, those people that wanted to do ‘DevOps’ because everyone else is, without taking the time to understand what that means. If you are a decision maker and want to foster a DevOps culture in your organisation in order to improve software delivery and quality, don’t build a DevOps Team; by doing so you are just making life harder for yourself. When you create a DevOps Team, you are signalling to the rest of your organisation that DevOps is a function - a notion that you then have to work to undo to create the culture and thus reap the benefits you wanted in the first place. And for those people in your organisation that have some inkling of what DevOps should be, well they are not going to take you as seriously and nor should they.

Look at it this way: You wouldn’t rename a software development team to ‘Agile Team’ because you want to adopt Scrum, would you?

The Real World

Back in the real world hiring managers will no doubt continue to post jobs for DevOps Engineers and we have probably long passed the critical mass for that to change anytime soon. So, maybe the battle is lost and I need to move on? Perhaps. Probably. I am trying to be stoic and pragmatic and accept the world for what it is, so going forward I will start to use ‘Shift Left’ and ‘Shift Left Culture’ interchangeably with DevOps, which admittedly isn’t as snappy but it helps differentiate and I can live with that… until someone builds a Shift Left Team that is.