Daniel Bryant: Platform Engineering for Developers and Architects

My three messages are that platform engineering needs a product focus with developers as customers; platform architecture and application architecture influence each other; and good APIs, abstractions and automation matter across the whole system.

Looking back over my development career, I remember moving through environments such as Heroku and Cloud Foundry and later confronting the cognitive load of cloud-native tools. Developers wanted to build, ship and run software without personally mastering every operational detail.

A developer portal is one part of a platform, not the whole thing. I like the definition of a platform as self-service APIs, tools, services and knowledge assembled into an internal product. Software development remains a team activity: the goal is to reduce unnecessary coordination, not eliminate people.

A platform needs business goals. I frame them as increasing speed, reducing risk and improving efficiency, then translate those goals into language that makes sense to each audience. Developers might care about a usable abstraction; executives may care about delivery and risk.

I use a three-layer model. At the application layer, developers compose and deliver applications through interfaces such as a portal, CLI or declarative configuration. The infrastructure layer provides and maintains the underlying building blocks, often using infrastructure as code.

Between them is platform orchestration: it turns infrastructure capabilities into services and workflows developers can consume. Each layer has its own lifecycle and needs to own its flow of value; a platform team is not merely a ticket-processing bottleneck.

The application team delivers observable business value, the platform team provides services, patches and improvements, and the infrastructure team maintains its own foundations. Clear ownership lets each group improve its part without relying on ad hoc handoffs for every change.

Team Topologies describes several ways teams can interact: collaboration, facilitation and providing something as a service. Each has its place. A well-designed service boundary can reduce coordination costs while giving the provider feedback on adoption and consumer satisfaction.

APIs, abstractions and automation connect the layers, but the flow is two-way. Developers benefit from sensible defaults while also needing enough understanding of the underlying infrastructure to reason about behavior and constraints.

I recall earlier monolithic applications where a change to the user interface cascaded toward the database, and enterprise abstractions could hide whether a call was local or remote. When failures occurred, the hidden details made diagnosis difficult.

Hexagonal architecture introduced a way to separate a core from external dependencies through ports and adapters. Loose coupling helps test components in isolation and evolve their implementations, although the architecture still needs to match the organization’s actual needs.

I discuss Netflix OSS and libraries that supplied platform capabilities to applications. One difficulty was that implementations and semantics could drift across languages. Sidecars and tools such as Dapr offer another way to expose capabilities through clearer APIs, while the underlying services still need to exist.

I prefer thinking in “golden bricks” as well as golden paths. A single prescribed route can become a golden cage; composable, supported building blocks let teams choose the database, internal services and delivery workflow they need while retaining useful defaults.

Microservices can create cohesive, loosely coupled services, but require rapid provisioning, monitoring and deployment. Some organizations adopted the architecture before they had those capabilities. I saw teams move quickly initially and later struggle to understand and operate their fleet.

The Log4Shell incident illustrated an ownership problem for some teams: they did not know where a vulnerable dependency was running or how to coordinate upgrades across many services. The issue was not just writing infrastructure code, but knowing who could maintain and update it.

Heroku and Cloud Foundry offered useful paved paths, though they had tradeoffs. I compare generated infrastructure to a puppy: creating it is only the beginning. Someone must be responsible for maintenance, security changes and what happens after day one.

Workload definitions and platform orchestration can express what an application needs while leaving the platform to manage infrastructure and policy. I also mention cell-based architecture: it can help organize a fleet, but routing and upgrades across cells still require careful engineering.

Design control planes for APIs, CLIs and user interfaces. I often see too much platform logic embedded in a portal, which couples behavior to one interface and can duplicate it elsewhere. An API-first design can serve different interfaces consistently.

Keep the initial interface simple even if infrastructure, policy and compliance behind it are complex. Progressive disclosure lets users start with a small set of choices and reveal advanced options when needed. Simplicity should not require concealing every useful detail.

Developers do not want unexplained magic, even if automation is valuable. Coupling, cohesion, composability and leaky abstractions matter for platforms just as they do for application code. If consumers depend on undocumented implementation details, changing the platform becomes difficult.

Measurement should connect platform health to outcomes. I distinguish leading indicators such as adoption, onboarding time and time to a pull request from later indicators of delivery performance. No single number captures developer experience or the value the platform creates.

I point to DORA, SPACE and the DevEx framework as complementary ways to discuss delivery and developer experience. A balanced framework helps teams avoid optimizing one metric while ignoring friction, quality or human experience.

To wrap up, treat developers as customers, design good interfaces, and aim for speed and safety at scale. Platform and application architecture evolve together; composable building blocks and clear ownership make it easier to improve both.