Evolving a cloud platform
A cloud platform is a product that many teams build on. That makes evolution harder (lots of consumers) and more important (mistakes are multiplied).
The platform as a set of quanta
Section titled “The platform as a set of quanta”Think about which parts of the platform can evolve independently:
| Layer | Examples on AWS | Changes how often? |
|---|---|---|
| Organisation and accounts | AWS Organizations, OU structure, Control Tower, Account Factory (or AFT for Terraform) | Rarely; high blast radius |
| Identity and access | IAM Identity Center, permission sets, SCPs/RCPs | Occasionally |
| Networking | Transit Gateway, shared VPCs, IPAM, Route 53 Resolver, egress inspection | Occasionally; hard to change |
| Shared services | Logging and security accounts, CI/CD runners, artefact repositories | Regularly |
| Golden paths | CDK constructs, Terraform modules, Service Catalog products, templates | Often |
| Workloads | Teams’ own services | Constantly |
The lower layers are the hardest to change. Spend more design effort there and keep them simple; move as much as possible into the upper layers, where change is cheap.
Practices
Section titled “Practices”- Platform as a product. Treat application teams as customers. Their adoption is a fitness function: if teams route around the golden path, the path is wrong.
- Golden paths, not golden cages. Provide a well-supported default with guardrails, but let teams leave it when they have a reason (and record that reason).
- Versioned building blocks. Publish CDK constructs and Terraform modules with semantic versions and changelogs. Use expand and contract for breaking changes: release the new version, help consumers move, then deprecate the old one.
- Guardrails as fitness functions. See Fitness functions on AWS.
- Self-service with automated checks instead of ticket-based approvals.
- Team Topologies. The platform team reduces cognitive load for stream-aligned teams; enabling teams help them adopt new capabilities. See Team Topologies and platform teams.
Migrations as evolution
Section titled “Migrations as evolution”Large cloud migrations are where evolutionary thinking pays off most:
- Strangler fig for moving workloads: route traffic piece by piece, with the old system as fallback.
- Two-way-door decisions first. Make reversible choices quickly; spend time on one-way doors (account structure, IP addressing, identity provider). See ADR-0001 and ADR-0002 for worked examples.
- Measure as you go. DORA metrics, cost per workload, and guardrail compliance show whether the platform is actually improving.
Fitness functions for the platform itself
Section titled “Fitness functions for the platform itself”- Time to provision a new account or environment (lead time for the platform).
- Percentage of workloads on a supported version of each golden-path module.
- Number of open guardrail exceptions and how old they are.
- Percentage of resources managed by IaC (vs. created in the console).
- Developer satisfaction with the platform (survey; a manual, temporal check).