Hybrid and multicloud without architecture theatre

Few phrases sound as responsible in a strategy document as "hybrid multicloud". It suggests flexibility, resilience and freedom from any single vendor. It is often written before anyone has asked which workloads need it, who will operate it, or what it will cost.

Hybrid and multicloud are consequences of requirements. They are poor goals on their own. An organisation that adopts them as goals tends to pay for two of everything (skills, tools, contracts, controls) while getting the resilience and freedom of neither. An organisation that arrives at them because specific workloads demand it can get real value, as long as it keeps the operating model coherent.

This final part brings the series together. It looks at when hybrid and multicloud earn their cost, why multicloud changes lock-in rather than removing it, how portability actually works, and how to decide whether a second strategic cloud is justified.

Mopane Group is fictional, and its workloads and figures are illustrative. Over the previous five parts, Mopane's workloads have landed in several places: group systems and the financial services policy platform on Azure, the retail loyalty app on AWS, a retail analytics workload on Google Cloud, Oracle E-Business Suite heading for an Oracle platform, and the packaging plant's systems on a local platform. That looks like a multicloud strategy. Whether it is one is the question this part answers.

Hybrid that earns its cost

Hybrid is justified when a workload has a durable boundary between local and cloud execution. Common examples:

• local execution with central analytics or management, like Mopane's plant;
• legacy systems that cannot move yet but must serve cloud applications;
• data reduction or AI inference at an edge location, where shipping raw data to a region is impractical;
• regulated data held locally while approved processing uses public cloud;
• a staged migration with a defined end state;
• business continuity that requires local operation during a network outage.

The boundary is where the cost lives, and it is only worth paying if both sides are run as one system. That means one operating model across the boundary: identity, asset inventory, policy, observability, vulnerability management, incident ownership and cost allocation all have to cover both sides. Without that, hybrid becomes two platforms and an integration problem, and every incident starts with an argument about which side owns it.

Mopane's plant boundary meets this test. The plant runs locally; its servers are enrolled in Azure Arc, so they appear in the group's inventory, patch compliance and security monitoring; and production data crosses the boundary on a schedule, through a local buffer, so neither side depends on the other being up to function.

A specific warning about permanent temporary architecture. Migrations create transitional components: a database replicated in both directions, a VPN that was meant to last three months, a synchronisation job nobody remembers writing. Every one of them needs an owner, a retirement condition and a review date. Otherwise a hybrid design is simply a migration that never finished.

Multicloud that earns its cost

Start with a distinction that removes most of the confusion. Using Microsoft 365 for email, an application on AWS and analytics on Google Cloud makes an organisation a consumer of multiple clouds. That is normal and often sensible. It does not automatically justify a common multicloud application platform: a shared layer designed so that any workload can run on any provider.

Deliberate multicloud, in the stronger sense, is defensible when:

• separate workloads have strong and different provider fits, proven on evidence;
• a merger or group structure has created platforms that cannot yet be consolidated;
• a software product must deploy into the customer's chosen cloud;
• a regulation or contract creates a real provider constraint;
• concentration risk is material enough to fund independent controls and tested recovery on a second provider;
• a unique service creates more value than the integration and operating cost of adding its platform.

Most of these describe placing different workloads on different clouds. Very few describe running the same workload on several clouds at once, and that is deliberate. Running one workload active-active across providers is among the most expensive things an organisation can choose to do, and it is rarely what the business case actually requires.

The lock-in myth

The most common argument for multicloud is avoiding lock-in. It is also the weakest, because multicloud does not remove lock-in. It changes its form.

An organisation that builds a portable layer to avoid depending on any one provider becomes dependent on that layer instead: a Kubernetes distribution, a third-party database that runs everywhere, a network fabric, an infrastructure-as-code abstraction, or the small team capable of operating every environment. It also gives up much of what made each provider worth choosing, because portable designs tend to use only the lowest common denominator of managed services.

The more useful question is not "how do we avoid lock-in" but "how much would it cost, and how long would it take, to leave, and is that acceptable for this workload?"

Four levels of portability

Portability is not one thing. It has levels, and each costs more than the one before.

Most organisations need credible exit, not instant active-active operation across providers. Credible exit means: data can be exported and has been exported in a test; the infrastructure is defined in code; dependencies are recorded; and recovery has been tested. Rebuilding a service elsewhere within weeks, if a provider relationship fails, may be economically rational. Running it twice forever, just in case, usually is not.

A seven-question approval test

Before adding a second strategic runtime cloud (a platform the organisation will build and run its own workloads on, as opposed to consuming a SaaS product) require written answers to these questions:

