skip to content

Your board asks for multi-cloud after another company's outage, so which three distinct postures can that one word mean?

level: middleimportance: must knowfreq 62%

answer

  1. one word, three different bills
  2. live on both, split, or planned
  3. only one survives losing a platform
  4. split placement buys no failover
  5. a plan nobody ran is a document

basics

~20 s

Multi-cloud covers three different architectures: the same workload live on two platforms at once, different workloads split across platforms with one home each, and a single live platform plus a documented exit plan. Each has a different bill and a different failure behaviour.

solid answer

~40 s

The word hides three postures. **Live on both** means the same workload serves from two platforms simultaneously, each side able to carry the whole load alone — the only posture that survives losing a platform without a project. **Split by strength** places different workloads where each fits best, but every workload still has exactly one home, so it buys no failover for any single workload. **A plan on paper** keeps one live platform plus a documented, ideally rehearsed, way to leave. They are not degrees of the same thing: the first levies a permanent design and operating tax, the second doubles operational surface without doubling resilience, and the third costs almost nothing until the day you use it. The first question in any multi-cloud conversation is which of the three is actually being proposed.

go deeper

for a junior

Recall that multi-cloud is not one thing. Be able to name the three shapes: the same workload live in two places, different workloads in different places, and a written plan to move. That distinction alone puts you ahead of most first-screen answers.

for a middle

Explain the mechanics that separate them: which posture has a second copy of the data in step, which has a second copy of the capacity, and which has neither. Say plainly that placing workloads on different platforms provides no failover for any one of them.

for a senior

Show that you price each posture, not just describe it. Talk about the capacity you pay for twice, the commitment discount you lose by splitting spend, and the blind spot both live copies share when the failure is self-inflicted.

for a principal

Frame it as which fear the organisation is buying insurance against — supplier failure, supplier pricing power, or a supervisor's concentration-risk question — and be explicit that three different fears have three different cheapest answers.

## One word, three different commitments "Multi-cloud" is a word a board uses for a goal — *do not depend on one supplier* — and engineers use for at least three architectures that share almost nothing. They fail differently, they bill differently, and they create different day-two work. Before anyone can argue about whether multi-cloud is worth it, the conversation has to name which posture is on the table. | Posture | What it is | What it buys | What it costs | |---|---|---|---| | **Live on both (active-active)** | the same workload serving from two platforms at once, each side sized to carry the whole load alone | survives the loss of an entire platform with no migration project | design limited to what both platforms offer, two of everything operationally, idle capacity on both sides | | **Split by strength** | different workloads placed on the platform that suits each, every workload with exactly one home | two sets of real operating knowledge, commercial spread across two suppliers | two control surfaces, two identity models, two audits — and no failover for any individual workload | | **Plan on paper** | one live platform plus a documented, ideally rehearsed, way to leave it | keeps the option open and satisfies a concentration-risk requirement cheaply | nothing until it is used — and it is worth nothing if it has never been exercised | ## Posture one — the same workload live on both This is the only posture that answers "what serves the next request if a whole platform is gone". It is also the most expensive, and the cost is not mainly the second infrastructure bill. Two structural taxes come with it. The **design tax**: the workload can only use capability both platforms express, in a shape both express it in, so the richest managed tiers on either side are off the table or must be matched by hand. The **capacity tax**: if either side must carry the whole load alone, you are paying for roughly twice the capacity you use, and your spend is split across two suppliers so each qualifies for a smaller commitment discount. It also has a blind spot people forget. A live second copy faithfully reproduces whatever you send it, so a bad configuration change or a bad release rolled out to both sides fails on both sides. The posture protects against *the supplier* failing, not against *you* failing. ## Posture two — split by strength Here the data pipeline runs on one platform because its analytical tier is better, and the transactional service runs on the other. It is the posture most organisations already have without calling it one. It does buy things: leverage at renewal, two teams with genuine hands-on knowledge, and a smaller blast radius in the sense that not everything is in one place. What it does **not** buy is continuity for any one workload. The ledger still has one home; if that home is unavailable, the ledger is unavailable, and having the analytics elsewhere does not change that by one second. Presenting this posture as resilience is the most common way the word is oversold internally. ## Posture three — an exit plan held on paper One live platform, plus a written, costed and ideally rehearsed description of how the workload would be stood up somewhere else. This is the cheapest posture by a wide margin, and for a regulated business it is often the one a supervisor actually asks for: evidence that concentration risk has been thought about and that leaving is possible, not evidence that you are already running in two places. Its weakness is that it degrades silently. A plan written two years ago against an estate that has changed underneath it is a document, not a capability, and nobody finds out until the day it matters. ## How to tell which one you are being sold Four questions separate the three in under a minute: 1. **If the platform disappeared right now, what serves the next request?** Something on the other platform (posture one), nothing (postures two and three). 2. **Where is the data at this moment, and how stale is the second copy?** Continuously in step, periodically copied, or not there at all. 3. **When was this last exercised, by whom, and how long did it take?** A posture nobody has run is a claim, not a capability. 4. **What does the second side cost when nothing is wrong?** Full capacity, a small standing footprint, or a document. Only one of the three postures usually earns its tax for any given workload, and which one depends entirely on what the organisation is actually afraid of.

  • Which of the three postures do most organisations already have without ever deciding to?
    The split posture. Software-as-a-service tools, an analytics estate and a transactional estate accumulate on different platforms through ordinary procurement. It is worth naming, because it already carries the operational tax of two platforms — two identity models, two audit trails, two quota regimes — while delivering none of the continuity benefit people assume the word implies.
  • If the fear is a supplier raising prices at renewal rather than an outage, which posture answers it?
    Mostly the third, and partly the second. Credible leverage comes from being able to show a costed, rehearsed move, not from already running everywhere. Running live on both is an expensive way to buy negotiating power, and it weakens your position in another way: your spend is split, so you qualify for a smaller commitment discount on each side.
  • Does running live on two platforms protect against a bad release?
    No, and assuming it does is a common error. A live second copy applies what you give it. A faulty configuration or a faulty release promoted to both sides breaks both sides, usually within minutes of each other. That class of failure is addressed by how you roll changes out, not by how many platforms you hold.

A restaurant chain can keep a second fully staffed kitchen ready to serve tonight, cook starters in one building and mains in another, or simply hold a written plan for renting a new kitchen. All three get called "we are not dependent on one building", and only the first keeps serving when a building burns.

saying these in an interview costs you the question

  • Treating multi-cloud as one architecture with one price
  • Claiming split-by-strength workloads survive a platform outage
  • Calling an exit plan nobody has exercised a resilience strategy
  • Assuming a second platform protects against a bad release
  • Believing an open account on a second platform is a posture
  • Arguing the cheapest posture is automatically the right one