Multicloud architecture tradeoffs: Form3 says don't

Form3, a payments platform, runs actively on Amazon, Google and Microsoft at the same time. Its engineers went on stage to explain how — and spent a notable share of the talk explaining who should not copy them. That combination makes it the most useful public account of multicloud architecture tradeoffs available right now, because the people who did the work are the ones naming the cost.

They did not choose this

In their conference talk, the driver is regulatory, not architectural. UK banking regulators raised concerns about concentration risk, and a major customer required the ability to exit any single cloud provider. That demand forced a redesign of the whole platform.

This is the first thing to take from it. Form3 did not arrive at three clouds by reasoning about resilience from first principles. They were told to, by a customer whose business they wanted and a regulator they cannot ignore. If you are considering multicloud and nobody is requiring it of you, you are in a different situation from theirs and their answer may not be your answer.

The design decision that made it tractable

The architecture moved from AWS-only to a cloud-agnostic platform on Kubernetes, with Go microservices, CockroachDB and NATS JetStream spanning Google Cloud, Azure and AWS.

The idea that makes it work is deceptively simple: each cloud is treated as an availability zone, not as a separate deployment. That is the difference between one distributed system and three systems you have to keep in agreement. Three parallel deployments means three of everything — three release processes, three sets of drift, three chances to be subtly out of step — and a data synchronisation problem that has defeated much larger companies. One system whose failure domains happen to be different providers is a harder engineering problem up front and a far smaller operational one afterwards.

It also explains the component choices. CockroachDB and NATS JetStream both assume a network that spans failure domains. Had they picked a managed database from any one provider, the exit requirement would have been unsatisfiable at the point it mattered most.

The gaps required custom work: a cross-cluster pod disruption budget operator, because Kubernetes reasons about disruption within a cluster and they needed it across clusters, and a cluster lifecycle operator for node pool management. That is a fair signal of where the ecosystem still assumes one provider.

Worth noting what they did not have to build. Treating clouds as availability zones only works because the data layer can tolerate it; if your system of record is a single-writer managed database, no amount of Kubernetes portability above it changes where the truth lives. The database choice is the multicloud decision, made years before anyone uses the word. Everything else is downstream consequence and comparatively mechanical.

It worked, and it cost

The proof point is unambiguous. During a major Google Cloud outage, only low-level alerts fired and payments kept flowing through the other clouds. For a payments company, that single sentence is the entire business case.

The bill is equally unambiguous. Kevin Holditch put it without hedging: it is definitely more expensive to run across three clouds, and there is no getting away from that. They have reduced the cost since, but the direction of travel is fixed. There is also an overhead most cost models miss — they run multiple smaller production environments rather than scale pre-production enormously, which is a sensible answer to an expensive problem and is itself more estate to operate.

One constraint deserves attention because it defeats a common assumption. Latency ruled out spreading US operations across both coasts: in their words, they could easily burn through their service level agreements just waiting for electrons to cross the continent. Their US disaster recovery site accepts a non-zero recovery time and recovery point. Physics does not care how good your architecture is.

The multicloud architecture tradeoffs, in their words

Ross McFarlane's conditions are the most valuable part of the talk, and they are all commercial rather than technical.

• Does the market care? If your state-of-the-art solution does not impress your customers, then it is maybe not worth your effort or your money. Form3's customers are banks with a regulator asking them about concentration risk. They will pay for this. Most buyers will not pay a premium for an architecture they never see.
• Can you afford it? Bankruptcy is incompatible with uptime. That is the sentence to quote in the meeting where someone proposes multicloud for a product that has not found its market.
• Do you have the team? You need a really robust platform engineering practice and a really capable and trusted platform team. Not an intention to build one. One that exists.

We would add a fourth from our own delivery experience: are you already good at running on one cloud? Multicloud does not fix a weak deployment story, undocumented infrastructure or a team that dreads releases. It multiplies all three. Almost every client who has raised multicloud with us had unresolved problems on their existing provider that would have taken a fraction of the effort to fix.

There is a quieter cost in the same category. Every engineer on the team now has to hold three providers' failure modes, quotas, IAM models and quirks in their head, or the platform team becomes a bottleneck for everyone else. That is a hiring and onboarding cost that never appears in the cloud bill, and it compounds with turnover.

What people usually mean when they ask for multicloud

In our experience the request is nearly always one of four things wearing the wrong label, and naming which one saves a great deal of money.

1. Procurement leverage. You want a credible threat to leave at renewal. That needs portable architecture — containers, open-source data stores, infrastructure as code — not live traffic in three places.
2. Regulatory or customer obligation. Form3's case. Read the actual clause: exit capability within a defined period is common, continuous active operation is rare and far more expensive.
3. Outage anxiety after a bad week. Usually better answered with multiple regions from one provider, which is dramatically cheaper and handles most of what actually goes wrong.
4. Using the best service from each. The most expensive one, because it produces genuine dependencies on three providers with none of the exit benefit. This is the opposite of what Form3 built.

Only the second reliably justifies the architecture in the talk. The first is usually satisfied by disciplined portability, which is worth doing regardless and is much of what we mean by scalable architecture in the first place. The third is a region problem. The fourth is a trap.

The distinction that matters in the contract is between exit capability and continuous operation. An obligation to demonstrate you could move within, say, ninety days is satisfied by portability, rehearsed runbooks and an annual test. An obligation to keep serving through the loss of a provider is what Form3 built, and it is a different order of expense. We have seen teams read the first clause and budget for the second.

Where we would start instead

If the exit requirement is real, the sequence matters more than the destination. Get infrastructure fully described in code and reproducible from scratch. Move off provider-specific managed services in the data layer, which is where lock-in actually bites, and be honest that this is the expensive step. Prove you can rebuild the platform in a second region of your existing provider before claiming you could rebuild it on another one. Then, and only then, argue about three clouds.

That order also happens to deliver most of the value early. A platform that is reproducible, portable in its data layer and provably rebuildable is already resilient, already gives procurement leverage, and is already easier to operate — before anyone pays for a second provider. It is the same argument as deciding when to shard a database: the preparation is cheap and reversible, the commitment is neither.

Form3 built something genuinely impressive under a constraint they did not choose. The honest lesson from their talk is not how to run on three clouds. It is that they can name exactly why they had to, and most teams asking the question cannot. If you want help working out which of the four requests above you are actually making, that conversation is usually a short one and it is the useful half of any cloud engineering engagement.