Is DevOps dead?

Have you ever wondered why, despite so much investment in DevOps, some companies still face so many problems implementing agile software development and delivery practices? Why is it that in some organizations, the software lifecycle continues to be a minefield, full of bottlenecks and pain points for both developers and operations teams?

Lately, we’ve seen the emergence of a new concept: Platform Engineering. Many say this is just a new name for good old DevOps, while others argue that it represents a natural and necessary evolution. What’s really happening? Has DevOps died? Or are we just witnessing the next phase of its evolution?

Let’s explore this fascinating topic and understand what Platform Engineering really means, how it differs from traditional DevOps, and why you should pay attention to this trend that, according to Gartner, will be adopted by around 80% of large software engineering organizations by 2026.

A brief history of operational software development

To understand where we are, we need to know where we came from. Let’s go back in time and take a quick retrospective:

SysAdmin denying a deploy to a junior dev

The SysAdmin era (late 90s and early 2000s)

Remember the days when we had a single gatekeeper for all infrastructure operations? The famous SysAdmin was the gatekeeper who controlled access to everything. If a developer needed to do anything related to infrastructure, they had to go through this gatekeeper.

This was the famous "throw it over the wall" approach: developers wrote the code, and when they were done, they threw it over the wall for the operations team to implement and manage. Inevitably, this resulted in frustrating experiences on both sides of the wall.

It was common to see developers finishing their applications and updating via FTP, editing PHP files directly on the server with FileZilla, causing that hot deploy anxiety. Nostalgia for some, trauma for others!

FireFTP in the 2000s

The DevOps revolution (mid-2000s to today)

When the cloud started gaining traction, with AWS emerging in 2006, the DevOps concept began to establish itself as the new gold standard for engineering teams. DevOps promised to unite development and operations, creating a culture of collaboration and automation that would accelerate software delivery.

"You build it, you run it" became the mantra, and the traditional divide between development and operations began to dissolve in many organizations. This brought significant improvements in areas like scalability, availability, and operability, but it also significantly increased the complexity of day-to-day operations.

Suddenly, engineers needed to master 10 different tools, Helm charts, Terraform modules, and much more just to deploy and test a simple code change in one of the many environments of their microservices setup across multiple clusters.

Where did DevOps fail?

The problem is that, throughout this evolution of the toolchain, the industry somehow decided that the division of labor—which has proven successful in virtually every other sector of the global economy—was not a good idea for software development. Instead, the DevOps paradigm was advocated as the path to achieving a high-performance setup.

The idea was noble: developers should be able to deploy and run their applications and services end-to-end. However, for most companies, this approach is quite unrealistic. While it works well for advanced organizations like Google, Amazon, or Airbnb, it’s far from trivial to replicate true DevOps in practice for most other teams.

The main reason is that most companies are unlikely to have access to the same level of talent and resources that can be invested solely in optimizing workflows and developer experiences.

The anti-patterns of DevOps

What tends to happen when a common engineering organization tries to implement true DevOps is that a series of anti-patterns emerge. A classic example is what happens in many development teams when the organization decides to implement DevOps and remove a formal operations role or team.

Developers (usually the more experienced ones) end up taking on the responsibility of managing environments, infrastructure, etc. This leads to a setup where "shadow operations" are performed by the same engineers whose work in terms of coding and product development is most valuable.

Everyone loses in this scenario. The senior engineer is now responsible for configuration and needs to resolve requests from more junior colleagues. The broader organization is now misusing some of its most expensive and talented resources and cannot ship resources with the same speed and reliability.

Industry studies confirm this reality. A recent survey showed that in 44% of low-performing organizations, some developers perform DevOps tasks on their own and constantly help less experienced colleagues. Compare this to high-performing organizations, where 100% have successfully implemented a true "you build it, you run it" approach.

Ticket system used in the 2000s

The ticket office: a symptom of a bigger problem

A clear symptom that your organization is suffering from these anti-patterns is what many call the "ticket office"—the need to open countless tickets to get anything related to infrastructure or deployment done.

Have you worked in a company where, for every new application or infrastructure change, you had to fill out several different forms? Where if you chose the wrong template, you’d get an email saying, "You opened the wrong ticket, please open a new one using the correct form"?

This ticket office approach is a clear sign that something isn’t working well in an organization’s DevOps culture. It creates bottlenecks, frustrates developers, and prevents the rapid delivery of value to end users.

The rise of Platform Engineering

