Multi-cloud architecture: run on three clouds, or don’t

How to run on three clouds at once, and when not to

Running active active across three clouds sounds like a flex. It is also a recurring bill, a bigger blast radius, and a lot more ways to fail.

Form3 chose to do it anyway. They moved from single cloud to triple active multi-cloud for payments infrastructure, with different disaster recovery expectations across the UK, Europe, and the US. Ross McFarlane and Kevin Holditch walk through the technical choices that made it possible, including CockroachDB, NATS, cross-cloud networking, and custom Kubernetes operators, in their InfoQ talk from 2026-09-11. According to McFarlane and Holditch, the hard part was not Kubernetes. It was making the whole system behave predictably under regional and provider failure modes. InfoQ

The CTO lesson is simple. Multi-cloud. It is an operating model choice.

Multi-cloud architecture: what it is, and what “triple active” really means

Multi-cloud. Triple active means all three clouds serve live traffic at the same time, not just sitting idle for disaster recovery.

In the Form3 story, the architecture is not “deploy the same Helm chart three times.” It is a set of system contracts that survive provider differences.

Core components in a triple active setup

Cross-cloud networking: private connectivity and routing that works across providers.
A shared messaging layer: event transport that stays available during partial failures.
A distributed database: data replication and consistency across regions and clouds.
A Kubernetes control pattern: operators and automation that keep drift under control.
A DR and resilience model per market: UK, EU, and US expectations differ.

McFarlane and Holditch describe using CockroachDB for distributed data and NATS for messaging, plus custom Kubernetes operators to manage the complexity. InfoQ

That stack choice is not the point. The point is the contracts it forces you to define.

Why CTOs reach for multi-cloud, and why it often backfires

CTOs usually get pushed into multi-cloud for one of three reasons.

A regulator asks for resilience beyond a single provider.
A board asks about concentration risk.
A big customer demands it in procurement.

The backfire happens when teams treat it as an infra project. It is a product and reliability project.

The hidden cost is not compute, it is coordination

A triple active system multiplies the number of “normal” states.

Cloud A is healthy, Cloud B is degraded, Cloud C is healthy.
Cloud A has a control plane issue, workloads keep running, but you cannot deploy.
Cloud B has a regional networking event, and your cross-cloud routing flaps.

Each state needs a runbook, monitoring, and a decision owner.

If you do not have a crisp incident model, you will learn it during an outage. Use a structured post-incident process early, not after the first public incident. The Incident Postmortem tool helps teams capture timelines and action items without turning it into a blame session.

Data gravity turns into data politics

Multi-cloud forces you to answer questions that a single cloud lets you ignore.

Which system is the source of truth?
What is the write path during a partition?
Who decides when to fail over, and what is the user impact?

McFarlane and Holditch point to CockroachDB as a way to run a distributed database across clouds. That choice still forces you to pick consistency and latency trade-offs per workload. InfoQ

If your product cannot tolerate cross-region write latency, you will end up with per-region writes and async replication. That is not a database decision. That is a product semantics decision.

Kubernetes makes it possible, but it does not make it simple

Kubernetes gives you a common scheduler and API surface. It does not give you common load balancers, common IAM, common DNS behavior, or common managed service limits.

Form3 used custom Kubernetes operators to manage parts of the system. That is a strong signal. They did not try to “click ops” their way out of drift. They wrote software to run their software. InfoQ

That is the real bar for triple active. You need platform engineering maturity.

Multi-cloud networking: the part that breaks first

Cross-cloud networking is where good diagrams go to die.

You need to plan for:

Routing asymmetry: traffic goes out one path and returns another.
MTU mismatches: packet fragmentation shows up as random timeouts.
DNS caching: failover looks fast in theory and slow in practice.
TLS and cert rotation: three clouds means three places to break trust.

A practical pattern is to treat networking as a product with tests.

Run synthetic probes between every cloud pair.
Track latency and packet loss as SLO inputs.
Alert on route changes, not just service errors.

If you do not measure the network, you will argue about it during incidents. The Connectivity Tester is a simple way to get repeatable latency and packet loss checks during triage.

Distributed data across clouds: what CockroachDB buys you, and what it does not

A distributed SQL database can reduce the amount of custom replication code you write. It can also lock you into a set of failure semantics.

McFarlane and Holditch describe using CockroachDB in their multi-cloud design. InfoQ

