Is DevOps dead? That claim keeps appearing on the internet, with people arguing that platform engineering is taking over. In this talk, which I gave at the Developer Experience Conference at Roche in Poznan, Poland, I explain why DevOps is absolutely not dead and why platform engineering is the key to making it actually work at scale.
The real problem with DevOps#
We all know the benefits of DevOps: increased deployment frequency, faster lead time, faster time to restore services, and lower change failure rates. Science confirms this through the annual State of DevOps reports. Companies doing DevOps achieve faster time to market, higher quality, better customer satisfaction, and attract top talent.
But there is a problem. Modern software development with DevOps comes with a massive technical stack. Our battle cry is “you build it, you run it,” which sounds great until you realise what that actually means. Every team needs infrastructure (cloud and on-prem), runtime environments (Docker, Kubernetes), CI/CD tools (GitLab, GitHub), monitoring (Prometheus, Grafana, Dynatrace), security scanning (Snyk, SonarQube), collaboration tools (Jira, Confluence), and cost management on top of everything. And somewhere in there, the team also needs to build an actual application.
In larger companies, you get multiple of these stacks across different products or silos. The result: inconsistencies, lack of operational experience, tool complexity, and cognitive load that crushes developer productivity. The rate of new features goes down.
“Think about bigger companies. There you have multiple of these stacks for potentially each one of the products. The cognitive load for the developers is just too high.”
The digital factory: connecting strategy to execution#
Before diving into the solution, I want to paint a picture of what modern companies should look like. Imagine a drone company. The board has a vision to increase market share. They create a portfolio of ideas: maintenance drones, fast drones, drones that carry high loads. They prioritise and pass the best idea down to product management. Product managers break it into features: better battery, better motors, software updates. Teams pick up the work.
Now the new motor team needs to start immediately. Without a platform, they would spend weeks setting up their development environment. With a platform team providing a standardised continuous delivery pipeline, they start within minutes.
But the story does not end at delivery. Telemetry data from the product flows back to the teams for continuous improvement and back to the board for strategic decisions: are we gaining market share? Should we invest more or pivot? This feedback loop from strategy through execution and back is what I call the Digital Factory.
Platform engineering: the foundation#
Where we are today in many companies: different teams use different tools, build their own local environments, and bring non-standardised solutions into production. The tool landscape is enormous, and every team picks what is currently trendy.
Where we need to go: platform engineering. Teams work on a standardised platform and bring software into production in a standardised way. The platform provides a defined set of services and tools. This is what I call the industrialisation of software engineering.
The target operating model is clear. Product teams focus on feature delivery. The platform team creates a self-service platform with all the skills needed to support the product teams. A large chunk of the technology stack moves to the platform team, while the product-relevant stack stays with the product team.
How the platform actually works#
The platform team builds an internal product. The customers are the product teams. The platform provides capabilities like observability, security, CI/CD, identity management, and infrastructure provisioning.
Here is the critical distinction. If the platform provides monitoring capabilities, that means the platform team delivers self-service tools for standardised monitoring. The product teams then use those tools to monitor their own applications. The product teams still practice DevOps. The platform team does not run the products, that would take us back to the old world of separated development and operations.
“The platform team will not run or maintain the products of the product teams. That’s a very important distinction to the old IT model.”
Architecture: floating platforms and adapters#
Two architecture principles are essential. First, use adapters for every integrated tool. In 22 years, I have seen many tools come and go. With adapters, you can swap GitLab for GitHub or vice versa without disrupting developers.
Second, build a floating platform following Gregor Hohpe’s concept. Integrate tools and cloud providers but never abstract them away. Do not duplicate features. If you do, your platform starts to sink under its own weight. A floating platform sits on top of the tools, making them accessible in a governed, streamlined way.
And here is something important: AI is not separate from this. It is a capability of the platform. When you have such a platform, AI and ML capabilities are governed, standardised, and available enterprise-wide. Without this, everyone just uses whatever tools are out there, ungoverned and unstandardised.
The platform in action#
I demonstrated the Zühlke Platform Plane, which we built together with LGT. Here is what it delivers:
- Self-service everything: Create repositories, deploy applications, provision databases, all without tickets.
- Single sign-on: One identity across all tools. Onboard a developer in the morning, offboard in the evening. Access to everything is managed centrally.
- Partner integration: External companies bring their own identity, get integrated via Microsoft Entra, and manage their own people.
- Standardised services: Need a MySQL database, MongoDB, or Kafka? One click gives you a governed instance with correct naming, backups, logging, and monitoring already configured.
- Security by default: All repositories and container images are continuously scanned. Provenance tracking shows exactly who introduced which change.
- AI-powered tools: Documentation chatbot, Docker image analysis, log analysis. When everything is in one platform, creating AI use cases is like playing Lego.
- FinOps and emissions tracking: Teams see their costs and carbon footprint right in the platform.
- Pipelines and runners: Self-hosted runners, high-performance pools, and even virtual machines for mobile development.
- API explorer: All OpenAPI specifications across the enterprise in one place.
“When a developer deploys an application, monitoring, logging, dashboards, everything is automatically provided. The cognitive load on the development side goes down.”
Key takeaways#
- DevOps is not dead: It needs a platform to work at scale. Platform engineering is the enabler, not the replacement.
- Build a self-service portal: No ticket ops. Enable teams to do everything they need on their own.
- The platform is an internal product: With internal customers (the product teams) and a dedicated platform team that builds and maintains it.
- Architect for change: Use adapters and the floating platform concept to stay flexible.
- AI is a platform capability: Govern it, standardise it, and offer it through the platform instead of letting everyone go their own way.
- Developer experience matters: When developers get monitoring, security, and infrastructure out of the box, they can focus on what actually creates business value.
- Platform engineering is the foundation of the digital factory: It enables teams to do DevOps and continuously deliver value. We are entering the age of industrialisation of software development.