Navigating Today’s Multi-Cloud Complexity Challenges

A multi-cloud strategy is an infrastructure strategy where compute infrastructure and services are consumed from two or more cloud providers. The services consumed are typically in the form of Infrastructure-as-a-Service (IaaS) or Platform-as-a-service (PaaS). However, other services can be included such as Disaster Recovery.

Businesses often opt for a multi-cloud strategy to reduce reliance on a single provider, which can provide better cost optimizations and removing the provider as a single point of failure. Also, businesses use multi-cloud to reduce the level of vendor lock-in, which can increase expense and reduce agility.

A business might run their workflows with Amazon Web Services (AWS) while using Microsoft Azure storage services as a backup or replication target. By taking this approach the business is ensuring that their data is available from two independent storage services. If the volume of data is quite large, the business might pursue this strategy due to the pricing difference between the vendors.

Assessing the real cost of replicating data to another provider is not always straightforward, despite the pricing being publicly available. The source cloud provider is very likely to charge for the egress data volume. It may be cheaper to replicate the data to a storage service from the same provider in a different region or zone.

The consumption of services, even those which are very similar, vary significantly between cloud providers. Application services are typically confined to the same cloud provider, distributing across multiple providers is highly unlikely due to issues such as data transfer costs, data locality, and latency.

Making an application provider-agnostic limits the number of provider services the application can consume. Other cloud providers may not have a service that provides the same functionality. If the application uses such a service then moving to another provider is going to be very difficult.

Database-as-a-Service (DBaaS) is a common feature from most cloud providers. However, the available features and limitations are going to differ between providers. Typically, this means this limits the features available as advanced features or options may not be available elsewhere, or additional third-party services are required to provide these features across vendors.

Public cloud providers offered hundreds of different services that evolve at a blistering cadence. Keeping abreast of a provider’s portfolio and continual updates significant time investment and each additional provider in a multi-cloud strategy increases the time required.

Service changes become less drastic over time as the service matures. Therefore, additional management overhead occurs by consuming an immature service.

Standard frameworks for managing cloud services are available from third-party tools such as Terraform. However, infrastructure configuration settings vary greatly between cloud providers. To deploy the same application at different providers requires provider-specific configuration files for each provider. Provider-specific configuration files are not just limited to infrastructure, OS and application configuration workflows may require infrastructure information. Methods to gather information changes between cloud providers.

A diverse skill set is required amongst the team managing the cloud-based infrastructure and services to cover each cloud provider. Everyone cannot know everything about all cloud providers. However, to prevent knowledge silo’s it is essential to ensure and encourage knowledge sharing. Informal training strategies such as ‘lunch and learn’ sessions encourage knowledge sharing amongst team members and provide an excellent forum for discussion. Also, small information training sessions can help keep up to date with the rapid rate of change experienced in cloud environments.

Consuming a Kubernetes based container service enables configuration reuse across providers from the container level up. However, each provider has its own set of API for configuring the service itself.

Using third-party tools to provide a simple front-end for consuming cloud services can help to flatten the learning curve, but they are not a silver bullet. There is no substitute for maintaining a functional working knowledge of the cloud environment.

Implementing a multi-cloud strategy is an excellent approach for the consumption of services, but there are challenges to address up front. When assessing a multi-cloud strategy make the determination based on the applications and which provider is best suited for a specific application.