Platform Engineering vs. DevOps: What's behind Internal Developer Platforms?
Alexander Hoeft and Artem Lajko explain why companies should create a solid automation basis before building an Internal Developer Platform.
(Image: IM Imagery / Shutterstock.com)
Internal Developer Platforms (IDPs) are receiving a lot of attention in the cloud-native scene. In their presentation at the CloudLand 2025 Cloud Native Festival, Alexander Hoeft and Artem Lajko explain what lies behind the concept, how it differs from classic DevOps approaches, and why many organizations are not yet ready to build such a platform.
The basic principle of an IDP is to provide development teams with a central platform through which they can use infrastructure and services in self-service. Instead of having to take care of provisioning, configuration, and operation themselves, developers access pre-built, standardized components. This is intended to reduce cognitive load and increase productivity.
(Image:Â cloudland.org)
From May 19 to 22, 2026, interested parties will find a packed CloudLand Cloud Native Festival line-up with more than 200 highlights – including the two new topic areas "Open Source" and "Platform Engineering". Artem Lajko will also be back with a presentation: "When Building One Platform Isn’t Enough".
Tickets for the festival and accommodation in Heide Park Soltau can be booked via the festival homepage.
Hoeft and Lajko emphasize a crucial point that is often overlooked in discussions: the role of a Platform Engineer is fundamentally different from that of a DevOps Engineer. While DevOps Engineers typically work directly in product teams, combining development and operations tasks, Platform Engineers act as service providers for the entire organization. They build and maintain the platform that other teams “consume,” thus treating their needs similarly to how a product team treats its end-users.
However, anyone who believes they can start building an IDP right away is clearly told no by the speakers. Organizations should first have a robust foundation of automation in place before building a platform on top of it. Specifically, Hoeft and Lajko recommend that basic processes such as infrastructure as code, CI/CD pipelines, and automated tests must already be established and mature. Without this level of maturity, there is a risk of not reducing complexity but merely shifting it to a new level.
Backstage as an IDP component: Not a self-runner
A concrete tool that regularly appears in the IDP discussion is Backstage, the open-source project developed by Spotify and now managed by the CNCF. It serves as a developer portal and can function as a central interface for an IDP. However, Hoeft and Lajko warn of typical pitfalls in its use: Backstage is not a turnkey solution but a framework that requires considerable adaptation and maintenance effort. Those who introduce it without planning sufficient resources for continuous development will quickly end up with a half-finished platform that is not adopted by the development teams. Furthermore, there is a risk of operating Backstage purely as a service catalog without actually building the underlying automation layers.
Trend or sustainable development?
The central question of the presentation – whether IDPs are just a trend – is answered with nuance by the speakers. The underlying concept of offering developers infrastructure as a product is by no means new and has already proven itself in large technology companies. However, each organization must realistically assess its maturity level. An IDP is therefore not a project that can be set up on the side, but a strategic decision that affects personnel resources, organizational structure, and technical prerequisites equally.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmung wird hier eine Vimeo-Video (Vimeo LLC) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Vimeo LLC) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
About the Speakers
Alexander Hoeft and Artem Lajko work for the IT consulting company iits-consulting. Hoeft works there as a Senior Platform Engineer and is also active as a blogger and speaker at conferences. Lajko is Head of Platform Engineering at iits and also a Platform Engineering Ambassador and Kubestronaut. He is also a blogger, speaker, and author of the book (“Implementing GitOps with Kubernetes”).
(map)
