Migrating between clouds

Multi-cloud maturity model

Organizations will move towards multi-cloud at their own pace — here are the stages of adoption we’ve seen in the marketplace.

I recently wrote about why organizations, including GitLab, will opt for a multi-cloud future. Every organization will do this at their own pace and the awesome Mitchell Hashimoto recently tweeted about the dimensions involved in multi-cloud. And I wasn’t the only one with whom this resonated. I wanted to share what we’ve at GitLab seen in the marketplace. Although technically independent dimensions in practice we see them building on each-other.

The levels of multi-cloud adoption from initial to mature:

1. Mono-cloud: all applications on one cloud
2. No portability: cloud dependent DevOps processes
3. Workflow portability: cloud independent DevOps processes (most GitLab customers are at this level)
4. Application portability: applications can run on any cloud, there are no cloud specific services used (DynamoDB, Lambda, BigQuery, etc.)
5. Disaster Recovery (DR) portability: applications can fail over to another cloud with limited downtime.
6. Workload portability: applications shift workload between multiple clouds dynamically (for example autoscaling servers for background jobs)
7. Data portability: Data changes can happen in multiple clouds (for example with CockroachDB)

Traffic portability is a separate dimension that happens independent of the above. At any level you can introduce a Content Delivery Network (CDN) to forward traffic to your application. With the introduction of CloudFlare Isolates and Fastly WASM it is clear that CDNs are becoming (edge-)clouds themselves.

Workflow portability is the start of going multi-cloud and it offers the biggest benefits. This ensures that compliance is easier, that you can use the unique capabilities that different clouds offer, that people can switch teams and be effective, and that you can host new applications with the cloud of your preference.

After workflow portability comes application portability. This helps primarily with negotiations: if you don’t like the deal you can leave and if you like it you can move all applications to that cloud. And if a cloud vendor starts competing with your business you can pack your applications up and leave.

At GitLab we’re thinking about helping people test for application portability. For this multi-cloud validation of applications we plan to use cross-cloud ci made by the Cloud Native Compute Foundation (CNCF). This software ensures that their projects work across all clouds.