So, what’s the difference between low- and high-performing organizations? How do the best teams ensure that their developers can run their applications and services without constantly needing help from senior colleagues?

The answer: they have a platform team building an Internal Developer Platform (IDP). The Puppet State of DevOps 2020 Report clearly shows the correlation between the use of internal platforms and the degree of DevOps evolution in organizations.

Platform Engineering is defined as the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product, often referred to as an "Internal Developer Platform," that covers the operational needs of the entire application lifecycle.

Backstage IDP

Internal Developer Platform (IDP)

An IDP encompasses a variety of technologies and tools, integrated in a way that reduces the cognitive load on developers while maintaining essential context and underlying technologies. It helps operations structure their setup and enable developer self-service.

The best engineering organizations configure internal platform teams that build these IDPs. By using these platforms, developers can choose the right level of abstraction to run their applications and services, depending on their preference.

For example, if a developer likes tinkering with Helm charts, YAML files, and Terraform modules, great, they can do that. If they’re a junior frontend developer who doesn’t care if the app is running on EKS, fantastic, they can simply self-serve an environment that comes fully provisioned with everything they need to deploy and test their code, without worrying about where it’s running.

Golden paths and paved roads

Platform Engineering seeks to create "golden paths" and "paved roads" for developers. But what does this mean in practice?

Most CI/CD setups today focus simply on updating images. The CI builds them, updates the image path in the definitions, and that’s it. This covers most deployment use cases. But things start to get more complex and time-consuming when we need to do anything beyond this basic workflow, such as:

• Adding environment variables and changing settings
• Adding services and dependencies
• Rolling back and debugging
• Creating a new environment
• Refactoring
• Adding/changing resources
• Applying RBAC (role-based access control)

The list goes on. Platform Engineering is about connecting all of this to a paved road. Instead of letting everyone operate everything and having to understand the entire toolchain to do so, platform engineers provide the glue to connect everything into a consistent self-service experience.

When does Platform Engineering make sense?

A common misconception is that Platform Engineering only makes sense for large teams. And while if your team consists of 5 developers, a platform team and an IDP are certainly overkill, once your organization grows beyond the 20-30 developer mark, an Internal Developer Platform is probably something you should consider, sooner rather than later.

There are countless stories of teams that delayed building an IDP for too long and had to suffer unnecessary hardships. For example, imagine your only DevOps hire leaves the company, and your entire organization can’t deploy for weeks.

Principles of Platform Engineering

Many organizations are waking up to the benefits of Internal Developer Platforms and developer self-service. To quote the Puppet State of DevOps 2021 Report, "The existence of a platform team does not inherently unlock higher DevOps evolution; however, large platform teams expand the benefits of DevOps initiatives."

Here are some useful principles that are a common thread among successful platform teams and self-service-oriented organizations:

Clear mission and role

The platform team needs a clear mission. An example: "Build reliable workflows that enable engineers to independently interact with our setup and self-serve the infrastructure they need to run their applications and services."

Whatever makes the most sense for your team, make sure it’s defined from the start. It’s also extremely important to establish a clear role for the platform team, which should not be seen as just another help desk that creates environments on-demand, but rather as a dedicated product team serving internal customers.

Treat your platform as a product

Expanding on the product focus, the platform team needs to be driven by a product mindset. They need to focus on what provides real value to their internal customers, the application developers, based on the feedback they receive. Make sure they ship features based on this feedback loop and don’t get distracted playing with the latest shiny new technology that just came out.

Focus on common problems

Platform teams prevent other internal teams from reinventing the wheel by addressing shared problems repeatedly. It’s crucial to figure out what these common problems are: start by understanding developer pain points and friction areas that cause slowdowns in development. This information can be gathered both qualitatively through developer feedback and quantitatively by observing engineering KPIs.

The glue is valuable

Often, platform teams are seen as pure cost centers because they don’t ship any real product features to the end user. After all, they’re just gluing our systems together. This is a very dangerous perspective, and of course, this glue is extremely valuable.

Platform engineers need to embrace and internally announce their value proposition. Once you’ve designed the golden paths and paved roads for your teams, the primary value you create as a platform team is being the adhesive glue that binds the toolchain together and ensures a seamless self-service workflow for your engineers.

Don’t reinvent the wheel

Just as platform teams should prevent other teams within the organization from reinventing the wheel and finding new creative solutions to the same problems, they should avoid falling into the same fallacy. It doesn’t matter if your homegrown CI/CD solution is superior today, commercial vendors will eventually catch up.