1. Which named risk or business outcome requires it?
2. Why can the primary platform not meet that requirement?
3. Which applications and data belong on each platform?
4. Who owns identity, networking, security, observability, FinOps and incidents across them?
5. What duplicated skills, tools, contracts and controls will it add?
6. How will portability or failover be tested?
7. What measurable event would end the multicloud arrangement?

If the answer to the first question is "avoid vendor lock-in", the case is incomplete. If nobody can answer the fourth, the arrangement will fail at its first serious incident.

Mopane: multicloud as a consumer, not as a platform

Mopane applied the test to its own map. Azure is the primary enterprise platform. AWS is there because the retail digital team was already productive on it, the loyalty app passed every gate there, and moving it would cost more than it returned (Part 3). Google Cloud hosts one analytics workload that passed its spike on BigQuery. Oracle E-Business Suite is heading for an Oracle-managed database platform because licensing dominates its economics, with the final choice waiting on its recovery gate (Part 4). The plant stays local (Part 5).

Each placement answered questions 1 to 3 on its own evidence. None of them justified a common multicloud application platform, so Mopane did not build one. Instead, it standardised the things that have to be the same everywhere, which is where the real governance value lies:

• Identity: Entra ID is the single workforce identity across every platform, including AWS and Google Cloud.
• Security evidence: logs from every platform land in one security monitoring platform with one incident process.
• FinOps: one tagging standard (owner, cost centre, environment, workload) enforced on every platform, and one monthly cost review covering all of them.
• Exit evidence: each workload has a recorded exit plan, with a data export tested at least annually.
• Ownership: each platform has a named owning team; the group platform team owns the shared standards, not every platform.

That answers question 4. Question 5 got an honest answer too: the AWS and Google footprints each add a skills dependency on a small team, which Mopane accepted and recorded as a risk, with a trigger to reconsider if either team shrinks below three people who can operate it.

A South African reference pattern

For most South African enterprises, a practical pattern looks like this: one primary public cloud, a governed local or edge platform where a workload genuinely requires one, and selected SaaS products. A second public cloud is introduced for a named workload advantage, not as a duplicate default.

This concentrates scarce skills and guardrails on one platform, which matters in a market where experienced cloud engineers are expensive and hard to retain, while preserving room for justified exceptions. The platform team publishes paved paths for the common case. Architecture governance assesses exceptions against the same evidence used everywhere else, not against loyalty to a provider.

The earlier piece on when to use Azure, AWS and GCP together gives a shorter introduction to the same question.

Close the loop: prove it, record it, review it

Two steps finish any platform decision, and they apply to every part of this series.

Test the disputed risks. Run a focused proof aimed at the risks people actually disagree about: failure and recovery, data export, cost at peak load, security controls, deployment effort and operational visibility. Do not build a broad proof of concept that demonstrates the easy parts and avoids the difficult ones.

Record the decision with a review date. Keep the assumptions, rejected alternatives, material risks, owners and review triggers with the architecture decision record. Revisit the choice when a hard assumption changes, not on a whim and not never.

Common mistakes

• Adopting hybrid multicloud as a goal. It should be the consequence of specific workload requirements.
• Running two sides of a hybrid boundary as two platforms. One operating model must cover identity, policy, monitoring and incidents on both.
• Leaving transitional components with no retirement date. Temporary architecture becomes permanent cost.
• Believing multicloud removes lock-in. It moves the dependency to an abstraction layer or a scarce team.
• Building active-active across providers when credible exit would do. It doubles the operating cost for a scenario the business may never need.
• Justifying a second cloud with "avoid lock-in". Name the risk or outcome, or the case is incomplete.

A decision you can defend

We use five platforms as a consumer of multiple clouds, not as a multicloud application platform, because each workload's placement passed its own gates on evidence. The main risks are fragmented security evidence, inconsistent cost allocation and thin skills on the secondary platforms. We will control them through single workforce identity, one security monitoring platform, one tagging standard with a monthly cross-platform cost review, and annually tested data exports. We will reconsider if a secondary platform's operating team falls below three people, if a provider changes terms materially, or if a regulator imposes a provider constraint.

What to take from this part

Hybrid and multicloud are consequences, not goals. Start from the workload, not the slogan.

A hybrid boundary needs one operating model. Otherwise it is two platforms and an integration problem.

Multicloud changes lock-in; it does not remove it. Plan for credible exit instead.

Standardise what must be the same everywhere. Identity, security evidence, cost allocation, exit plans and ownership.

Record every decision with a review trigger. A platform choice is an assumption that will eventually change.

That completes the series. Start again from Part 1, or see every part on the series page.

How CloudNala can help

We help organisations turn a collection of cloud choices into a coherent estate: applying the approval test to proposed second platforms, defining the shared identity, security, FinOps and exit standards that every platform must meet, and setting up the decision records and review triggers that keep the strategy current.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book a Cloud Platform Decision Review or write to us at consult@cloudnala.co.za