Platform Engineering for Developers, Architects & the Rest of Us • Daniel Bryant • GOTO 2025

Daniel Bryant, in his presentation on Platform Engineering, distills 20+ years of experience into key concepts, aiming to provide a clear understanding for software developers, architects, and platform engineers alike. He emphasizes three core messages:

Core Goals of Platform Engineering

1. Product Focus: Platform engineering must adopt a product-centric approach, treating developers as its primary customers. The platform is not merely a collection of tools, but a compelling internal product. This requires KPIs and OKRs, just like any external product.
2. Symbiotic Architectures: Platform architecture and software architecture are deeply intertwined. Mistakes made at one level can significantly impact the other, underscoring the need for careful design at all architectural layers.
3. The Prize: APIs, Abstractions, and Automation: The true value lies in well-designed APIs, effective abstractions, and robust automation, rather than just swapping out underlying tools. Universal software engineering principles like coupling and cohesion apply equally to platform components and their configuration.

Bryant adopts Evan Botcher’s definition of a platform as a “sociotechnical thing” that provides self-service APIs, tools, services, and knowledge, aiming to deliver product features at a higher pace with reduced coordination and increased safety. Gartner’s view aligns, highlighting improved developer experience, self-service, and automated infrastructure. Ultimately, platform goals translate into business value: going faster (increased revenue), decreasing risk (staying off the news), and increasing efficiency (saving money).

Platform Architecture: A Three-Layered Approach

Bryant proposes a consistent three-layered architecture observed across various industry models (Gartner, Keith Morris, Camille Fournier, Dapper):

1. Application Choreography Layer: This is where developers primarily operate, focusing on the Software Delivery Life Cycle (SDLC) by coding, shipping, and running applications (e.g., using Backstage, Score, Radius).
2. Platform Orchestration Layer: Positioned as the “smart glue” layer, it manages the platform’s life cycle, provides APIs for platform services, and enforces policies. This is the domain of tools like Cratics, Crossplane, and Humanitec, where raw infrastructure primitives are abstracted for developer use.
3. Infrastructure Orchestration/Composition Layer: The realm of SREs, operators, and sysadmins, dealing with the Infrastructure Life Cycle through Infrastructure as Code (e.g., Terraform, Crossplane).

Crucially, each layer or team must own its flow of value from idea to production. Any interruption (e.g., requiring tickets for infrastructure changes) disrupts this flow. Integrating concepts from Team Topologies, Bryant advocates for providing “X as a Service” (e.g., Postgress as a Service, or business-specific services like “Know Your Customer as a Service”). This model offers low cost, clear boundaries, and focuses on consumer satisfaction, aligning perfectly with the “platform as a product” philosophy.

Architectural Evolution and Lessons Learned

Bryant traces the evolution of software architecture and its impact on platforms:

• Monoliths to Hexagonal Architectures: Moving from highly coupled, layered monoliths to hexagonal architectures enabled loose coupling, better testing, and clearer encapsulation of dependencies (e.g., database adapters).
• Microservices and Cognitive Load: While microservices promoted cohesive, loosely coupled services, they significantly increased developer cognitive load due to the need for rapid provisioning, monitoring, and deployment capabilities that many organizations lacked.
• DevOps and Scaling Challenges: DevOps principles were transformative for smaller teams, fostering cross-pollination. However, at enterprise scale, the proliferation of independent “DevOps teams” making disparate technology choices (e.g., logging frameworks) led to increased toil and reduced centralized control, as evidenced during events like Log4Shell.
• PaaS (Heroku, Cloud Foundry): These platforms offered prescriptive “golden paths” for developers, providing high productivity but often sacrificing flexibility, creating a “golden cage” for use cases outside the platform’s opinionated scope.
• The “Puppy for Christmas” Anti-Pattern: Bryant warns against giving developers templated code (e.g., Terraform scaffolding) without also providing ongoing maintenance and upgrade support. This shifts the operational burden to developers who may lack the expertise, turning an initial gift into a long-term chore.
• Evolution of Platform Component Delivery (Netflix OSS to Sidecars/Dapper): Early SDK-based platform components (Netflix OSS) led to implementation-level coupling (e.g., JVM-only). This evolved to language-agnostic sidecar patterns (Prana, Dapper), which expose platform capabilities via HTTP APIs, simplifying consumption across diverse technology stacks. Dapper’s architecture itself exemplifies the three-layered model.
• Golden Bricks vs. Golden Paths: Instead of rigid “golden paths,” Bryant advocates for providing “golden bricks” – composable, opinionated building blocks (like Lego bricks) – that developers can assemble to create tailored solutions. This allows for both standardization and flexibility, enabling teams to build their own bespoke golden paths.
• Cell-Based Architecture: Briefly touched upon as a microservices++ approach for regional deployments (e.g., in banks), it highlights the challenge of “fleet management” – how to consistently upgrade and manage numerous isolated deployments of services at scale.

Key Insights for Platform Success

1. Developer Experience (DevEx) is User Experience (UX): A platform’s success hinges on its user-friendliness. This means designing API-first control planes, with CLIs and UIs built on top of robust APIs, avoiding the common mistake of embedding business logic solely in presentation layers (portals).
2. Minimize Cognitive Load & Progressive Disclosure: Platforms should simplify complex underlying infrastructure. APIs should offer progressive disclosure: a simple interface for common tasks, with advanced options available for more complex configurations.
3. Abstraction and Empowerment: Developers are “magicians,” not just consumers of magic. Platforms should empower them to compose solutions from well-understood abstractions, adhering to principles like CUPID (Composability, Unix principles, Predictability, Idempotency, Durability), Single Responsibility Principle, and Least Surprise. Critical is avoiding leaky abstractions that expose underlying implementation details, creating unwanted dependencies.
4. Customer and Product Focus: Platforms are internal products for developers, demanding user-centric design that genuinely solves problems. Thoughtworks’ “Platform as a Product” and Sarah Wells’ work at the FT are cited as exemplary models.

Measuring Platform Success

Bryant emphasizes the importance of defining clear metrics for platform success:

• Metrics Frameworks: He references Camille Fournier and Ian Nolan’s model of Impact, Guardrail, and Product Health metrics (e.g., lead time to delivery, change failure percentage, platform adoption). He also distinguishes between leading indicators (onboarding time, pull request time) and lagging indicators (app retention, upgrade cycle time, incidents).
• DevEx Frameworks: While DORA metrics are excellent for gaining C-level buy-in on delivery performance, they are primarily delivery-focused. The SPACE framework offers a more comprehensive but complex view. Bryant highly recommends the DevEx / DX Core 4 framework as a balanced approach to measure various aspects of developer experience and platform success.

Conclusion

Reiterating his core messages, Bryant underscores that platform engineering’s shift from traditional DevOps implies developers are customers demanding product-focused solutions. API-first design is crucial, enabling collaboration across various business functions (Dev, Ops, InfoSec, Finance). Universal engineering principles like coupling, cohesion, and abstraction are vital for platform design. Finally, the emphasis remains on composability – building “golden bricks” rather than restrictive “golden paths” – to create flexible, business-fit platforms that empower developers and drive organizational efficiency.

• Tags:
• Devops
• Microservices
• Platform Engineering
• DORA Metrics
• Kubernetes
• Internal Developer Platform
• DevEx
• Software Architecture
• APIs
• Developer Experience
• Infrastructure as Code
• Abstraction
• Cognitive Load
• DX Core 4
• Team Topologies
• Product Thinking
• SPACE Framework
• Golden Paths
• Sidecar Pattern
• Cell-Based Architecture
• Coupling and Cohesion