Are you ready for multicloud? A checklist

Perhaps you deployed your first cloud-native Node.js application to Amazon Web Services and then received a new assignment to port over several legacy .NET applications to a public cloud. Should you try Amazon Lightsail as a first step, or should you review Microsoft Azure’s options for .NET developers?

Or maybe your team has applications running on Azure that need to securely connect to machine learning models deployed by the data science team on Google Cloud Platform. It’s easy to conceive scenarios where development and data science teams end up exploring, prototyping, and deploying applications, databases, microservices, and machine learning models to multiple public clouds.

For larger enterprises, supporting multiple clouds is almost inevitable, due to the herculean level of governance required to channel all development, data science, and shadow IT efforts to a single public cloud. Even so, there are several reasons why global businesses and larger enterprises determine that “being multicloud” is strategically important.

I reached out to several experienced IT leaders active on Twitter through social chats like IDGTechTalk and CIOChat to get their perspectives on whether and how organizations should support multiple clouds. I’ve included their opinions and insights in this checklist on multicloud readiness. Are you ready?

Ease into multicloud complexities 

IT leaders know the complexities of setting up secure and robust cloud infrastructures. Naturally, these complexities multiply when you combine multiple clouds. You should strive to avoid dealing with them all at once. 

Operating across multiple clouds is complex because of the required governance, technical expertise, and integrations. As Sarbjeet Johal, an independent technology strategist, puts it, “Nobody gets up in the morning and says we are going to do multicloud today. They just fall into it, mainly due to organizational silos. Multicloud is as easy as 1-2-3… said no one ever!”

Joanne Friedman, Ph.D. and CEO of Connektedminds, suggests that IT teams leverage their primary cloud provider wherever possible, rather than hunt for new or better capabilities in a second provider. “Accept that there is no one size fits all in public clouds, and only 40% to 60% of what is required can be found with one provider,” she advises. 

Other IT leaders share pragmatic viewpoints on how multiclouds evolve and how to navigate initial complexities. Travis Campbell, a big data consultant, offers this insight into where the multicloud journey begins:

Companies doing ‘multicloud’ but really treating it as a single cloud by each line of business are a special case here. For example, finance may have applications on cloud X, while engineering is deploying to cloud Y, and there’s no cross-pollination of work and data. It’s multicloud without hard problems.

So, in the case of organizations already operating multiple clouds independently for different purposes, an inevitable next step would be application integrations, data integrations, or service orchestrations across those clouds. This is where those hard problems begin. It’s best to proceed slowly and cautiously. 

Make the case for a multicloud architecture

Other IT leaders chimed in with similar sentiments. Specifically, many noted that supporting multicloud isn’t easy today, and that IT leaders should identify strong business rationale before endorsing a multicloud architecture. I asked them to identify some of the reasons why they might seek multicloud architectures.

Mark Thiele, CEO and Founder of Edgevana, outlines a number of strategic benefits to seek from multicloud architectures. “I would target multicloud when it provides my customers with one or more of significant price value, speed to market, a unique technical capability that drives better value, innovation, and performance improvements,” he says. 

Mike D. Kail, Executive Technologist at Palo Alto Strategy Group, agrees. “The main reason [to consider multicloud] is when a cloud service provider offers a service that is far and above better than the one used in your initial deployments,” he says. “An example would be TensorFlow for artificial intelligence and machine learning.”

Ed Featherston, Distinguished Technologist at HPE, seconds that view, and provides some operational guidance:

Many organizations I work with select one platform as their main focus, and other platforms based on business benefit for specific needs and solutions. IT leaders must define how they approach multicloud from a strategy, support, and process perspective. When other platforms are brought in, there is a framework and structure to provide consistency in their approach. Don’t let it be because of “cloud sprawl,” as that always results in disaster.

Chris Ibbitson, Chief Technologist of Financial Services at HPE, says that enterprises seek agility in public and private clouds. “Whether it is with public cloud providers, or in a hybrid cloud model, utilizing a mix of private cloud capabilities and multiple public cloud providers is focused on the agility and speed of delivering change,” he says. “While most organizations have already adopted some form of hybrid cloud, the focus is now turning to multicloud.”

So IT might bring in a second cloud service provider to support a specific business or technical need. In these cases, IT leaders should define which businesses and use cases each cloud will serve and which services and technologies each cloud will provide. 

Johal and others shared some additional reasons:

• Large enterprises seek to avoid being reliant on a single cloud service provider, especially if they expect to negotiate enterprise-specific service levels and pricing.
• Data sovereignty and compliance often require storing data in the country of residence, specific requirements on encryption and data security, or even specificity on acceptable cloud service providers.
• Organizations seeking mergers and acquisitions often target multiple cloud service providers and support models to enable easy onboarding and to simplify support structures.
• IT requires specific technical capabilities, especially at scale, where there might be strategic business advantages in deploying to one cloud service provider versus another.
• When IT elects to self-manage a commercially bought application that runs on a public cloud that’s different from the public cloud IT has adopted as their development standard. Industry-specific and other niche applications may provide the structure and support models on a single cloud service provider.

There are also places where hybrid and multicloud architectures offer technical advantages, especially for edge computing, human safety applications, and real-time analytics.

