Platform Engineering for Software Developers and Architects (Redux) - Daniel Bryant, Syntasso

Platform Engineering for Software Developers and Architects (Redux)

Speakers: Daniel Bryant; Syntasso

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=fZ_ULsJ5WGA

Overview

Daniel Bryant’s KubeCon EU talk, "Platform Engineering for Software Developers and Architects (Redux)," delivers a comprehensive and insightful exploration into the evolving landscape of platform engineering. Bryant, a seasoned developer, architect, and CTO, unpacks the critical shift required for successful platform initiatives: a product focus where developers are considered the primary customers. He argues that platform engineering is not merely a repackaging of DevOps, but a distinct discipline aimed at delivering a robust internal product that enables developers to build and ship software with speed, safety, and at scale.

The talk emphasizes the symbiotic relationship between platform architecture and software architecture, highlighting how well-designed APIs, abstractions, and automation—the "three A's"—are paramount to overcoming the cognitive load developers face in modern, complex cloud-native environments. Bryant traces the historical evolution of software delivery paradigms, from monolithic enterprise applications to microservices and cloud-native Kubernetes deployments, illustrating how the need for effective platforms has become increasingly urgent. This article delves into Bryant's proposed three-layered platform architecture, offers practical advice for both platform builders and consumers, and underscores the importance of measuring platform success through a developer-centric lens.

Background

▶ Watch: Introduction and high-level key takeaways (0:00)

Daniel Bryant begins by recounting his 20-year journey in software development, marked by fluctuating levels of cognitive load. Early in his career, working with simple Java applications, the cognitive load was manageable. However, as he moved into enterprise use cases involving Enterprise Service Buses (ESBs) and message queues, the complexity and the number of technologies to learn spiked dramatically. A period of relative simplicity followed with platforms like Spring Boot, Cloud Foundry, Ruby on Rails, and Heroku, where the platform abstracted away much of the underlying infrastructure, allowing developers to focus on business logic with simple commands like CF push or Heroku push.

The advent of microservices and DevOps once again sent cognitive load "massively up." While Bryant, like many KubeCon attendees, enjoys learning new technologies, he observed that many clients he consulted with simply wanted to write code (JavaScript, Go, Java) to solve business problems, not master Bash, Terraform, Crossplane, or Docker. This realization, coupled with the explosion of work within the CNCF ecosystem, led to the early framing of what he called a Developer Control Plane (DCP) – a platform architecture designed to simplify the developer experience. He wanted to "code, ship, and run" with ease, recognizing that while tools like Backstage (a "twinkle in Spotify's eye" at the time, now ubiquitous), Docker, and MS Ingress were powerful, an integrated workflow layer leveraging webhooks, CRDs, and APIs was missing.

Bryant grounds his definition of a digital platform in established thought leadership. He cites Martin Fowler's blog, specifically Evan Botcher's definition, which describes a digital platform as focusing on self-service APIs, tools, services, knowledge, and support, arranged as a "compelling internal product." The goal is to deliver product features at a higher pace with reduced (not zero) coordination. He also references Gartner's focus on platform engineering, which aligns with his "three A's" (APIs, abstractions, automation) by emphasizing improving developer experience, self-service capabilities, and automated infrastructure operations.

Crucially, Bryant stresses the importance of clearly defined platform goals: going faster, decreasing risk, and increasing efficiency at scale. He draws inspiration from Team Topologies by Matthew Skelton and Manuel Pais, and Gregor Hohpe's "Software Architect Elevator." Hohpe's work highlights the need to use different language depending on the audience:

• C-suite: "Make me more money" (go faster), "keep me off the front page of the newspapers" (decrease risk), "save me money" (increase efficiency).
• Boiler room (developers): "Improve the developer experience" (go faster), "make it easy for me to do the right thing" (decrease risk), "right abstractions" (increase efficiency). This contextualization underscores the product-centric approach, translating business value into tangible developer benefits.

Key Findings

▶ Watch: Developer cognitive load and platform evolution (2:50)

Daniel Bryant's talk crystallizes several key findings that are fundamental to successful platform engineering:

1. Platform Engineering is a Product Discipline with Developers as Customers: This is the overarching theme. A platform must be treated as an internal product, designed with a focus on developer experience (DX) and user experience (UX). Its success hinges on its adoption and how effectively it reduces friction for its users – the software developers and architects. This shifts the mindset from an "ops team building infrastructure" to a "platform team delivering a valuable product."

