This article is based on content originally published on about.gitlab.com.
As organizations deepen their cloud-first strategies, optimizing cloud architecture has moved to the top of the IT agenda. A growing share of infrastructure spending now goes toward cloud computing, and most enterprises are not relying on a single provider. Using multiple cloud providers and services demands an architecture that supports workflow portability — and a genuinely unbiased, multi-cloud strategy to make that portability real.
What Is Multi-Cloud?
Multi-cloud is the practice of using two or more cloud providers to meet different technical or business requirements within a single organization. At its core, multi-cloud is enabled by cloud-native applications built from containers that can consume services from different providers, all managed within one overarching architecture.
It is worth distinguishing between simply using multiple cloud providers and genuinely operating in a multi-cloud way. An organization might have workloads scattered across AWS, Azure, and GCP for historical reasons without having the workflow portability that true multi-cloud requires. Vendor lock-in — where switching providers becomes prohibitively expensive or technically complex — remains a real risk even for organizations that think they have diversified.
Key Reasons Organizations Adopt Multi-Cloud
- Greater flexibility: Each cloud provider has strengths and weaknesses. Multi-cloud lets teams choose the best service for each workload rather than accepting whatever a single vendor offers.
- Better support for acquisitions: When companies merge or are acquired, their existing systems may sit on different cloud platforms. A multi-cloud architecture lets both sides continue operating without a forced migration.
- Increased resilience: Designing failover across multiple providers reduces the blast radius of a single provider outage.
- Stronger negotiating leverage: When DevOps processes are not tied to vendor-specific services, teams can negotiate better pricing or credits because switching costs are lower.
- Fewer conflicts of interest: Large cloud providers offer an expanding catalog of services that can compete with their own customers. Using multiple vendors limits exposure to those conflicts.
Can Cloud Providers Really Support Multi-Cloud?
Most major cloud service providers (CSPs) publicly endorse multi-cloud, but their business model creates an inherent tension. Cloud computing is largely pay-per-use: the more services a customer consumes from a single provider, the more revenue that provider earns and the harder it becomes to migrate those workloads elsewhere.
AWS, GCP, and Azure each offer dozens to hundreds of distinct services — many of which are deeply integrated with each other within that provider’s ecosystem. The broader and deeper a team’s adoption of any single provider’s managed services, the greater the switching cost. Proprietary data formats, provider-specific APIs, and tightly coupled managed services all work against workflow portability.
This does not mean CSPs are acting in bad faith when they discuss multi-cloud support, but DevOps teams should assess independently whether a given tool or service is genuinely cloud-agnostic or whether it creates new dependencies on a particular provider’s infrastructure.
Implementing CI/CD in a Multi-Cloud Context
CI/CD pipelines are a central component of multi-cloud delivery. If an organization wants to build once and deploy to any target environment — whether that is AWS EKS, Google GKE, Azure AKS, or an on-premises Kubernetes cluster — the CI/CD toolchain must be able to orchestrate those deployments without being tied to a specific provider’s runtime or API.
The RightScale 2019 State of the Cloud Report cited implementing CI/CD in the cloud as one of the top cloud initiatives among respondents. This reflects a broader recognition that delivery pipelines are infrastructure — and that infrastructure must be as portable as the applications it deploys.
GitHub Actions and GitLab CI/CD: A Multi-Cloud Comparison
GitHub announced Actions with CI-like functionality in 2018, bringing integrated pipelines into GitHub’s source code management platform. In June 2018, Microsoft acquired GitHub — a move that underscored the strategic value of developer tooling as a channel for cloud adoption. With millions of developers already using GitHub for source control, the platform became a natural on-ramp for Azure workloads.
That is not necessarily a problem for teams already committed to Azure, but it introduces a consideration for organizations pursuing a cloud-agnostic strategy. GitHub Actions can deploy to any cloud, but the commercial relationship between GitHub and Microsoft means there is an inherent gravitational pull toward Azure integrations and marketplace offerings.
GitLab, by contrast, is not owned by a cloud provider. When a team uses GitLab CI/CD, GitLab does not have a financial incentive to favor one deployment target over another. GitLab pipelines can build, test, and deploy to AWS, GCP, Azure, or any other target that a runner can reach. Governance features — security scanning, compliance frameworks, audit logs — apply consistently regardless of where the workload ultimately runs.
“Choosing a cloud provider should depend on the company’s business objectives, it should not be constrained by technology, and GitLab wants to enable every one of our customers to have this freedom.”
Sid Sijbrandtij, co-founder and CEO, GitLab
Practical Implications for DevOps Teams
When evaluating CI/CD tooling for a multi-cloud environment, consider the following questions:
- Does the CI/CD platform require a specific cloud runtime? Some managed CI services run exclusively on a single provider’s infrastructure, which can introduce latency, cost, or compliance issues for workloads on other clouds.
- Are pipeline definitions portable? YAML-based pipeline definitions stored in the repository alongside application code are easier to migrate than pipelines configured through a proprietary UI or API.
- Does the vendor have a commercial relationship with a specific CSP? That relationship may shape roadmap priorities in ways that disadvantage teams on other clouds.
- Can runners or agents be self-hosted on any infrastructure? Self-hosted runners give teams control over where build jobs execute, which is important for compliance, performance, and cost management across clouds.
- Are security and governance policies enforced consistently? In a multi-cloud environment, consistent policy enforcement across all deployment targets is as important as the deployment itself.
Multi-Cloud Should Mean Any Cloud
A multi-cloud strategy is only as strong as its weakest dependency. If the CI/CD layer reintroduces a single-provider dependency, the organization has not truly achieved workflow portability — it has just moved the lock-in point upstream.
Cloud-agnostic CI/CD tooling — where pipelines are defined as code, runners can execute on any infrastructure, and the vendor has no stake in which cloud you choose — is a practical enabler of genuine multi-cloud operations. As cloud strategies mature, the ability to build, test, and deploy to any target environment without rewriting pipelines or renegotiating tool contracts will become a meaningful competitive advantage.