Most multi-cloud is accidental, arriving through acquisition or team preference rather than strategy. The costs are real (duplicated expertise, duplicated tooling, incomparable billing), and the usual mitigation of writing everything against a lowest common denominator makes things worse. The workable approach is to unify the operating model while letting each provider be itself.
What is multi-cloud DevOps?
Multi-cloud DevOps is the practice of running one consistent operating model (delivery, observability, security and cost management) across more than one cloud provider, so processes and skills transfer between environments even though the underlying provider services differ.
How organisations get here
Deliberate multi-cloud (for resilience, negotiating leverage or regulatory requirement) exists but is the minority case. Most estates arrive at it accidentally: an acquisition brings a different provider, a data science team chooses one for a specific managed service, a regional requirement forces a second, or a large credit arrives from a vendor.
This matters because the right response differs. Accidental multi-cloud usually needs operational consolidation while workloads stay where they are. Deliberate multi-cloud needs genuine portability, which is considerably more expensive.
The costs, stated plainly
| Cost | Why it happens |
|---|---|
| Duplicated expertise | Each provider has its own services, quirks and failure modes to learn |
| Duplicated tooling | Monitoring, cost and security tools often need per-provider configuration |
| Incomparable billing | Different taxonomies, granularity and discount structures |
| Egress charges | Cross-provider data movement is billed and is rarely modelled in advance |
| Weakest-link security | Your posture is that of the least well-configured provider |
| Lowest common denominator | Avoiding managed services to stay portable often costs more than lock-in would have |
That last row is worth dwelling on. Refusing a managed database to preserve portability means operating a database yourself across every provider. The cost of that is usually larger, and more permanent, than the cost of migrating a managed database once if you ever actually need to.
Unify the operating model, not the services
The productive distinction is between the operating model and the provider services. The operating model (how you deploy, what you monitor, how access is governed, how cost is attributed) should be identical everywhere. The services underneath can differ.
- One inventory across providers, with a common resource taxonomy.
- One delivery path targeting any provider, with per-target configuration and approvals.
- One policy set evaluated against every provider, reporting specific deviations.
- One normalised cost model so totals and comparisons are meaningful.
- One access model resolving effective permissions across every provider IAM.
Kubernetes helps here, not because it makes clouds identical but because it gives the delivery layer a common target. What it does not solve is everything around the cluster (networking, identity, storage, managed data services), which is where the per-provider work remains.
Practical portability, without the fantasy
Full portability (the ability to move any workload to any provider quickly) is expensive and rarely exercised. A more useful goal is that migration is possible with known effort, which you get from a few specific choices rather than from avoiding managed services.
- Keep application code free of provider SDKs where a standard interface exists: S3-compatible object storage, standard SQL, OpenTelemetry.
- Keep infrastructure definitions in code, so recreating an environment elsewhere is a known quantity.
- Know where your data actually is and what moving it would cost in egress and downtime: this is usually the binding constraint, not the compute.
- Accept lock-in deliberately where the managed service is genuinely better, and record the decision so it is a choice rather than a discovery.
What DevOpsArk provides here
DevOpsArk normalises the operating model across AWS, Azure, Google Cloud and on-premises: one inventory with a common taxonomy, one delivery path that can target clusters and services on any provider, one policy set evaluated everywhere, and billing data normalised so cost is comparable and totals are meaningful.
It does not abstract away provider capability, which is deliberate. Managed services stay what they are; what becomes uniform is how you govern, observe and account for them.
Key takeaways
- Most multi-cloud is accidental; the right response differs from deliberate multi-cloud.
- Avoiding managed services to preserve portability usually costs more than the lock-in would have.
- Unify the operating model (inventory, delivery, policy, cost, access), not the underlying services.
- Kubernetes gives a common delivery target but does not unify networking, identity or data services.
- Aim for migration with known effort rather than instant portability, and record lock-in as a decision.
Frequently asked questions
Deliberate multi-cloud is justified by regulatory requirements, genuine resilience needs or negotiating position, and it carries real cost. Accidental multi-cloud is common and usually needs operational consolidation rather than workload migration.
It makes the delivery layer portable, which is a genuine benefit. Everything around the cluster (networking, identity, storage classes, managed data services, load balancers) still differs, and that is usually where migration effort concentrates.
By normalising billing data into a common resource taxonomy, because each provider uses different granularity, naming and discount structures. Without normalisation, comparison is not meaningful.
Lock-in is dependence on provider-specific services that makes migration expensive. It matters in proportion to how likely you are to migrate and how expensive it would be. Accepting it deliberately for a service that is genuinely better is usually the correct trade; accepting it unknowingly is not.
Rarely. Active-active across providers is expensive and introduces its own failure modes, and most outages people fear are regional rather than provider-wide. Multi-region within one provider addresses most of the risk for far less complexity.