Companies of every shape and size are moving away from using their own physical hardware to instead gain more agility and potentially reduce maintenance and costs by using a public cloud provider. But making the move brings up a major, complex decision: Which one will deliver the services and infrastructure your business needs? The choice of, say, Amazon Web Services (AWS) over Microsoft Azure or Google Cloud isn’t always clear, and each raises specific issues over long-term business impacts.

Yet you may not have to choose. As an enterprise, you’ll very likely need to deploy two or more of the major public cloud providers to support your teams’ specific technical needs. And with the right combination of providers, deft integration of the technology, and thoughtfully designed work processes, the advantages of multi-cloud can far outweigh any extra effort that’s required.

Evaluating the benefits of multi-cloud

Of course, that’s not to suggest that remaining provider-agnostic comes completely without cost, so the first question your organization should ask before proceeding is, "Will we benefit?" There are numerous conditions and types of businesses for which the answer is a resounding yes. Distributing your most business-critical workloads across multiple clouds may ensure better uptime and availability. And for less critical workloads, being multi-cloud also allows better selection for specialization, as each of the cloud providers have specialized areas (for example, machine learning) where they have competitive advantages.

There are business reasons to deploy multi-cloud as well. Some software as a service (SaaS) companies have clients that are sensitive about whom they support with their hosting dollars, such as retailers who are opposed to AWS. Other companies might be intent on avoiding vendor lock-in, either so they can flexibly shift workloads as cloud provider services evolve, or to stay competitive in negotiations with vendors.

Navigating the challenges of a multi-cloud strategy

Companies that opt for a multi-cloud approach should develop them as a targeted, strategic service where every feature delivers additional value and is driven by the needs of the business. A crucial part of that is implementing new policies and procedures that will make the best use of teams within the organization — creating new ones where necessary — and reducing their burden.

The process should begin with a dedicated in-house cloud platform engineering team, which develops a roadmap that outlines the services the setup will enable, as well as the timeline. Those services must be directly aligned with their downstream consumers, so companies should assemble a steering committee that can provide continuous input on the priority of the items in workstreams. The committee might examine whether there is greater demand for solutions on AWS than on Azure App Service, for instance, thereby letting the business inform decisions on new enhancements. Membership in the committee will depend on organizational structure, but on a high level, companies should be looking at senior members of the technical business who represent a diverse view of use cases for the cloud (for example, product-group directors or vertical-business-unit technical directors).

The leader of the cloud-platform team should take responsibility for creating and maintaining the roadmap in a format that’s accessible to all business units, taking notes on discussions and prioritization during steering committee meetings and then disseminating them to the members. Large organizations could consider publishing a regular newsletter or a multichannel distribution method regarding progress on the roadmap.

Establish clear criteria and alignment for each business unit and cloud provider

Rarely will an individual business unit need to leverage both clouds simultaneously. Business units should be enabled to select which cloud to use by building a clear set of selection criteria that combines the advantages of one cloud over another — Microsoft Azure’s ability to deploy the Office suite, for example, or AWS’s better support for open-source apps and tooling — with the company cloud roadmap enabling those services.

Each vertical or business unit should then select and deploy their workloads to that single cloud , building expertise on it while the enterprise architecture team continues to ensure that each public cloud’s underlying services enablement is supported equally.

How to build the cloud platform engineering function

Expecting business application teams to keep pace with both the technologies required for their solutions and the underlying services offered by the cloud providers is a recipe for messy configuration and insecure technologies. That’s why it’s important to build out the cloud platform engineering team: It’s an effective way to execute the roadmap and ensure cloud services stay relevant, secure, and modern. This team can be structured like any other engineering team in the organization, operating using the same design-develop-deliver framework (Scrum, Kanban, or Waterfall, for instance) and project management tooling other developers in the organization follow. Cloud platform engineering teams will vary by skillset — with a mix of cloud services configuration, infrastructure and policy as code, networking architecture, devSecOps (development, security, and operations), and information security expertise — rather than by structure or ceremony. The team should be encouraged to leverage cloud providers’ certification tracks. (As a bonus, allowing the team to work across multiple clouds, or to rotate between them occasionally, can also assist with talent retention.)

Managing the different clouds and configuring services within them (as well as staying current with terminology and services offered) requires serious effort. But with a strategic roadmap aligned to each business, and a core team delivering value to the application workstreams, companies can make multi-cloud an indispensable tool.