Navigating the Multicloud Spectrum

There’s no single approach to cloud applications

The move to cloud platforms presents enterprises with various challenges, one of which is the use of multiple clouds. Multicloud environments are perhaps the number-one discussion when it comes to the use of public or private cloud services. There’s an acceptance that organizations will use more than one cloud — most already do — but the question of how best to do this has no single answer.

Multicloud strategies have obvious benefits: not being beholden (or locked in) to a single platform or supplier; an outage on a single cloud does not affect 100% of cloud workloads; different clouds offer different benefits. Tied into this is the concept of workload portability — the ability to run the same workload in different clouds. For some organizations, regulation may be a driver.

Although the reasons for multicloud usage are varied, there are essentially two philosophies when it comes to implementation:

• Cloud-agnostic — the idea that a workload can run on any cloud and is not intrinsically linked to a specific platform
• Workloads should embrace capabilities specific to a given cloud platform

The first approach better supports portability; the second is more about matching workloads to clouds. The philosophies are not black and white; there’s a spectrum between the two. The question is where the value lies when considering the business strategy the workload is supporting. Part of the answer depends on the type of business.

When Portability Is King

We’re seeing software providers that have typically run their own infrastructure starting to move into the public cloud. Recently Salesforce announced Hyperforce, a way of running certain Salesforce workloads in public clouds. Adobe and Box have made similar moves, and even IBM has enabled products previously tied to its own cloud platform to run on Amazon Web Services (AWS) or Microsoft Azure.

For software suppliers, it moves them out of supporting infrastructure. With public clouds already having significant presence around the world and specializing in scalable infrastructure — including building their own hardware — it makes good sense to make use of them rather than trying to replicate them or even emulate them. For customers, the benefit is being able to run workloads and data where they want.

The challenge is building solutions that can run in different clouds. A lesson learned early in the evolution of cloud platforms was that the “lift and shift” of traditional applications to the cloud is often not successful. Optimization for cloud is essential. Salesforce describes Hyperforce as a “complete re-architecture” of its products.

The multicloud challenge of optimization is how to do it in a way that doesn’t lean heavily on the capabilities of a specific cloud. Although Hyperforce aims to run in public clouds, it is currently skewed toward AWS, a similar scenario to when VMware moved its traditional on-premises products to the cloud.

There are software products that create a common platform across different clouds — for example, Red Hat OpenShift and Google Anthos. Instead of building for the underlying cloud, companies can design and build workloads to run on these abstractions. The workload can be moved anywhere that runs that platform. This provides consistency for architects, developers and operations teams.

The counterargument to this approach is that it doesn’t exploit the value in the underlying cloud. Software provider Canonical attempts to address this problem through its Juju charms — pre-written scripts to add components to cloud-native applications. Charms provide consistency for those working on top of the platform while optimizing for what is underneath.

Embrace What Makes a Cloud Unique

For software providers, portability is a priority, because customers will want to run the same product with all the same benefits in different clouds. For an enterprise, this may not be true. An enterprise can target a workload at a specific cloud and so optimize for that platform and take advantage of proprietary capabilities.

For example, object storage on AWS is probably best done by using its Simple Storage Service (S3). That creates a dependency between the workload and AWS, but there’s a strong case that the value derived from using S3 is greater. Arguably, running workloads in public clouds and not exploiting their unique capabilities isn’t cost-effective, and it makes economic sense to run them in a traditional data centre. Another strong argument is that not harnessing a cloud platform’s unique properties means you’re not creating a truly cloud-optimized solution.

Success Is Finding Your Place on the Spectrum

Multicloud environments will be the future for many, but each organization will need to find the multicloud strategy that suits their specific business model. For software providers, this will focus on portability, whereas for many enterprises the answer may be targeting workloads at specific cloud platforms. Each will need to look inward at their own requirements and capabilities and not to a single answer from outside.