Skip to main content

DevOps is dead, is it serious doctor?

· 7 min read
Idriss Neumann
Idriss Neumann
founder cwcloud.tech

Happy new year everyone 🎉 . Let's start this new year with a new retrospective about DevOps.

There's already a lot of articles and blogposts1 which explains in detail what DevOps is, so I'm going to go over it very quickly in order to be sure that we're on the same page when we're talking about DevOps in this article.

So basically DevOps is a strategic alignment between the stackholders who develop a product and its features (the build) and those who maintain the production (the run). We're supposed to measure the application of DevOps by the success in breaking down the frontiers (or silos) existing between the build and run in a company or organization.

For quite some time now, the DevOps word has drifted away from its original intent by recruiters to directly refer to some technical skills2 which can be valuable assets in oder to implement it. That's why we can read so many "DevOps evengelists" shouting that "devops ain't a role, it's a set of good practices which help to break down silos", and they are right from an evengelist perspective.

However, I personally found as a tech manager which wants to provide tools and technical skills, that we should accept it and comply nowadays. That's why I don't have any issue with adding the DevOps word on CVs or job offers when it comes to select profiles whose role corresponds more to either SRE3 or Platform Engineers. Same thing for tools we're developing like CWCloud. I think the more important thing is to answer the customer's needs. So if they think that DevOps is a set of technical skills, then it's not a serious issue, let's start by approaching them because we're relevant to help rather than correcting them in a dogmatic way.

Moreover, to illustrate this even more, let's see how GitLab is presenting itself:

GitLab: The most-comprehensive AI-powered DevSecOps platform

Before the AI hype, it was defined during years as the complete DevOps toolchain despite the fact that git repositories, CI/CD and GitOps capabilities ain't DevOps and lot of companies which are using GitLab aren't following the DevOps principle at all. I personnaly think it should be the same for people who can help to automate some deployments automations using tech skills like ansible, terraform, helm, whatever.

That been said, let's go back to the point of this blogpost: I personnaly think that DevOps is dead and we're back to the silos like every decades in all the industries which are growing and in this case, because of the move to modern cloud.

First, let's define what modern cloud is: it's basically a matter of providing a layer of abstraction of the complexity of infrastructures via user-friendly APIs which can be directly consumed by product owners, developers, datascientists... in short, stackholders who ain't skilled enough in the field of hosting and managing their apps in production. And those API with different level of abstractions are provided As a Service4.

The modern cloud is now a service which can be externalized using public cloud (by public cloud providers like AWS, GCP, Azure, Scaleway, whatever) or private cloud using modern tools like OpenStack, OpenShift, Kubernetes, FaaS platform... any kind of tools which aims to provide the features teams some sort of autonomy in the deployment of their code.

And that's why, we're assisting to the rize of the silos again:

  • teams of Platform Engineers which are providing the tools to help the developers to deploy their code (images registries, CI/CD pipelines capabilities, serverless engines, observability tools...)
  • teams of SRE5 which are most of the time former developers taking care about the incident in production and giving the information on how to solve those incident in the short term and long term including patching the code directly
  • teams of consumers (developers, product owners, datascientists...) of the platform6
  • teams of OPS who are taking care of the physical infrastructure: hardware, network, low-level system administration

Moreover, the only difference between public cloud and private cloud is the fact that some of the stakeholders from those silos are directly working as employee of the cloud provider. Basically it's a matter of mutualizing human resources in large scale organizations which haven't been really compliant with DevOps since the begining.

So ain't it looks like what we had before the hype of DevOps? What are the differences?

The only difference is in fact the SLA7 and the time to market were really bad for various reasons:

  • lacks of agility in the planing of the different teams which weren't aligned
  • some people were some sort of bottleneck because of a lacks of automation and abstraction
  • former corporate practices frameworks like ITIL or CMMI which were solving everything with ITSM8

And as for the agile methodologies before, DevOps was too much oriented on breaking down the silos which is impossible for every large scale organizations. And because the purpose of any kind of company is to grow, it wasn't a sustainable solution. Methodologies which ain't scalable ain't sustainable at the end.

That been said, is it really an issue if we go back to former silos? I think not, like Agile (and even ITIL, CMMI, COBIT, DDD, TDD, whatever), we're improving by cherry-picking some principle of those methodologies and frameworks when we need it. Of course, we'll continue to improve in the fields of automation, CI/CD, observability and improve our SLA in the incident resolution and our time to market for evolutions using pragmatic engineering, not by religiously following methodologies. Dogmatism and pragmatism are often inherently opposed and as engineers we should stick to pragmatism and focus on solving issues with the best ROI9.

So again, happy new year and let's hope that 2025 will be a new era of improvement. We have plenty of surprises coming in terms of observability and automation (maybe using AI 😱).

Footnotes​

  1. If you're a French speaker, I like very much this article from Katia Himeur Talhi for example. Otherwise, you can ask directly chatGPT for this kind of things, it'll write a similar article that will probably looks like lot of blogpost on the web 🥹 ↩

  2. CI/CD pipelines, deployment automations, observability, scripting... ↩

  3. System Reliability Engineer. If you're not familiar with this concept, I advise you again to read the Katia's article if you can read it or ask chatGPT otherwise 😛 ↩

  4. That's what we're often talking about IaaS, PaaS, DaaS, CaaS, FaaS... ↩

  5. We can see that this team is often the same people who are also doing platform engineering two different roles and purpose but same technical skills so same people ultimately ↩

  6. In the ideal world, those people are supposed to consume directly the platform API's: setting up their Dockerfiles, their CI/CD pipelines... But it's sometimes deleguated to the platform engineers teams for various reasons. For example they might have not enough time to take care of this work or it's still too complicated... I think this issue will be solved with more abstraction, automation and AI because most of the time, those kind of configurations are repetitive and redundant everywhere in the end. And that's also why we're developing CWCloud 😜 ↩

  7. Service Level Agreement ↩

  8. Information Technology Service Management. Basically, operating everything, every department, every people with a ticket tools like Jira, Asana, Mantis, whatever ↩

  9. Return of Investment ↩