DevOps is dead? Long live DevOps!

I am not going to go into a usual routine of introducing DevOps as a tale of Developers and Ops people building a wall between themselves and then DevOps being focused on breaking this wall. It is a valid one, but it is kinda old and too generic.

Probably, DevOps is different for each individual; there are different expectations and criterias for everyone. One can call someone a DevOps engineer and the other - SRE or maybe a Platform Engineer. Those might be different titles in your organisation.

There are also a lot of articles with DevOps principles or pillars or values. They all a bit different and they all a bit the same. You can see that it is somewhat confusing and some people would want to structure it. First of all, let me list those principles, at least one of the variations:

1. Continuous delivery
2. Automation
3. Fast reaction to feedback

Those are pretty simple to understand - we want to deliver the product to customers as fast as possible to provide value. To make it robust, we need to automate as much as possible, to remove human error and increase speed. And to make sure that the product meets clients needs we need to know those ever-changing requirements.

Those are principles that are close to business, but I think DevOps is actually closer to tech people. From that perspective, the main thing that DevOps is focused on is complexity and the ways to reduce it.

It can be hard to introduce automation in the beginning, but then it is supposed to work seamlessly, hence reduce the complexity in the long run. End to end responsibility is often listed as another principle. This one once again helps with complexity, because during handovers a lot of knowledge is lost.

Obviously, to be able to be responsible for something one needs to be able to monitor. And also test and develop the product. My personal opinion is that anyone who is doing DevOps needs to be able to code. At least, “Dev” is the first half of this acronym. Maybe it is a “survival bias” but I aslo think that in order to consciously do DevOps one needs to be fairly senior and experienced.

Finally to make it all possible, people have to constantly improve and learn new things. How to better and easier to achieve their goals or how to analyze logs faster.

So all together there are a lot of requirements or parts of DevOps. To make it manageable again it is much easier to say that DevOps is not a title, but a culture. You dont need to tackle every single aspect of this culture to “do DevOps”. Whatever works right now, and with time the situation will change and improve - so more parts of this culture could be taken on board.

Different approaches to tackle DevOps can be called differently. If you are focused on stability of your systems, monitoring and availability the job might be called “Site Reliability Engineer”. If you are working on infrastructure code most of the time and how to deploy code on it, you might be called “Platform Engineer”. And if you are responsible for team culture and dynamics, work processes then you have a title like “Agile coach”. It all parts of the same culture, which is definitely not dead :)

I work as SRE at the moment, but also write a lot of Java and terraform code. My favourite thing to do - knowledge sharing and breaking silos. I am supporting business to the best of my ability. It might mean that instead of building pipelines I will spend majority of my time in meetings, refining requirements or defining the secure architecture. And I am ready to switch context as needed. Automating as much as I can, where it makes sense. I would not go as far as to say “automate everything”. Some tasks needs to be done only once, and if you need to re-do them again it either means that something went horribly wrong (and you do not need to worry about this task in particular) or things are spectacularly great (and once again, repetition of that task would not change the picture).