Review cloud support models before going multicloud

While businesses may have some rationale to support a multicloud architecture, IT leaders still strongly suggest performing financial analyses and reviewing your cloud operating models.

Kail suggests answering these questions, “Are the benefits going to be greater than the complexities of deploying and operating a multicloud architecture? Are there financial implications, both short and long term?”

Steven Kaplan, Vice President of Customer Success Finance at Nutanix, agrees. He suggests, “As with any significant IT decision, it’s imperative to do a comprehensive financial analysis not only to select the most strategically optimal solution but to provide both the justification and financial baseline for moving forward.”

When there is justification, IT must consider extending their service models and expertise from one cloud to multicloud. Featherston notes that cloud is more about people, process, and culture than it is about the technology. “Organizations should try to get through those dramatic transformations in their organization for one platform first to lay the groundwork and provide the framework to move forward on other platforms,” he says. “Basically, get one cloud right first, then branch out.”

Thiele offers several specific practices that should be in place before expanding multicloud. “The ability to coordinate common processes around security, deployment, visibility, and resource management, among other things, is vital. Having well-defined devops and devsecops processes and tools enable both improved efficiency and more consistent security policy.”

Friedman’s recommendation is to start with infrastructure as code tools. “They support a form of infrastructure automation and configuration,” she notes. “While they don’t address the entire scope of cloud governance, having programmable and version-controlled infrastructure is important.”

Embrace devops to support multicloud architectures

I agree with Thiele and Friedman that robust devsecops practices—especially around CI/CD for deploying applications, infrastructure as code for provisioning and configuring infrastructure, and monitoring capabilities including AIops—are critical to both implementing and supporting multicloud architectures.

But what I learned from this group of IT leaders is that not just any devops technology or devops practices will do, as some are better suited for multicloud strategies than others. One approach is to steer away from the proprietary tools of cloud service providers, such as AWS CloudFormation, Azure Resource Manager, or Google Cloud Deployment Manager, even as some are providing multicloud support. Enterprise IT groups should also expand their devops culture from a deployment-frequency focus to include deployment agility.

Kail has a specific recommendation. “Infrastructure-as-code should be table stakes to mitigate configuration drift, and of course security needs to be architected from day one,” he notes. “Tools such as Terraform certainly help. Security solutions that can span multicloud are also paramount.”

Multiple IT leaders recommended Terraform for multicloud architectures because it’s a declarative, agentless, masterless provisioning tool. One recommended architecture pairs Terraform with Packer, Docker, and Kubernetes to support provisioning, server templating, and orchestration.

However, selecting a multicloud-enabling tool doesn’t mean the implementation supports multiple clouds. Featherston recommends Terraform, but with a disclaimer. “The one caveat I have is making sure clients understand, it’s a common language to use on multiple platforms, but the code to build AWS does not build Azure,” he explains. “The benefit is that the team has a common language to code in, but the tradeoff is that not all platform features may be available.”

Beyond infrastructure as code, Friedman recommends the following tools, practices, and governance to meet multicloud requirements:

• Automation and orchestration for both applications and individual virtual machines
• Security including identity management and data protection/encryption
• Policy governance and compliance including audits and SLA metrics
• Performance monitoring of both the infrastructure (i.e. compute instances, storage, networks) and applications
• Cost management through resource optimization and billing estimates

Technology companies are also selling multicloud enabling technologies. For example, HPE GreenLake Central provides visibility into cost and compliance across different cloud providers, and Google Cloud Anthos enables a consistent development and operations experience for hybrid and multicloud environments.

Prepare for a multicloud future

Despite all of the complexities today in adopting multiple public clouds, the consensus among IT leaders is that most enterprises will support multicloud architectures, and even integrate applications across clouds. We can use history as a lesson, as enterprises had to support Linux and Windows, .NET and Java, and Oracle and Microsoft SQL databases, to name just a few examples—despite all of the rationale behind sticking to one platform.

Some final thoughts from these leaders:

• “I expect we’ll see an evolution of multicloud over the next three to five years, whereby more workloads are designed and abstracted away from the underlying cloud provider by default. The focus will be on the advanced capabilities different cloud providers can enable, such as artificial intelligence, machine learning, and analytics.” – Chris Ibbitson
• ”Solve for a single cloud first, then determine if multicloud is right for you.” – Mike D. Kail
• “Multicloud architectures are hard and expensive to maintain. Be strategic about single cloud providers and tactical about multicloud undertakings. Avoid doing multicloud at the infrastructure layer for the same workloads at almost all costs.” – Sarbjeet Johal
• “Opt for the paths of least resistance, focus on security first, then automation and orchestration inculcated through policy.” – Joanne Friedman

Travis Campbell sums it up well:

I think the people being successful at this are doing lowest common denominator stuff and using the barest minimum on each provider with their layer baked on top to handle the abstraction. Build once, run anywhere is the golden ticket we’re all seeking. We’re still a ways out.

Thanks to these contributors for sharing their experience and insight. You can find all of them on Twitter: @efeatherston, @ibbitsc, @joannefriedman, @mdkail, @mthiele10,  @ROIdude, and @sarbjeetjohal.