1. The Symbiotic Relationship Between Platform and Software Architecture: Bryant emphasizes that a well-designed application cannot exist without a supportive platform, and a good platform must understand the needs of the applications it hosts. This requires constant collaboration between development, operations, security, finance, and architecture teams, forming a "multiplayer game" where everyone contributes to the platform's evolution.

1. The "Three A's" are the Prize: APIs, abstractions, and automation are identified as the core pillars of an effective platform. APIs provide programmatic access, abstractions hide complexity, and automation streamlines workflows. These elements are critical for achieving speed, safety, and scale.

1. A Three-Layered Platform Architecture is Emerging: Bryant proposes and validates a three-tiered model for platform architecture:

• Application Choreography Layer: Where app developers interact (Backstage, CLIs, UIs).
• Platform Orchestration Layer: The crucial middle layer, building higher-level APIs and constructs (e.g., "database as a service") from raw infrastructure.
• Infrastructure Operations Layer: Where platform engineers manage infrastructure as code.

This model is corroborated by insights from Gartner, Keith's book on platform engineering, and Camille Fornet & Ian Noland's "paved path platform" concept.

1. Shift from "Golden Paths" to "Golden Bricks": While "golden paths" (opinionated, standardized ways of working) are valuable for productivity, they can become "golden cages" if too restrictive. Bryant advocates for "golden bricks" – composable, well-defined components that allow developers to construct their own golden paths, catering to diverse application needs (e.g., a data application vs. a standard 12-factor app).

1. Minimize Cognitive Load and Embrace Progressive Disclosure: Platforms should be designed to reduce the mental burden on developers. Progressive disclosure is a key UX principle here: start simple, provide easy defaults (e.g., "name and size" for a database), but allow experts to progressively access and configure more advanced options as needed.

1. Metrics are Essential for Platform Success: "What gets measured gets managed." Bryant highlights the alarming statistic that a significant number of platform engineering initiatives lack success metrics. He champions frameworks like DORA metrics (lead time, change fail percentage), the SPACE framework (Satisfaction, Performance, Activity, Communication & Collaboration, Efficiency & Flow), and the DX Core 4 framework for comprehensively measuring platform adoption, onboarding time, retention, and overall developer satisfaction.

Technical Deep Dive

▶ Watch: Early framing of the Developer Control Plane (4:00)

Bryant's technical deep dive into platform architecture is structured around an evolving three-tiered model, informed by his extensive experience and observations across the industry.

The Three-Layered Platform Architecture

Bryant articulates a clear three-layered platform architecture that he believes is becoming standard:

1. Application Choreography Layer (Top Layer):

• Audience: Application developers, full-stack engineers.
• Interaction: This is where developers directly interact with the platform.
• Tools/Interfaces: Backstage (for portals), CLIs, and direct APIs.
• Purpose: To enable developers to "code, ship, and run" their applications with minimal friction, abstracting away underlying infrastructure complexities.

1. Platform Orchestration Layer (Middle Layer):

• Audience: Platform engineers, potentially specialized architects.
• Nature: This is presented as the "newer, more nuanced" layer. It builds higher-level constructs and APIs than raw infrastructure.
• Function: To offer services that are more relevant to the business context (e.g., "what does a database mean in your context?"). This includes embedding governance, security, and backup policies directly into these higher-level abstractions.
• Tools/Concepts: Bryant's own work on Cratics (a platform orchestration framework) falls squarely into this category. Other tools mentioned include Humatic, Crossplane, and the use of Argo and Flux CRDs (Custom Resource Definitions) for declarative platform management. This layer is crucial for delivering the "golden bricks" that developers can consume.

1. Infrastructure Operations Layer (Bottom Layer):

• Audience: Platform engineers, DevOps, operators, SREs, SysAdmins.
• Interaction: This layer deals with the raw infrastructure.
• Tools/Concepts: Infrastructure as Code (IaC) tools like Bash, Terraform, and CRDs for Kubernetes-native infrastructure provisioning.
• Purpose: To build out and manage the foundational compute, storage, and networking resources.

Bryant emphasizes that this three-layer separation aligns with observations from Gartner, Keith's books on platform engineering, and Camille Fornet & Ian Noland's "paved path platform" concept, suggesting a convergence of industry thinking around this model.

