The core decision in a multi-cloud strategy is not whether to use multiple clouds, but which architectural pattern to adopt—and each pattern buys a different benefit at a different price in complexity and cost. Segmented architectures, where projects pick their own providers, deliver flexibility with modest overhead. Parallel architectures, which run critical applications across multiple clouds simultaneously, buy availability at the cost of heavy automation and doubled data egress exposure. As architect Gregor Hohpe puts it, "there ain't no such a thing as a free lunch. Architecture is the business of trade-offs."
Understanding Multi-Cloud Architectural Patterns
Before comparing options, it helps to be precise about what multi-cloud means. Writing on enterprise cloud architecture, TechBlocks cautions that a multi-cloud infrastructure is not defined by an organization simply consuming multiple SaaS products, and warns that executives are often pushed toward a default multi-cloud distribution that "wastes resources and introduces unnecessary risk." The genuine question is when a multi-cloud strategy delivers a real advantage versus when it is an expensive add-on that inflates operational costs.
Hohpe's analysis distinguishes three patterns. In a segmented setup, different projects or business units use different cloud providers based on their needs. In a parallel setup, the same critical application is deployed across multiple providers to achieve availability beyond what a single provider can offer. A portable setup aims to shift workloads between clouds at will. Each pattern answers a different business driver, and none is free of drawbacks.
Segmented Multi-Cloud: Choice by Project
The segmented pattern gives each project the freedom to select the provider—and the provider-specific services—that best fit its needs. Hohpe notes that projects remain free to use proprietary cloud services, such as managed databases, depending on their preferred trade-off between avoiding lock-in and minimizing operational overhead. Because each workload lives in one cloud, this setup makes a good initial step for multi-cloud: it supports project needs and preferences while reducing lock-in for individual workloads.
The trade-off is governance. Hohpe's comparison flags that a segmented estate requires a common framework for provisioning, billing, and governance across disparate environments, and that vendors may steer an organization back toward "arbitrary" usage patterns. Without that shared framework, the pattern risks becoming yet another layer of abstraction with a lack of clear guidance. In cost terms, keeping data within its chosen cloud generally limits cross-cloud transfer, which reduces egress exposure—but only if workload placement is deliberate rather than organic.
