Building Composable Platforms: Patterns, Practices, and Pratfalls

Composable platforms are redefining how internal platform teams deliver value. While the theory is compelling, the real-world results can be mixed. In this talk, we’ll explore the patterns that actually work (and the ones that don’t) when building composable platforms using Kubernetes, and tools like Backstage, Crossplane, and Kratix.

Drawing from experience across regulated enterprises, scaling startups, and open source communities, we’ll examine how teams are approaching modular service delivery, integrating self-service with governance, and balancing autonomy with consistency. You'll learn:

Which architectural and team patterns accelerate platform adoption
Why some “composability” efforts create more confusion than clarity with incorrectly scoped abstractions
How to identify early warning signs of failure, such as platform gatekeepers and overly rigid golden paths
This talk is for platform engineers, architects, and leaders who want to make composable platforms deliver real outcomes.

Transcript

1. Building Composable Platforms: Patterns, Practices, and Pratfalls Daniel Bryant Developer, Platform Engineer & Product Marketer
2. tl;dr • Composition is valuable in three layers: app, platform, and infra • Each layer (teams) must own their flow of value • Think speed, safety, efficiency, and scalability • Composability is all about APIs, abstraction, and automation • Build your platform as a product
3. @danielbryantuk linktr.ee/danielbryantuk
4. Setting the scene
5. The value of platform engineering By 2026, approximately 80% of large software engineering organizations will establish dedicated platform engineering teams to create "Internal Developer Platforms" But something happened in 2024-2026… gartner.com/en/articles/what-is-platform-engineering
6. (AI) Party like it’s August 29th, 1997
7. Platform teams aren’t feeling the love…
8. Platforms are still valuable… gartner.com/en/articles/software-engineering-tiny-teams
9. Maybe even more so… weaveintelligence.io/research/state-of-ai-in-platform-engineering-2026
10. My 2c: AI is accelerating demand on your platform leaddev.com/culture/platform-engineering-for-developers-architects-the-rest-of-us-ai-agents
11. The value of platform engineering By 2026, approximately 80% of large software engineering organizations will establish dedicated platform engineering teams to create "Internal Developer Platforms" “Teams must own their own flow of value” https://www.gartner.com/en/articles/what-is-platform-engineering
12. Team Topologies recap: XaaS FTW teamtopologies.com/key-concepts
13. The value of platform engineering By 2026, approximately 80% of large software engineering organizations will establish dedicated platform engineering teams to create "Internal Developer Platforms" “Teams must own their own flow of value” https://www.gartner.com/en/articles/what-is-platform-engineering
14. Each team must own their flow of value Developer want to code, ship, run Here is the “platform as a product” Here are the infrastructure modules syntasso.io/post/platform-engineering-orchestrating-applications-platforms-and-infrastructure
15. Why Composable Platforms?
16. The benefits of composable platform architecture • Fast time to market ◦ • Increased resilience ◦ • Easier to understand, chain, and maintain Cost-efficiency ◦ • Quick assembly and deployment Easier to upgrade Supports evolution ◦ Modular growth
17. The benefits of composable platform architecture • Fast time to market (Speed) ◦ • Increased resilience (Safety) ◦ • Easier to understand, chain, and maintain Cost-efficiency (Efficiency) ◦ • Quick assembly and deployment Easier to upgrade Supports evolution (Scalability) ◦ Modular growth
18. Internal Platforms Scorecard Attribute Definition One Metric That Matters Speed Fast, on-demand provisioning of services and infrastructure Mean Time to First Deploy Safety Customisation with control, delivering business-specific services within guardrails % of Services Running that are Policy-Compliant Efficiency Seamless fleet-wide operations with reduced operational toil Mean Time to Upgrade Service Instances Scalability Ability for teams to extend and evolve the platform independently Mean Time to Add a Service to the Platform
19. Composability impacts all of the properties • Speed 🏎 ◦ • Safety 󰠺 ◦ • Re-usable, organisation-specific, and approved compliance components Efficiency 🎯 ◦ • API-first, highly automated, with consistent lifecycle management Upgradable as a fleet (easy to upgrade 100 as it is 1) Scalability 🚀 ◦ Supporting inner sourcing & “platform democracy” (easy and effective contributions)
20. Platform Patterns
21. #1: Build-Your-Own Kit vs Composable Blocks 😡 Fails: DevOps Tool Dump • • • “Here’s Terraform, Helm, ArgoCD, Vault…” Every team builds its own mini-platform No shared standards, no upgrade path 😃 Works: Small set of reliable primitives • • • Few org-specific building blocks Blocks versioned, upgradable, combinable Good discoverability of primitives 🏎✅✅◾(only for the right teams) 🏎✅✅◾ (with abstraction + automation) 󰠺❌❌◾ 󰠺✅✅◾ (needs fleet management) 🎯❌❌❌ 🎯✅◾◾ 🚀❌❌❌ 🚀✅✅◾
22. #1: Build-Your-Own Kit vs Composable Blocks careersatdoordash.com/blog/doordash-engineers-with-kafka-self-serve/
23. #2: Policy in Confluence vs Policy in the Runtime 😡 Fails: Docs-based Governance • • • Golden-path wiki nobody reads Platform team becomes gatekeeper Drift, exceptions, and manual reviews 😃 Works: Reusable Governance as Code • • • Compliance baked into delivery path Evidence is machine-readable Reusable components (CALMS, OPA, etc) 🏎❌❌◾ 🏎✅✅◾ 󰠺✅◾◾(yes, at the start) 󰠺✅✅✅ 🎯❌❌❌ 🎯✅✅✅ 🚀❌❌❌ 🚀✅✅ ◾(need all teams involved)
24. #2: Policy in Confluence vs Policy in the Runtime infoq.com/presentations/mcp-calm-api-architecture/
25. #3: Puppy for Christmas vs Platform as a Product 😡 Fails: Puppy for Christmas • • • Templates for Terraform, Helm, etc No owner, no upgrade, no guarantees Day-2 chaos: drift, patches, audit pain 😃 Works: Platform as a Product • • • Capabilities offered as versioned products Each has owner, SLA, lifecycle, Automatable, reconcilable (idempotent) 🏎✅◾◾ (yes, initially) 🏎✅✅✅(minimise approvals) 󰠺❌❌❌ 󰠺✅✅✅(engage InfoSec) 🎯✅◾◾ (yes, initially) 🎯✅✅✅(GitOps++) 🚀✅◾◾ (yes, if everyone is an expert) 🚀✅✅✅ (embracing Innersourcing, etc)
26. #3: Puppy for Christmas vs Platform as a Product thenewstack.io/how-data-helps-lego-click-developer-experience-into-place/
27. Putting it all together
28. For composability to thrive… • Clear API (contract) and lifecycle management (versioning, reconciliation, etc) ◦ CNCF Whitepaper soon published “Platform producer factors” • Correct level of abstraction (relevant to your organisation) • Building blocks appropriate for the layer/department/specialisation • Components must be discoverable • Productise your services for the win!
29. Abstractions all the way down Layer Application Too Low Terraform + Helm + Vault + Argo CD Infrastructure Too High [WebApplication / Worker] deployMyApp() Developer expresses app requirements, deps and intent Easy initially, but rigid and hard to extend Raw K8s resources, Terraform modules, cloud services PostgresDatabase / KafkaTopic / Environment [FinOpsReporter / PiiLeakDetector / ProdDeployApprover] createProductionApp() Consumer assembles infrastructure into a capability Organisation-specific capabilities with policy and lifecycle built in Individual API calls, scripts, cloud resources Network / DatabaseInstance / KubernetesCluster Consumer understands implementation details Platform Useful Abstraction Operators manually assemble primitives Reusable infrastructure components with clear contracts Bundles too many capabilities and removes choices teams legitimately need to make createProductionEnvironment() Hides topology, resilience, networking and capacity decisions Each layer should expose abstractions meaningful to its consumers, without leaking the implementation details of the layer below.
30. Abstractions all the way down Layer Application Too Low Terraform + Helm + Vault + Argo CD Infrastructure Too High WebApplication / Worker deployMyApp() Developer expresses app requirements, deps and intent Easy initially, but rigid and hard to extend Raw K8s resources, Terraform modules, cloud services PostgresDatabase / KafkaTopic / Environment [FinOpsReporter / PiiLeakDetector / ProdDeployApprover] createProductionApp() Consumer assembles infrastructure into a capability Organisation-specific capabilities with policy and lifecycle built in Individual API calls, scripts, cloud resources Network / DatabaseInstance / KubernetesCluster [FinOpsReporter / OpenPortCheck] Operators manually assemble primitives Reusable infrastructure components with clear contracts Consumer understands implementation details Platform Useful Abstraction Bundles too many capabilities and removes choices teams legitimately need to make createProductionEnvironment() Hides topology, resilience, networking and capacity decisions Each layer should expose abstractions meaningful to its consumers, without leaking the implementation details of the layer below.
32. Wrapping up 🎉
33. Conclusion • Think about your platform architecture in three layers: ◦ Application, platform and infrastructure • Each team must own their flow of value • Think speed, safety, efficiency, and scalability • Composability is all about APIs, abstraction, and automation • Build your platform as a product
34. Thank you! @danielbryantuk | daniel@syntasso.io syntasso.io/platform-as-a-product-oreilly-report docs.kratix.io/ske/installing-ske/intro