How to Improve Your Multicloud Strategy

— Written by Chris Gibes, Tim Keating and Mark Yorko.

As organizations build multicloud environments, it’s important that they think strategically about guiding principles and capabilities. Multicloud may involve any combination of the major hyperscale public cloud platforms — Microsoft Azure, Amazon Web Services and Google Cloud Platform — or a hybrid that also includes private clouds.

Learn how CDW can help you gain business agility through DevOps.

For many organizations, multicloud works because it lets them use the provider that offers the best features, security, resilience or cost-effectiveness for a specific workload, without limiting them to a single option. Multicloud also facilitates the DevOps objective of providing rapid time to value for features or products. The ability to accelerate the frequency and quality of releases is a paramount goal of DevOps, and a well-maintained multicloud solution can help organizations achieve that objective.

Both multicloud and DevOps thrive on rapid-response flexibility, and that makes it essential to have a strategy that can guide important decisions.

Get Developers Involved in Cloud Selection and Strategy

Support your developers by involving them in decisions about the public cloud platform they’ll be using. Each provider has distinct tools and features that may work well for one team but not as well for another. The risk, otherwise, is that developers may find their own workarounds that don’t align with the overall strategy.

Similarly, from a DevOps perspective, transparency in a multicloud strategy is important. The developers using the service should have direct, real-time visibility into applicable policy and processes. A strong governance policy should be incorporated into multicloud management so that as the DevOps pipeline consumes cloud resources, it follows the appropriate constructs in a programmatic and automated way.

Design for Cloud-Native Environments and Portability

Designing applications to utilize cloud-native patterns (microservices deployed as containers and managed via Kubernetes) makes it easier to move those applications to another provider if the need arises — for example, in response to a security issue or a competitive concern. By assuming that whatever you deploy may, at some point, be deployed in the cloud, you’ll have a smoother transition if the organization later decides to migrate the application or move to a different public cloud.

Designing for portability also increases resiliency: It yields greater freedom to choose the cloud provider that best meets needs at a particular time, for a particular project.

Plan Ahead for Your Cloud Exit Strategy

An important component of portability is thinking upfront about an exit strategy, but this is often an overlooked issue. If an organization has amassed large amounts of data in a public cloud and later needs to evacuate, it may be on the hook for significant egress fees. The migration process may still be difficult, even if it’s well planned. But organizations that consider exit strategies early stand a better chance of minimizing the financial and logistical consequences.

Optimize Data Gravity in Multicloud Environments

Latency takes on new complexity when multiple clouds are involved. The latency of data traveling rack to rack in a data center is one thing; data that has to traverse the internet, introducing latency in each transaction, is a much bigger problem. The best practice, of course, is to keep the compute close to the data (which exhibits the concept of data gravity). It takes planning to think about potential data sources and applications to reduce the risk that application performance will suffer.

For example, suppose an app running in one cloud will require data in another cloud. To minimize latency, an organization may choose to place the data with the provider where the workload will happen, even if that wouldn’t otherwise be the best fit — because ultimately, performance will improve.

Build Your Organization’s Multicloud Capabilities

Every cloud provider is different, and each is continually improving. Exploring different environments on a small scale before you need to move a major project is a good way to learn the various tools and features. Start with a low-risk project — perhaps a less critical initiative requiring a one-time capability — that can expand your team’s experience. This also gives the organization practice at taking an established set of best practices and adapting them to a new environment.

Looking to learn more about DevOps? Subscribe to CDW’s Simplifying DevOps podcast.