Platform Engineering for Software Developers and Architects (KubeCon Talk Recap)
- Daniel Bryant
- 7 days ago
- 4 min read
As someone who has spent years moving between development, operations, and architecture roles, I’ve seen firsthand how rapidly the platform engineering space is evolving. It has been a journey full of lessons, challenges, and exciting discoveries. In my recent talk at KubeCon EU, I aimed to share some of these insights, distilled into actionable guidance for fellow software developers and architects who are navigating this dynamic space.
Check out the recording below, and keep reading for a short summary.
Platforms Are Products: Developers Are Customers
One of the key messages I wanted to drive home is that platform engineering should have a product focus. As platform builders, developers are our customers. They rely on the platform to reduce complexity, improve delivery speed, and remove friction. It’s our responsibility to make their lives easier. Too often, I see platform initiatives falling into the trap of merely rebranding DevOps or focusing too much on infrastructure.
A good platform delivers tangible value. This means offering self-service APIs, useful and opinionated abstractions, and plenty of automation (the “three As”). But it doesn’t stop there. Knowledge and support are equally critical. A great platform team creates an environment where developers can focus on solving business problems without being bogged down in infrastructure and low-level tooling. This helps minimise cognitive load and maximises developer productivity.
Platform and Software Architecture: A Symbiotic Relationship
In today’s world, platform architecture and software architecture are deeply intertwined. Gone are the days when developers could just ship code and hope platform teams would handle the rest. The rise of microservices, Kubernetes, and cloud-native technologies has made this clear.
We now live in an environment where collaboration between developers and platform engineers is non-negotiable. Developers need to understand platform constraints, such as compliance and security, while platform teams must support developers in staying productive and in flow. The result is a symbiotic relationship where both sides learn from and depend on each other.
The Three-Tier Model of Platform Architecture
To help demystify the complexity of today’s tooling, I introduced a simple yet powerful three-tier model of platform architecture:
Application Layer (Code, Ship, Run): This is where developers primarily work. It includes developer portals, CLIs, and declarative configuration.
Infrastructure Composition Layer (Plan, Build, Maintain): Managed by platform engineers, this layer covers infrastructure as code, Terraform, Crossplane, and other provisioning tools.
Platform Orchestration Layer (Design, Enable, Optimise): The most novel and essential layer today. It acts as the glue between the other two. Tools like Kratix, Crossplane compositions, Argo Workflows, and Flux live here, orchestrating resources and workflows.
This orchestration layer is still maturing, but it is vital to building scalable, developer-friendly platforms. I see it as a core focus area for the future of platform engineering.
From Hexagonal to Microservices to Cell-Based Architectures
Reflecting on my career, I shared how architectural paradigms have evolved and how they influence platform engineering today.
Hexagonal Architecture taught us the importance of clean boundaries and loose coupling, which is still highly relevant.
Microservices took modularisation to another level but introduced challenges with complexity, observability, and deployment.
Cell-Based Architectures, which are emerging now, aim to reduce blast radius and improve fault tolerance. However, they present new challenges in abstraction and orchestration.
What ties these architectural evolutions together is the need for clear abstractions and careful orchestration to manage complexity and empower developers.
Golden Bricks vs Golden Paths
A concept I’m actively exploring is golden bricks instead of golden paths. For years, we’ve talked about paved paths as the ideal developer experience. But rigid golden paths can become restrictive, turning into golden cages.
Golden bricks are reusable, composable components that developers can combine to create their own paved roads. This approach encourages autonomy and creativity while maintaining guardrails. It also aligns better with the diverse needs of teams and projects.
At Syntasso, this idea is influencing our thinking around Kratix and how we help organisations balance governance with flexibility.
Measuring Success: Why Metrics Matter
To make platform engineering successful, we must be able to demonstrate its impact. I highlighted the importance of metrics and shared some of my favourite frameworks, including DORA, SPACE, and DevEx. These help measure:
Business outcomes (such as speed and reliability)
Developer experience (cognitive load, sati
sfaction, feedback loops)
Platform adoption and overall health
In particular, I like Camille Fournier’s and Ian Nowland’s framework of Impact, Guardrail, and Product Health metrics that they provide in their Platform Engineering O’Reilly book. This gives platform teams a structured way to track performance, spot issues, and communicate value up and down the organisation.
Designing for Progressive Disclosure
One of the most important design principles in platform engineering today is progressive disclosure. Developers shouldn’t be overwhelmed with configuration options and complexity upfront.
Progressive disclosure allows us to show only the essential options at first. As developers become more advanced or their needs grow, they can access more detailed configuration and customisation options. This approach improves day-one onboarding without sacrificing power and flexibility for power users.
Final Thoughts: Software Delivery is a Team Sport
If there’s one thing I’ve learned, it’s that software development and platform engineering are team sports. Success depends on collaboration, shared understanding, and strong communication. APIs, abstractions, and automation are the technical enablers, but people and processes make them successful.
For platform engineers, this means working closely with developers to understand their needs and constraints. For developers, it means respecting the challenges of operating platforms at scale and engaging with platform teams as partners.
Ultimately, our mission is to build platforms that are intuitive, flexible, and empathetic. Platforms should empower developers to do their best work, not constrain them with unnecessary complexity.
Comentarios