Evolution of Platform Abstractions: From Hexagonal to Sidecars

Bryant traces the evolution of architectural patterns and platform approaches:

• Hexagonal Architectures (Ports and Adapters):
• Concept: Business logic in the middle, surrounded by interfaces (ports) and their implementations (adapters). The idea was to swap out implementations (e.g., MySQL for PostgreSQL) without affecting business logic.
• Benefits: Cohesive business code, easier testing (isolating business logic), promotes loose coupling.
• Challenges: Leaky abstractions were common (e.g., EJB remote and home interfaces, container-managed transactions). Developers were meant to write code indifferent to local vs. network calls, which often led to complex debugging when issues arose. Tightly coupled layered applications meant changes rippled across the stack, requiring multiple deployments across application servers and ESBs.

• Microservices and the Rise of Platform Components:
• Martin Fowler's Prerequisites: Rapid provisioning, independent deployment, and isolation of schemas were critical for microservices success. However, many companies struggled with "rapid provisioning" often translating to slow, ticket-based processes.
• DevOps and "You Build It, You Run It": While valuable, this philosophy doesn't scale well in regulated environments or large enterprises, where consistency (e.g., few logging frameworks, centralized security) is paramount for auditors and managing vulnerabilities like Log4Shell.
• Netflix OSS and Spring Cloud: Netflix OSS provided platform services as Java SDKs, which Spring Cloud eventually integrated, benefiting Java ecosystems.
• Netflix Prana (2014): An early sidecar-like pattern, where a Java server exposed an HTTP API, allowing other languages (Go, Node) to consume platform components. This was a significant step towards language-agnostic platform access.
• Dapper: A modern manifestation of the sidecar pattern. Dapper provides SDKs at the application layer, abstracts platform components (locking, queues, databases) in the middle, and allows for various underlying implementations (e.g., Amazon SQS or RabbitMQ for queues). Bryant notes that while Dapper offers great abstractions, it still requires the platform to provide the "golden bricks" for deploying the application itself.

The "Puppy for Christmas" and Workload Definitions

Bryant humorously describes the "puppy for Christmas" problem: developers ask for a database and get Terraform code. Day one, "happy days." Day two, the developer is responsible for patching, upgrading, and managing the infrastructure, which often falls outside their core competency. This points to the limitations of "templates as a service" – great for day one, but poor for day two operations and ongoing maintenance.

This challenge has led to the emergence of workload definitions that aim to provide a higher-level, platform-agnostic way to describe applications and their dependencies:

• Open Application Model (OAM)
• Score (from Tech, donated to CNCF)
• Radius (from Microsoft)
• Dagger: While moving into AI, Dagger's CI/CD pipeline concept, with its three-tier model (app SDKs, Dagger engine, customizable CI/CD), also aligns with the need for structured workload definitions.

These tools, and the platform orchestrators like Cratics, aim to provide the "holy grail" of a Cloud Foundry/Heroku-like build pack model, where developers push code and the platform handles deployment magic, while still allowing for the "golden bricks" to customize the path.

Cell-Based Architectures

Bryant briefly touches upon cell-based architectures as an evolution, particularly for regulated environments. These are "microservices++" where:

• Infrastructure is tightly coordinated.
• Blast radius is minimized (unlike microservices that might share common infrastructure).
• Examples: Slack, AWS.
• Kubernetes Implications: Requires embracing Cluster API to spin up hardened, isolated clusters for each "cell." Tools like KEDA (Kubernetes Event-driven Autoscaling) and Pod Autoscalers are crucial for managing these environments. Advanced routing with Gateway API and Open Service Mesh is also necessary. The challenge remains to abstract these complexities so developers can interact with applications, nodes, and clusters in conceptually similar ways, preventing cognitive overload.

Demo / Proof of Concept

▶ Watch: Martin Fowler's definition of a digital platform (4:50)

The provided transcript does not include a description of a live demo or a proof of concept. The speaker focuses on theoretical frameworks, architectural patterns, and industry observations rather than a practical demonstration of a specific tool or solution.

Defensive Implications

▶ Watch: Gartner's perspective on platform engineering goals (6:10)

While the talk is not explicitly about security, Daniel Bryant's architectural recommendations and observations have significant defensive implications for organizations:

