Earlier this year, I wrote about how Platform Engineering was part of DevOps. More specifically, it ought to be part of DevOps, and things often go wrong when it isn't.
Platform Engineering without DevOps
The founding intention of DevOps was to break down the silo between the people making software. The most apparent wall to remove was the one separating development and operations, which is where the term DevOps came from.
If you build and run an internal developer platform without intentionally collaborating with users, you create a new silo. This is a bad thing.
In the decade since the birth of DevOps, there's been a fruitful research effort by DORA. This has explored the complex relationships between specific practices and outcomes. The rigorous academic study of software delivery has given us many valuable metrics and approaches that make things better for people, performance, and goal attainment.
A platform that ignores DevOps capabilities will likely show all the signs of low-performance software delivery:
- Large batches of work
- Delayed and ignored feedback
- Infrequent releases
- Low stability
- Lack of relevance to users
Platform teams need a high degree of user-centricity to achieve strong adoption rates with developers. A developer should be able to easily use the platform to solve the problems that matter to them. Mandated use of a platform is no substitute for user feedback.
Platform Engineering within DevOps
When you apply DevOps learnings to Platform Engineering, you're more likely to measure and achieve the outcomes and benefits expected from an internal developer platform.
You'll use the MONK metrics and DevEx metrics to track the success of the platform and its impact on the teams who use it. You'll collaborate closely with the platform's users to understand their needs and ensure the platform solves them.
You'll be more likely to succeed now and in the future with careful and deliberate use of DevOps and Team Topologies to ensure you don't fall into the trap of creating a new silo.
You can find many traps described in the patterns and anti-patterns of Platform Engineering.
Moving forward with confidence
Suppose you decided you need to adopt Platform Engineering. You should maximize your chances of short- and long-term success by wrapping it with everything we've learned from DevOps research.
The worst outcome from Platform Engineering would be a return to the days before we removed the development/operations boundary and before the State of DevOps research.
Happy deployments!
