Does it make sense to talk about DevOps engineers or DevOps tools?

DevOps engineers are in high demand – the job represents an engineering unicorn, someone that understands both development and operations and can help to foster a culture where the relationship between the two is almost frictionless.

But there’s some debate as to whether it makes sense to talk about a DevOps engineer at all. If DevOps is a culture of a set of practices that improves agility and empowers engineers to take more ownership over their work, should we really be thinking about DevOps as a single job that someone can simply train for?

The quotes in this piece are taken from DevOps Paradox by Viktor Farcic, which will be published in June 2019. The book features interviews with a diverse range of figures drawn from across the DevOps world.

Is DevOps engineer a ‘real’ job or just recruitment spin?

Nirmal Mehta (@normalfaults), Technology Consultant at Booz Allen Hamilton, says “There’s no such thing as a DevOps engineer. There shouldn’t even be a DevOps team, because to me DevOps is more of a cultural and philosophical methodology, a process, and a way of thinking about things and communicating within an IT organization…”

Mehta is cyncical about organizations that put out job descriptions asking for DevOps engineers. It is, he argues, a way of cutting costs – a way of simply doing more with less. “A DevOps engineer is just a job posting that signals an organization wants to hire one less person to do twice as much work rather than hire both a developer and an operator.”

This view is echoed by other figures associated with the DevOps world. Mike Kail (@mdkail), CTO at Everest, says “I certainly don’t view DevOps as a tool or a job title. In my view, at the core, it’s a cultural approach to leveraging automation and orchestration to streamline both code development, infrastructure, application deployments and subsequently, the managing of those resources.”

Similarly, Damian Duportal (@DamienDuportal), Træfik’s Developer Advocate, says “there is no such thing as a DevOps engineer or even a DevOps team.  The main purpose of DevOps is to focus on value, finding the optimal for the organization, and the value it will bring.”

For both Duportal and Kail, then, DevOps is primarily a cultural thing, something which needs to be embedded inside the practices of an organization.

Is it useful to talk about a DevOps team?

There are big question marks over the concept of a DevOps engineer. But what about a specific team? It’s all well and good talking about organizational philosophy, but how do you actually affect change in a practical manner?

Julian Simpson (@builddoctor), Neo4J’s Global IT Manager is sceptical about the concept of a DevOps team:

“Can we have something called a DevOps team? I don’t believe so. You might spin up a team to solve a DevOps problem, but then I wouldn’t even say we specifically have a DevOps problem. I’d say you just have a problem.”

DevOps consultant Chris Riley (@HoardingInfo) has a similar take, saying:

“DevOps Engineer as a title makes sense to me, but I don’t think you necessarily have DevOps departments, nor do you seek that out. Instead, I think DevOps is a principle that you spread throughout your entire development organization. Rather, you look to reform your organization in a way that supports those initiatives versus just saying that we need to build this DevOps unit, and there we go, we’re done, we’re DevOps. Because by doing that you really have to empower that unit and most organizations aren’t willing to do that.”

However, Red Hat Solutions Architect Wian Vos  (@wianvos) has a different take. For Vos the idea of a DevOps team is actually crucial if you are to cultivate a DevOps mindset inside your organization:

“Imagine… you and I were going to start a company. We’re going to need a DevOps team because we have a burning desire to put out this awesome application. The questions we have when we’re putting together a DevOps team is both ‘Who are we hiring?’ and ‘What are we hiring for? Are we going to hire DevOps engineers? No. In that team, we want the best application developers, the best tester, and maybe we want a great infrastructure guy and a frontend/backend developer. I want people with specific roles who fit together as a team to be that DevOps team.”

For Vos, it’s not so much about finding and hiring DevOps engineers – people with a specific set of skills and experience – but rather building a team that’s constructed in such a way that it can put DevOps principles into practice.

Is there such a thing as a DevOps tool?

One of the interesting things about DevOps is that the debate seems to lead you into a bit of a bind. It’s almost as if the more concrete we try and make it – turning it into a job, or a team – the less useful it becomes.

This is particularly true when we consider tooling. Surely thinking about DevOps technologically, rather than speculatively makes it more real?

In general, it appears there is a consensus against the idea of DevOps tools. On this point Julian Simpson said “my original thinking about the movement from 2009 onwards, when the name was coined, was that it would be about collaboration and perhaps the tools would sort of come out of that collaboration.”

James Turnbull (@kartar), CEO of Rethink Robotics is critical of the notion of DevOps tools. He says “I don’t think there are such things as DevOps tools. I believe there are tools that make the process of being a cross-functional team better… Any tool that facilitates building that cross-functionality is probably a DevOps tool to the point where the term is likely meaningless.”

When it comes to DevOps, everyone’s still learning

With even industry figures disagreeing on what terms mean, or which ones are relevant, it’s pretty clear that DevOps will remain a field that’s contested and debated.

But perhaps this is important – if we expect it to simply be a solution to the engineering challenges we face, it’s already failed as a concept. However, if we understand it as a framework or mindset for solving problems then that is when it acquires greater potency.

Viktor Farcic is a Developer Advocate at CloudBees, a member of the Google Developer Experts and Docker Captains groups, and published author. His big passions are DevOps, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).