DevOps Engineers — where it all went wrong

Historically — Operations team vs Development team

If your organisation has DevOps engineers then you have kind of missed the point.

It has become obvious to me that a lot of software development, especially in large enterprises, has a specific role or in some cases whole departments for DevOps. All this is doing is rebranding an existing set of skills and persisting the silo that DevOps was meant to break down.

DevOps its a movement to avoid Dev throwing code over to Ops that has bad logging, manual deployment and other development nasties. It’s about Devs and Ops working closely instead of screwing each other over, so having people in a role called DevOps is the exact opposite of DevOps. It blows my mind how wrong large businesses get the message. Often, it’s just a Buzzword to them.

When you look at these roles they are just operations roles rebranded as DevOps

Much like Agile, its not a skill set. It’s not a role. It’s a way of working, a mindset to ensure that the development teams and the operations team closely collaborate. This is often translated as the operations team creating a platform and dictating what the development team need to do in order to make the management of the platform easier. This is fine and often can help everyone have a common understanding. The problem with this is when the ops team become a dictatorship rather than having continuous conversations with the development team.

I have two perfect examples of this happening. The first being when I was on a development team where it made complete sense for us to deploy a branch to a test environment and another branch to production. (This is a separate discussion but to do proper continuous integration and deployment then this is needed.) So we, as a development team, contacted the DevOps team (writing this down shows how silly it is to call an operations team DevOps) and asked to start a discussion about a way we could start deploying to the test environment from a branch. We were immediately told “No we don’t do that here”. Maybe this was just a one off but I genuinely believe that creating roles and departments called DevOps creates this hostile, dictatorship type attitude.

The second was refusing to increase a docker container size because it would change the container size limit for every single microservice we had in production. To me, if we as a development team had a legitimate requirement to change the container size limit then there should be some flexibility there to adapt and for a conversation to happen where both parties have the right outcome. That is the spirit of DevOps!

Now, I am aware that it looks like all I have done is bash operations teams but that’s absolutely not the intention! Operations teams will want a nice, consistent platform that they can manage with ease. That makes total sense! It streamlines processes, allows for automation and means there are no random dependencies that are inconstant from the rest of the platform. I think the whole issue is the mentality harboured from calling an operations team a DevOps team. This has to be a conversation, a middle ground, where development teams have the flexibility to be innovative and not be constrained by “rules” or a platform. Where operation teams are able to automate, streamline and manage a large set of systems with ease.

Two teams. Collaborating for a flexible solution.

To summarise, DevOps is not a role, a team or a set of skills. It is a conversation and a mind set that should be employed to ensure a strong relationship and collaboration between an operations team and the development teams.