Like fish, is there no such thing as a DevOps engineer?

The IT industry is rife with made up titles. Unlike other professions (such as academia where the difference between an associate professor and a full professor is clear), we tend to make up titles based on whatever role needs to be fulfilled. I attribute this to two factors. First, there is the relative adolescence of the IT industry when compared with other, more mature, ones. Second, the landscape within IT keeps changing, making it difficult to solidify any particular role. For example, the traditional role of sysadmin has been superseded, in many cases, by the introduction of cloud computing and containerisation.  We seldom require that special someone to nurture individual servers anymore. As more companies move into ‘as-code’ systems, the need for a traditional sysadmin in a company has diminished (unless you’re a cloud provider or one of the few companies still maintaining a server room). 

So, what about ‘Ops’ people? Who are ‘Ops’ in a modern organisation? They are usually the people maintaining the company’s chosen virtual server solution (e.g. AWS). They maintain the cloud solution, oversee security and access management, and usually look after the source control solution. While this is definitely not a ‘Dev’ role, it also far removed from that of the original sysadmin. 

When engaging with the current term ’DevOps engineer’, I keep in mind that some people still call dolphins ‘fish’ and that the word fish has no scientific basis (although it is still extremely useful when ordering at a restaurant. It is like the constant reminders that ‘X is not really a fruit or a vegetable’, yet we all instinctively know in which section of a supermarket to find it. What I’m saying is that words emerge to encompass a shared meaning in society, and the IT industry is no exception. The term ‘DevOps engineer’ is in the process of being defined. 

When the term DevOps was coined around 2009, it was meant to describe a way of working where Devs stopped throwing deployment packages ‘over the wall’ for the Ops people to deploy. It bridged that disconnect, broke down the wall and allowed Dev and Ops to freely discuss and manage deployments together. It also meant that Devs would consult Ops before trying out something that might detrimentally affect the other, and vice versa. 

But how has the world moved on in the last ten or so years? Well, the increase of ‘as-code’ systems has meant that Devs now maintain their own deployments in the cloud and only encounter Ops when they need special permissions or additional resources that go beyond the bounds of the defaults. This has resulted in less time spent working with Ops. That wall has slowly started accreting again. 

The problem is that, at least for now, much work must be done that doesn’t fall under the specific mandate of the development teams (i.e. product work). These types of projects cut across teams and require some coding and configuration work that is also not of interest to the more Ops people maintaining the larger systems. The people doing this work have to do development and manage operations, and so, I believe, the role of the ‘DevOps Engineer’ was born. 

I recall, about five years ago, a team hiring a ‘DevOps person’, and laughing at the thought. Hiring one person to do all the DevOps work seemed like hiring one person to do all the version control work. But times change, and I needed to reassess my understanding. I am currently a tech lead in a DevOps team, a title we admit is a misnomer, but we don’t really have a better one (that task is on our backlog). What this team does falls into the categories I highlighted above. We maintain AWS, the EKS implementation, are rolling out GitLab and, most likely, setting up a paved road for the teams. This work is neither Ops nor Dev, but a weird between world where Dev and Ops fear to tread. 

Industry-wide, these ‘DevOps people’ have moved out of the individual teams and formed their own teams. I think this has been (and I argue must be) an organic process. The industry could have given the role a better name, but that is not how language works (see how the definition of ‘decimate’ has changed). If you look today at the average job description for a DevOps Engineer, there are very few traditional Ops requirements. 

So what have we ended up with? Well, the wall between Dev and Ops is back up. We’ve instead installed a team with two ladders who perches atop and acts as a go-between (or a bridge between the silos if you prefer). Maybe the gap in world views between Dev and Ops was just too dramatic to sustain. I’m sure it works in a few organisations but, for the most part, it seems the DevOps engineer is a new species that has evolved over the past few years and will continue to evolve for years to come (of course unless the industry takes another major turn). 

People need walls and build them automatically, yet this should not be seen as a bad thing. We need to recognise the tendency to build walls as a part of local optimisations. ‘Breaking down a wall’ is not a once-off occurrence, but more akin to keeping the grass trimmed. Maybe DevOps as a philosophy was doomed from the start. But it’s given birth to a whole new role. 

As developers gravitate to more specialisation, we must guard against these teams becoming a ‘catchall’ where each member must know everything (AWS, Kubernetes, AEM, GitLab, GitHub). All these skills used to be focused in well-rounded developers (cough, full stack, cough), who could do everything from designing the database to building the front-end. These days, developers tend to be more specialised, but the need for a well-rounded person still exists. The role has just shifted. That, coupled with the emergence of cloud computing, I believe has given rise to this new entity. 

So, the verdict is in: DevOps is dead, long live the DevOps engineer!