Most teams treat multi-cloud as a slogan until the day their primary provider blinks. Form3's journey from a single-cloud setup to a triple active architecture, as shared by Ross McFarlane and Kevin Holditch, is a useful counterpoint to that inertia. They did not chase redundancy for its own sake. They moved because regional financial markets in the UK, Europe, and the US each carry distinct disaster recovery expectations, and a single cloud cannot credibly satisfy all of them at once. That is the practical lesson: multi-cloud is not a feature, it is a compliance and reliability strategy wearing an engineer's hat.
What stands out is how unglamorous the hard parts are. Cross-cloud networking, distributed databases on CockroachDB, NATS for messaging, and custom Kubernetes operators are not the stuff of flashy demos. They are the plumbing that makes three active regions feel like one system. The fact that Form3 built custom operators rather than relying on off-the-shelf tooling tells you something important: generic multi-cloud abstractions often hide more complexity than they remove. The teams that succeed here are the ones willing to own their operational pain. This is the same discipline we see in other engineering efforts, like Scale Sandboxes Instantly: A New Approach to Concurrent AI Workloads, where Modal engineers rebuilt their sandbox infrastructure to handle concurrency at scale, or Simplify EKS Management: Elastic Beanstalk Now Runs on Shared Clusters, where AWS is reducing operational overhead by running managed services on shared infrastructure. In all three cases, the pattern is the same: the real innovation is in operational design, not in the choice of cloud provider.
There is also a strategic nuance here that often gets lost. Running on three clouds at once is not a badge of honor; it is a decision with real tradeoffs. The presenters are explicit about the "when not to" part, which is rare and valuable. Most architecture talks sell you on the destination without mapping the terrain. Form3's approach suggests that the question is not "can we run everywhere?" but "what does our disaster recovery actually require, and which cloud topology serves that requirement without bankrupting the engineering team?" That clarity is what separates a mature multi-cloud strategy from a vanity project. If you are building for global financial services, your regulators care about regional data residency and failover behavior, not about how many logos you can put on a slide.
Our take for you is straightforward: do not adopt a triple-active model because it sounds forward-thinking. Adopt it when your compliance boundaries, latency targets, and operational capacity demands it. And when you do, expect to write your own tooling, because the cloud providers are not going to solve cross-cloud data consistency for you. The related work on orchestrating AI agents in Orchestrate AI Agents: Google Open-Sources AX for Enhanced Efficiency shows a similar pattern: the hard problems are about coordination and state management, not about picking a platform. The specific detail to watch is how Form3 handles the human cost of running custom operators across three clouds, because that is where most teams will underestimate the long-term maintenance burden. If they can sustain that, they will have built something genuinely durable. If not, the architecture will still be elegant, but it will be a museum piece.