How Foundational Platforms Differ From Standard CD Practices

Ian Nowland, co-founder of Junction Labs and a veteran of infrastructure teams at Amazon AWS, Datadog, and FinTech companies, argues that foundational platforms—systems whose failure brings down the entire business—operate under radically different constraints than typical application teams, yet industry wisdom rarely accounts for this distinction.

The Core Difference: Business Impact#

A foundational platform is defined by a simple metric: if it breaks, does the business stop? This differs fundamentally from developer-experience tools or feature teams, where disruption frustrates users but doesn't halt core operations. A financial trading platform going offline or an observability system losing data ingestion represents total business failure—not user inconvenience. This gulf in consequence transforms how platforms must be built and deployed.

Where Standard CI/CD Falls Short#

The disconnect between platform teams and industry guidance stems from misaligned assumptions. Industry best practices like the DORA metrics emphasize frequent deployments and rapid rollbacks, benchmarking success by deployment velocity. Yet for stateful infrastructure systems that abstract complexity on behalf of their customers:

• Frequent releases are risky: When a single bug can cascade across the entire user base, a 50% failure rate in deployments is unacceptable. If product teams could tolerate that, platform engineers would be fired.
• Testing is nearly impossible offline: Platforms internalize the complexity of distributed systems, hardware failures, and state management that applications don't encounter. This complexity cannot be replicated in staging environments, making local or pre-production testing fundamentally limited.
• Rollbacks aren't always safe: Changes to stateful systems may be irreversible. A database migration or state corruption cannot be undone with a simple revert; the damage persists.
• Blast radius is broader: A platform outage affects not one team but every business unit depending on that infrastructure.

Why Platforms Internalize Complexity#

The paradox of platform engineering is that complexity doesn't vanish—it relocates. Building clean APIs and storage systems requires platforms to absorb and abstract the messy reality of hardware, distributed systems, and operational edge cases. This abstracted complexity lives inside the platform team's codebase, making change riskier and testing harder.