3 years ago

With the goal of bringing more productive discussions on this topic into focus and understanding which types of multicloud capabilities are worth pursuing, this series continues with a look at multicloud through the lens of workload portability. Different vendors have different APIs, semantics, capabilities, syntax and other nuances that make workload portability, in reality, one of the most challenging forms of multicloud portability.

You also need to decide what type of data portability you’re going to use, and the trade-offs are the same as they were in the first article in this series: Your decision on frequency needs to be the same as your decision about how often you intend to migrate workloads, and that depends on whether you plan to port workloads frequently (in this case, use continuous replication) or on rare occasions (in this case, break-glass may work).

These include: Before you consider this form of workload portability, you need to answer this question — will your potential compute cost savings be negated by higher bandwidth costs and performance degradation?

This type of workload portability doesn’t require as much data portability, leaving you to focus on workflow portability, which can usually be accomplished with automation tools for deploying across multiple clouds and hybrid clouds.