Cloud architecture used to be something a central team drew once and application teams implemented many times, each slightly differently. As organizations scaled to dozens or hundreds of teams on AWS, Azure and Google Cloud, that model broke. Every team reinvented networking, CI/CD, secrets handling and observability, and architecture review boards became bottlenecks. Platform engineering emerged as the answer: encode the architecture into a self-service internal developer platform (IDP) so that the secure, compliant, cost-aware way is also the easiest way. In 2026 the discipline has matured from a buzzword into a recognizable architecture pattern, and AI coding assistants and agents have raised the stakes further. This article explains how to design an IDP as a piece of cloud architecture, not just a portal.
Why Platform Engineering Became an Architecture Concern
The original promise of DevOps was “you build it, you run it.” In practice, asking every product team to master Kubernetes, Terraform, service meshes, policy engines, security scanners and FinOps tooling produced enormous cognitive load and inconsistent results. Platform engineering reframes the problem: a dedicated team builds reusable capabilities and offers them as products, so product teams can focus on business logic.
This is an architecture concern because the platform is the architecture for most teams. Whatever network topology, identity model, deployment pattern and observability stack the platform provides becomes the de facto standard. If the platform makes a poor decision, it is replicated everywhere; if it makes a good one, it is adopted everywhere without a single review meeting.
The CNCF’s Platforms Working Group captured this shift in its Platform Engineering Maturity Model, which describes how organizations progress from ad hoc, volunteer-built tooling to a product-managed platform ecosystem. That model is useful precisely because it treats the platform as a long-lived system with investment, adoption, interfaces, operations and measurement dimensions, not as a one-off tooling project.
What the CNCF Says a Platform Should Be
The CNCF Platforms white paper defines a cloud-native platform as a cross-cutting layer that gives users a consistent way to acquire and integrate common capabilities. It lists the attributes that separate a real platform from a pile of scripts: it is managed as a product designed around user needs; it offers a consistent experience through portals, APIs, CLIs and IDE integrations; it has clear documentation and golden path templates; it is self-service; it reduces cognitive load by hiding implementation detail; it is optional and composable, so teams use only what they need; and it is secure by default. These attributes are a practical checklist for any architecture review of a platform design.
The same paper enumerates typical capabilities: portals, provisioning APIs and CLIs, golden path templates, build and delivery automation, development environments, observability including costs, infrastructure services, data services, messaging, identity and secrets, security services and artifact storage. Few organizations need all of them on day one, but the list helps architects spot gaps and sequence investment.
A Reference Architecture: The Five Planes of an IDP
Most mature platforms can be described as a set of planes. The names vary across vendors and communities, but the separation of concerns is consistent.
1. Developer Control Plane
This is where developers interact with the platform: a developer portal (Backstage is the most common open-source foundation), a CLI, IDE extensions and, increasingly, AI assistants that can invoke platform actions. It hosts the software catalog, service templates, documentation and scorecards. The key design principle is that the portal is an interface, not the platform itself; everything it does should also be available through APIs.
2. Integration and Delivery Plane
CI pipelines, artifact registries, software supply chain controls (signing, SBOM generation, provenance attestations) and continuous delivery, often through GitOps tools that reconcile declared state in Git with running environments. This plane enforces build-time guardrails such as dependency scanning and policy checks on infrastructure code.
3. Resource Plane
The actual cloud infrastructure: accounts or subscriptions, networks, Kubernetes clusters, serverless runtimes, databases, queues and AI services. Platform teams expose these through higher-level abstractions, for example a “web service with a Postgres database” rather than forty individual resources, using infrastructure-as-code modules or control-plane frameworks such as Crossplane that let developers request infrastructure through Kubernetes-style APIs.
4. Security and Policy Plane
Identity federation, secrets management, workload identity, policy-as-code (for example Open Policy Agent or Kyverno), and integration with cloud-native posture and runtime security. The goal is to make guardrails automatic: a service created from a golden path should already have least-privilege identity, encrypted storage and network policies.
5. Observability and FinOps Plane
Logs, metrics, traces and cost data, collected consistently using standards such as OpenTelemetry and tagged by team, service and environment. Because every service is created through the platform, ownership metadata is reliable, which makes cost allocation and incident routing dramatically easier.
Golden Paths: The Core Architectural Product
A golden path is an opinionated, supported route from idea to production for a common type of workload. It bundles a template, infrastructure modules, pipeline configuration, security defaults, observability wiring and documentation. Good golden paths share several properties:
- They are optional but attractive. Teams can leave the path, but doing so means taking on support responsibility. Adoption should come from value, not mandates.
- They cover the majority case. Aim for the handful of patterns that represent most of your workloads, such as a containerized API, an event-driven worker, a data pipeline and a static front end.
- They evolve. Templates that generate code once and are never updated create drift. Prefer approaches where shared components are upgraded centrally, such as versioned modules, base images and reusable pipeline definitions.
- They encode architecture decisions. Each golden path should link to the architecture decision records that explain its choices, so teams understand the why.
Design Decisions That Matter Most
Abstraction Level
Too low, and developers still need deep cloud expertise; too high, and the platform cannot support legitimate variation. A common pattern is layered abstraction: a high-level “application” API for most teams, with escape hatches to lower-level modules for teams that need them.
Kubernetes or Not
Kubernetes is a powerful substrate for platforms, but it is not mandatory. Many organizations run successful IDPs on managed container services, serverless and PaaS offerings. Choose based on workload mix, team skills and portability requirements, not fashion.
Multi-Tenancy Model
Decide how teams are isolated: separate cloud accounts or subscriptions per team and environment, shared clusters with namespaces, or a hybrid. Account-level isolation simplifies blast radius and cost allocation; shared clusters improve utilization. Most enterprises combine both.
Build, Buy or Assemble
Building a portal from open-source components gives control but demands sustained engineering effort. Commercial IDP products and managed Backstage offerings reduce that burden. Treat this as a classic architecture trade-off and revisit it as the platform grows.
Operating Model and Team Topology
Architecture and organization are inseparable here. A platform team typically sits alongside, not above, stream-aligned product teams, and interacts with them in two modes: collaboration while a new capability is being discovered, and “X-as-a-service” once it is stable. Enabling specialists from security, data and FinOps contribute policies and modules into the platform rather than reviewing projects one by one. Size the platform team to the scope of the product, give it a product manager, and protect a share of its capacity for maintenance and upgrades; platforms that only ship new features accumulate their own technical debt quickly. Finally, publish a clear support model, including service-level objectives for platform capabilities, so product teams can trust the platform enough to depend on it.
Making the Platform AI-Ready
Two AI trends are reshaping platform design in 2026. First, AI coding assistants and agents now generate a large share of new code and infrastructure definitions. A well-designed platform turns this into an advantage: if golden paths, policies and templates are well documented and exposed through APIs, AI tools produce compliant output by default. If they are not, AI simply accelerates inconsistency.
Second, teams are building AI-powered products, which need GPUs, model endpoints, vector databases, evaluation tooling and AI gateways. Platforms are adding these as first-class capabilities:
- A golden path for retrieval-augmented generation and agent services, with approved models, gateways and evaluation pipelines.
- Platform actions exposed through the Model Context Protocol, so assistants can scaffold services or query the catalog under the developer’s identity.
- Quota and cost guardrails for model usage, surfaced per team in the FinOps plane.
- Policies for data access by AI services, integrated with existing classification and DLP controls.
A Maturity Roadmap
The CNCF maturity model describes four levels: Provisional (ad hoc, volunteer-built), Operationalized (a funded central team with standard tooling but reactive work), Scalable (platform as a product, with roadmaps, user research and self-service) and Optimizing (an ecosystem where users contribute and measurement is embedded). A practical roadmap toward the Scalable level looks like this:
- Map the current state. Interview product teams, inventory existing pipelines and modules, and identify the top sources of friction and incidents.
- Form a platform team with a product owner. Treat developers as customers and publish a roadmap.
- Deliver a thin viable platform. One golden path for the most common workload, end to end, including security and observability.
- Establish the catalog. Register services with owners and dependencies; this unlocks scorecards, cost allocation and incident routing.
- Add golden paths incrementally, prioritized by demand and risk.
- Measure. Track adoption, lead time, change failure rate, time to first deployment for new services and developer satisfaction.
- Open contribution. Let product teams contribute templates and modules through an inner-source model.
Measuring Platform Success
The CNCF white paper groups platform metrics into three families, and a balanced scorecard should include all three. User satisfaction and productivity: active users, retention and survey-based satisfaction, ideally informed by a framework such as SPACE. Organizational efficiency: time from request to fulfillment, time to build and deploy a new service, and time for a new engineer to ship a first change. Delivery performance: the DORA measures of deployment frequency, lead time for changes, time to restore service and change failure rate. The paper’s underlying point is worth repeating to stakeholders: a platform succeeds only when the products built on it succeed.
A Worked Example: From Ticket-Driven Cloud to Self-Service
Consider a hypothetical retail company with forty product teams on AWS and Azure. New services take weeks to reach production because teams file tickets for accounts, networks, pipelines and security reviews. Each team’s Terraform looks different, and costs cannot be attributed reliably.
The company forms a platform team of eight engineers and a product manager. In the first quarter they deliver a single golden path for containerized APIs: a template in a Backstage-based portal creates a repository, a pipeline with signing and scanning, a namespace on a shared managed Kubernetes cluster with network policies, a workload identity with least-privilege access to a managed Postgres instance, and dashboards wired through OpenTelemetry. Every service created this way is tagged with team and cost center.
In the second quarter, they add an event-driven worker path and a static site path, and they expose the platform’s actions through an MCP server so developers can ask their coding assistant to scaffold a new service on the golden path. The security team moves its standard controls into policy-as-code in the delivery plane instead of manual reviews.
By the end of the year, most new services use a golden path. Time to first production deployment for a new service drops from weeks to days, security review effort shifts from per-project meetings to maintaining policies, and finance receives reliable per-team cost reports. The architecture team spends its time evolving golden paths rather than reviewing diagrams.
Pitfalls and Anti-Patterns
- Portal-first thinking: launching a shiny portal with nothing reliable behind it. Start with capabilities and APIs.
- Mandates without value: forcing adoption of a platform that is slower than the old way breeds workarounds.
- One-time templates: scaffolding that is never updated leaves hundreds of services on outdated patterns.
- Ignoring the long tail: no escape hatches means legitimate edge cases get blocked or go fully off-platform.
- No measurement: without adoption and delivery metrics, the platform cannot justify investment.
In a modern cloud organization, the internal developer platform is the architecture. Design it as a product with clear planes, golden paths and embedded guardrails, and good architecture spreads by default.
Conclusion: Encode Architecture, Don’t Just Document It
Platform engineering lets cloud architects move from reviewing every design to encoding the best design once and offering it as self-service. A sound IDP separates developer, delivery, resource, security and observability planes; delivers a small number of evolving golden paths; balances abstraction with escape hatches; and is managed as a product with clear metrics. With AI assistants generating more code and AI workloads demanding new infrastructure, a well-architected platform is the most effective way to keep speed, security and cost under control at the same time.
How Hanoi Technology Can Help
Hanoi Technology designs and builds internal developer platforms, golden paths and policy-as-code guardrails that turn cloud architecture standards into self-service for product teams.