Platform teams should always ask what their differentiator is. Instead of building internal alternatives to a CI system or a metrics dashboard and competing with companies that have 20 or 50 times their capacity, they should focus on the specific needs of their organization and adapt off-the-shelf solutions to their needs.

The modern engineering organization

According to the Puppet State of DevOps 2021 Report, "highly evolved organizations tend to follow the Team Topologies model."

Published in 2019, the book Team Topologies by Matthew Skelton and Manuel Pais has become one of the most influential blueprints for modern team setups in successful engineering organizations. According to their blueprint, there are four fundamental topologies around which teams should structure themselves:

1. Stream-aligned team: aligned with a workflow of a business domain segment, they work on the core business logic.
2. Enabling team: helps stream-aligned teams overcome obstacles and detects missing capabilities.
3. Complex subsystem team: formed whenever significant mathematical/technical expertise is required.
4. Platform team: provides a compelling internal platform to accelerate delivery by stream-aligned teams.

As illustrated in the model, the platform team is transversal to all others, ensuring a smooth self-service workflow from code to production.

Why is Platform Engineering emerging now?

But why is this approach gaining so much traction now? Several factors contribute to this:

1. The growing complexity of cloud-native

As organizations adopt microservices architectures and cloud-native technologies, the complexity of development operations increases exponentially. Developers have to deal with containers, orchestration, networking, security, and much more.

2. The DevOps talent shortage

There’s a significant shortage of professionals with DevOps and cloud infrastructure expertise. Platform Engineering allows organizations to better leverage these scarce resources by creating reusable solutions that benefit the entire organization.

3. The pressure for speed and quality

Companies face constant pressure to deliver software faster without compromising quality or security. Platform Engineering promises to accelerate development without sacrificing these critical aspects.

4. The need for large-scale standardization

As organizations grow, the need for standardization becomes more pressing. Platform Engineering offers a way to enforce standards without creating bottlenecks in the development process.

Is DevOps dead?

Returning to our original question: is DevOps dead? The short answer is: no, definitely not.

DevOps isn’t dead—it’s evolving. Platform Engineering isn’t a replacement for DevOps but rather a natural evolution that addresses some of the practical limitations of implementing DevOps in real-world organizations.

DevOps laid the foundation: culture of collaboration, automation, measurement, and sharing (CAMS). Platform Engineering builds on these foundations, providing a more defined and sustainable framework for implementing these principles at scale.

At its core, Platform Engineering is the maturation of DevOps from a philosophy to an operational framework. It provides a clear structure for organizations that want the benefits of DevOps without requiring every developer to become an expert in all the tools and technologies involved.

Transitioning to Platform Engineering

If you’re considering transitioning to Platform Engineering, here are some steps to consider:

1. Assess your current maturity

Start by identifying where your organization is today in terms of platform capability. You can use the Platform Engineering Capability Model to outline where your organization stands in capabilities like investment, adoption, governance, provisioning and management, interfaces, and measurement/feedback.

2. Identify your goals

Clearly define what you hope to achieve with Platform Engineering. This could include:

• Increasing application quality, reducing bugs and issues during release
• Improving security, reducing the number of security incidents
• Lowering risk through better compliance
• Accelerating time to deliver business value
• Reducing development or operations costs

3. Build your team

For Platform Engineering to succeed, you need a dedicated team. This team should have a mix of skills, including development, operations, security, and a strong product mindset.

4. Start small

Don’t try to solve all problems at once. Start with a "thinnest viable platform" (TVP) and grow from there. Focus on solving the most pressing problems your developers face.

5. Cultivate the right culture

Platform Engineering requires an organizational culture that values both autonomy and standardization. This may require changes in how teams interact and how success is measured.

In conclusion...

Platform Engineering represents a significant evolution in how we think about software development and deployment. It addresses many of the practical difficulties organizations face when trying to implement DevOps at scale, providing a more tangible and operational framework.

DevOps isn’t dead—its core principles of collaboration, automation, measurement, and sharing are more relevant than ever. Platform Engineering is simply a more mature manifestation of these principles, adapted to the realities of modern software organizations.

As the complexity of software development continues to increase, Platform Engineering will likely become even more important. Organizations that adopt this approach will now be well-positioned to tackle tomorrow’s challenges.

So, is DevOps dead? No, it’s just grown and matured into the form of Platform Engineering, preparing us for the next chapter in the ongoing evolution of how we build and deliver software.

After all, as an old sysadmin would say, "the only constant in IT is change." And change, in this case, is definitely for the better.