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.

Sid Sijbrandij
Dec 3, 2018 · 2 min read

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.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Start a blog

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store