1. Centralized Control and Governance for Security: Bryant highlights the dangers of fragmented approaches, such as "a hundred different logging frameworks." A well-architected platform centralizes critical functions like logging, monitoring, and security upgrades. This is crucial for rapid response to vulnerabilities (e.g., "heaven forbid if Log4Shell pops up, right? Where's Log4j running in my infrastructure? I've got no idea."). A centralized platform ensures consistency, simplifies audits, and enables swift patching across the entire application portfolio.

1. Security by Design through Abstraction: The platform's role is to "make it easy for me as a developer to do the right thing." By embedding security best practices, governance rules, and compliance requirements into the platform's higher-level abstractions and APIs (the Platform Orchestration Layer), developers consume secure-by-default services. For instance, a "database as a service" offered by the platform would inherently include required security configurations, backups, and access controls, rather than relying on individual developers to implement them correctly.

1. Minimized Blast Radius with Cell-Based Architectures: For highly regulated environments, cell-based architectures are presented as a solution for minimizing the impact of security incidents. By isolating applications or groups of services into hardened, independent clusters (or "cells") using Cluster API, a compromise in one cell does not automatically propagate to others, significantly reducing the potential blast radius of an attack.

1. API-First Security and Control Plane Design: Bryant expresses nervousness about "portal-first" approaches where business logic, compliance, and security rules are coupled to UI elements. He advocates for an API-first design for the platform's control plane. This ensures that security policies and enforcement mechanisms are defined at the API level, making them consistent, auditable, and enforceable regardless of the front-end interface (CLI, UI, Backstage portal) used by developers. This separation prevents security logic from being scattered or difficult to maintain.

1. Standardization and Auditability: The concept of "golden bricks" and standardized workload definitions (e.g., OAM, Score, Radius) promotes consistent deployment patterns. This standardization simplifies security audits, as auditors have fewer unique configurations to review. It also makes it easier to implement and verify security controls across the board, rather than dealing with a multitude of ad-hoc deployment methods.

1. Progressive Disclosure for Expert Security Configuration: While the platform aims to provide secure defaults, progressive disclosure allows security experts or platform engineers to configure advanced security options. This means that basic users get a secure-by-default experience, while those with specific security requirements or expertise can access and fine-tune granular controls, preventing the "golden cage" scenario where security configurations are too rigid.

1. Enhanced Observability for Security Monitoring: A well-built platform inherently provides better observability into application and infrastructure behavior. Centralized logging, metrics, and tracing, managed by the platform, are critical for detecting anomalies, identifying potential threats, and responding effectively to security incidents.

Key Takeaways

• Platform Engineering is a Product, Developers are Customers: Treat your internal platform as a product, prioritizing developer experience (DX) and user experience (UX) to ensure adoption and effectiveness.
• Embrace the "Three A's": APIs, Abstractions, and Automation: These are the foundational pillars for building platforms that enable speed, safety, and scale by reducing cognitive load and streamlining workflows.
• Adopt a Layered Platform Architecture: Implement a clear separation between application choreography, platform orchestration (the crucial middle layer for higher-level APIs), and infrastructure operations to manage complexity and define responsibilities.
• Build "Golden Bricks," Not Just "Golden Paths": While standardized paths are good, provide composable "golden bricks" that allow developers to construct customized paths for their specific application needs, avoiding restrictive "golden cages."
• Design for Progressive Disclosure and Minimize Cognitive Load: Start with simple, secure defaults and progressively reveal advanced options. This ensures ease of use for general developers while empowering experts with granular control.
• Measure Platform Success with Developer-Centric Metrics: Utilize frameworks like DORA, SPACE, and DX Core 4 to track adoption rates, onboarding time, developer satisfaction, and overall impact, ensuring the platform delivers on its goals.

About the Speaker(s)

Daniel Bryant is a seasoned technology leader with a rich background spanning over two decades in software development. He began his career as a Java developer, progressively moving into roles such as architect, operations specialist, and CTO. Currently, he focuses on building developer tools, aiming to capture and package his extensive knowledge into practical solutions. Bryant has contributed to numerous open-source projects, including Open JDK, Open Source Java, Telepresence (a CNCF project), and MSI Ingress during his API management phase. He is currently working on Cratics with Syntasso, which he describes as a platform orchestration framework. A passionate advocate for knowledge sharing, Daniel is actively involved with InfoQ and has authored several books with colleagues. He is a regular speaker at conferences like KubeCon, sharing his insights on platform engineering and software architecture.