Introduction

Delivering software requires a diverse range of skill sets, from infrastructure provisioning and development to load testing, requirement analysis, and project management. Additionally, the knowledge requirements in these areas keep shifting. It would be unfair to require each senior developer to be an expert in all of these fields. The industry attempts to cater to this by introducing various roles of expertise to facilitate team assembly and ensure that we cover all the previously mentioned areas. DevOps engineer is one of those roles.

This blog post argues that this role used to make a lot of sense but has, to a large extent, outplayed its part in modern cloud-first software development projects. DevOps should be tightly integrated into everyday modern development, not as a role but as a methodology.

DevOps

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.

Instead of one team building an artifact and sending it to the operations part of the organization, the DevOps methodology advocates that a team takes ownership all the way into production. Additionally, the software is looked after in production by the same people that built it. However, DevOps has traditionally been discussed as a role or a team.

DevOps responsibilities evolutions

Let's examine some of the previously typical DevOps engineer responsibilities and how they have evolved in the cloud-native area. Some of the responsibilities are:

• Continuous Integration and Continuous Delivery (CI/CD)
• Infrastructure provisioning
• Testing and quality assurance
• Monitoring and logging

CI/CD

In one of my earliest projects, setting up a build server and tooling around deployment was a somewhat larger undertaking. I would SSH into machines, patch them, update the OS, and keep any SDKs on specific versions. Not to mention making sure that the different SDKs did not break older builds or introduced unoticed upgrades. Remember TeamCity on-prem, anyone?

Now, I utilize fully managed GitHub or GitLab build servers. I do not want access to them other than have them build my code. Both GitHub and GitLab have tooling that enables us to define both building and deploying software as code. The best ones to set it up are the ones who know the code and project best. Not a dedicated DevOps team or engineer that is remotly seperated from the domain.

Infrastructure provisioning

As with CI/CD, environment provisioning was also time-consuming and error-prone. However, with Infrastructure as Code (IaC), we can now define everything as code, test it, and have it under version control. One command brings provisions to the entire infrastructure environment according to the code. Additionally, cloud providers offer SaaS solutions that elevate the abstraction layer. The development team can focus on configuring IaaS and SaaS, rather than worrying about the technical details.

Alan Kay had the following quote:

"People who are really serious about software should make their own hardware."
- Alan Kay (early 1980)

Maybe we can change it a bit, but still keep the essence:

"People who are serious about software should care about the infrastructure."
-Fredrik Klingenberg (now)

Testing and qualitassurancece

In one of my early projects, we had a dedicated User Acceptance Testing (UAT) environment. Here, the customer and a dedicated team, typically the DevOps team, tested a rather large set of new functionalities. They would use a suite of testing tools and try to break the software.

The main problem here is that no one knows better how to break a piece of software than the authors themselves. Additionally, these tools are often offered as SaaS and can be automated by the development team themselves.

With the advent of continuous integration and feature flags, we aim to automate many of these tests and release them continuously into production. Even unfinished code is pushed into production. The team can turn on features for a specific subset of our customers.

Alleviating developers from quality assurance, load testing, functional testing, and customer engagement is doing them a disservice.

Monitoring

Traditional monitoring often required setting up and maintaining complex monitoring infrastructure, including servers for metrics collection, dashboards, and alert management systems. DevOps teams typically owned these responsibilities, acting as gatekeepers for monitoring tools and practices.

However, in the cloud-native era, monitoring has undergone significant evolution. Cloud providers and third-party services now offer sophisticated monitoring solutions as SaaS products, making it easier for development teams to implement and manage their monitoring without dedicated DevOps support. These tools often come with built-in integration capabilities, allowing developers to instrument their code directly and own the full observability of their applications.

Platform Engineering

Platform Engineering emerges as a natural evolution from traditional DevOps practices. It focuses on building and maintaining scalable, self-service platforms that enable development teams to efficiently deploy and manage their applications. Instead of having DevOps engineers directly handle infrastructure and deployment tasks, Platform Engineering teams create standardized tools, workflows, and infrastructure templates that development teams can use independently.

AKS example

One capability example that the platform team might provide is the Azure-managed Kubernetes offering AKS. The platform team provisions the AKS, enables the correct subset of features based on the organization's needs, and installs Cloud-Native tooling, such as Cert-Manager. Additionally, the platform team must provide good documentation.

Conclusion

The traditional DevOps engineer role, although historically important, has undergone significant evolution in the cloud-native era. Modern development practices, cloud services, and Platform Engineering have transformed how we handle operations, deployment, and infrastructure. Rather than having dedicated DevOps engineers, these responsibilities are increasingly integrated into development teams, enabled by self-service platforms and tools.