Here is the CTO level decision you still have to make.

Question	Option A	Option B	What breaks
Where do writes happen?	Single region leader	Multi-region writes	Latency or consistency
What happens on partition?	Reject writes	Accept writes and reconcile	Availability or correctness
How do you handle schema changes?	Global migrations	Per-region staged rollout	Downtime risk or drift

Payments and financial messaging often prefer correctness over availability for certain operations. That pushes you toward rejecting writes during partitions for specific workflows, even if the rest of the system stays up.

That split is where many teams fail. They try to apply one global rule.

Messaging across clouds: why NATS shows up in these designs

A message bus becomes the spine of a distributed system. It also becomes a failure amplifier.

Form3 used NATS as part of their architecture, per the talk. InfoQ

The CTO questions to ask are not “Kafka vs NATS.” They are:

Can we survive a cloud wide network event without retry storms?
Do we have backpressure and rate limits per tenant?
Can we replay events safely after a partial outage?

If you do not design for retry storms, multi-cloud will not save you. It will spread the storm.

Enterprise implications for CTOs

Your DR story becomes a contract, not a slide. Regulators and enterprise buyers will ask for evidence. They will ask for test results, not diagrams. Form3’s talk highlights different regional DR expectations across the UK, Europe, and the US, which forces explicit commitments per market. InfoQ
Your platform team becomes a control plane team. Triple active means you need automation that detects drift, enforces config, and manages rollouts across three providers. Form3’s use of custom Kubernetes operators is a clear example of that shift. InfoQ
Your incident response has to handle partial failures as normal. A single cloud outage is easy to classify. A partial cross-cloud degradation is not. If you do not have consistent severity rules, you will wake the wrong people. The Incident Severity Classifier helps standardize that call.
Your vendor risk model changes shape. Multi-cloud reduces single provider dependency, but it increases dependency on shared layers like DNS, identity, and your own automation. If you are doing this because procurement asked, write down the exit triggers and the real switching costs. The Vendor Lock-in Exit Strategy is useful for making that conversation concrete.

CTO recommendations: how to decide, and how to execute

Immediate actions

Write the failure modes. List the top 10 provider and network failures you expect. Include control plane loss, regional loss, and partial packet loss.
Pick two workloads to pilot. Choose one stateless and one stateful. Run them across two clouds first. Triple active is a phase, not a starting point.
Run a quarterly failover drill. Time it. Record it. Treat it like a product release.
Define data correctness rules per workflow. Payments, auth, and reporting do not need the same semantics.

Policy framework

Change control: Require an ADR for any cross-cloud dependency. Keep it short and review it monthly.
Service ownership: Assign one team per service, but assign one owner for cross-cloud routing and identity. Split ownership creates outages.
Evidence for resilience: Store drill results, RTO, and RPO in one place. Audits punish scattered evidence.

If you need a way to track risks, incidents, and service health in one view, the Command Center is built for that kind of portfolio visibility.

Architecture principles

Common API surface, not common implementation. Standardize on interfaces. Let each cloud use native primitives where it helps.
Fail closed for money movement. For payment initiation and settlement, reject ambiguous states. Make retries explicit.
Design for control plane loss. Assume you cannot deploy for hours. Your system still has to run.
Automate drift detection. If you cannot detect drift, you cannot run three clouds safely.

When not to run on three clouds

Most teams should not.

Do not do triple active multi-cloud if:

You have fewer than 6 to 8 engineers on platform and SRE work.
You cannot run weekly on-call without burnout.
Your product does not have a clear uptime or resilience requirement that justifies the cost.
Your data model cannot tolerate cross-region latency, and you are not ready to redesign workflows.

A useful decision rule is to treat multi-cloud like a rewrite. It is a multi-quarter bet with compounding complexity. If you are already debating a rewrite, use a structured decision model like the Rewrite vs Refactor framework to avoid stacking two risky bets.

Bigger picture: multi-cloud. Other sectors are catching up. Regulators and large buyers now treat operational resilience as a first class requirement, not a best effort.

That pressure will spread through supply chains. If you sell into banks, insurers, healthcare, or government, your architecture will get reviewed like critical infrastructure.

The question is not whether you can run on three clouds. The question is whether you can prove you will survive the failures you already know will happen.

Sources

InfoQ presentation: Form3 multi-cloud architecture

How to Run on Three Clouds at Once, and When Not To