Issue 1

BIOS Multi-Cloud

Managed Services across the region’s leading cloud

Technology Insight for Multicloud Computing

Most organizations will use more than one public cloud provider. Enterprise architecture and technology innovation leaders must select the multicloud strategy that best fits their business needs.

Key Findings

  • Most organizations will pursue a multicloud strategy, although most will also designate a primary cloud provider for a particular purpose, and are likely to have 80% or more of those types of workloads in their primary provider.
  • Because most organizations will have a multicloud strategy, they will also need to implement multicloud management to achieve some degree of common governance and tooling for those multiple cloud providers.
  • Most organizations will have at least one application that uses a multicloud architecture, typically through the use of a cloud infrastructure as a service (IaaS) provider in conjunction with multiple platform as a service (PaaS) components from different providers. However, very few organizations will migrate applications from one cloud provider to another. Such migrations will usually require significant manual effort, rather than being highly automated.

Recommendations

Enterprise architecture and technology innovation (EA&TI) leaders planning cloud strategy or architecting cloud-based applications should:

  • Choose a primary strategic provider for a particular function, such as IaaS, to maximize the ability to exploit a provider’s capabilities, concentrate employee skills and third-party partner relationships, simplify vendor management, and maximize discounts. However, adopt a multicloud strategy to maximize access to technology choices and innovative capabilities, and reduce vendor concentration risks.
  • Implement cloud-provider-native management to simplify integration, rapidly take advantage of new innovative capabilities and maximize value. However, pursue a multicloud management approach that also allows you to adopt common policies, procedures, processes and tools, when valuable.
  • Use a multicloud application architecture where necessary to exploit unique capabilities from multiple providers, such as vertical-specific APIs. Do not use a multicloud architecture to try to save money; it adds significant complexity and increases application life cycle costs.

Analysis

Most organizations have already adopted multiple cloud computing providers for different applications and use cases. Increasingly, though, organizations are adopting multiple public cloud providers that directly compete for the same types of use cases. A multicloud strategy can help a customer gain access to a broader range of capabilities, especially bleeding-edge innovative capabilities. However, a multicloud strategy also creates multicloud management and governance challenges. Most applications won’t migrate between cloud providers, due to portability challenges, but most applications don’t require such portability. However, an increasing number of applications will have a multicloud architecture — compositing together services from multiple public cloud providers — creating integration and operations challenges.

Definition

Multicloud computing refers to the use of cloud services from multiple public cloud providers for the same purpose. It is a special case of hybrid cloud computing, which is a broader term.

Hybrid cloud computing is defined as the policy-based and coordinated service provisioning, use, and management across a mixture of internal and external cloud services.

Description

On a practical level, EA&TI leaders typically think of multicloud computing as the use of one or more cloud providers for broadly similar purposes. For instance, an organization might adopt multiple cloud infrastructure as a service providers, such as Amazon Web Services (AWS) and Microsoft Azure. Multicloud computing commonly includes both IaaS and PaaS providers. It is rare for multicloud computing to include SaaS providers. Most customers adopt multiple SaaS providers for distinct purposes and almost never use multiple SaaS providers for the same thing. The exceptions are typically more-infrastructure-like use cases — for instance, the use of both OneDrive and Box for enterprise file sync and sharing solutions.

Multicloud computing, by the Gartner definition, does not refer to the simple use of multiple cloud services within the organization — only the use of multiple providers for the same purpose. Most organizations will use many cloud providers for different purposes, but this is not multicloud computing. Similarly, the Gartner definition of multicloud computing does not encompass the use of private cloud services. We refer to the use of public and private cloud computing together as “hybrid cloud.”

Multicloud computing considerations broadly fall into three buckets:

  • Multicloud strategy. Most organizations will have a multicloud sourcing strategy. This requires a strategy for vendor management, a framework for workload placement, and a strategy for developing and maintaining employee skills.
  • Multicloud management. While it is impractical, and often suboptimal, to manage multiple cloud providers in an identical fashion, it is best to have a coordinated approach to multicloud management and governance. This includes enabling standardization of some policies, procedures and processes. It also includes sharing some tools, especially tools that allow cost governance and optimization across multiple cloud providers. This also has an impact on developers, especially in DevOps-oriented organizations, as it affects the tools used across the application life cycle, such as continuous integration and continuous deployment (CI/CD) tools.
  • Multicloud architecture. Some applications span multiple cloud providers. Indeed, some applications may be a composite of multiple different types of services and providers. For instance, there may be integrated IaaS and PaaS (IaaS+PaaS) from a single provider, along with other PaaS elements from multiple providers, such as an integration PaaS, vertical-specific components or API services such as a voice API. Some applications may also be deployed on different cloud providers at different times; for instance, a batch-job application might be deployed to the least expensive cloud provider at a given time.

Multicloud Architectures

There are two primary types of multicloud architectures:

  • Redundant multicloud architecture: An application is deployed, in its entirety, to multiple cloud providers (see Figure 1).
  • Composite multicloud architecture: A single application is split across multiple cloud providers; different application components come from different cloud providers (see Figure 2).

Figure 1. Redundant Multicloud Architecture

figure 1

Source: Gartner (August 2018)

Figure 2. Composite Multicloud Architecture

figure 2

Source: Gartner (August 2018)

Redundant Multicloud Architecture

There are two types of redundant multicloud architectures:

  • Continuously replicated. The entire application is replicated on two or more cloud providers. This may use an active-active architecture, where all of the application copies are in continuous use, or an active-passive architecture, where only some of the application copies are in use. For instance, in an active-active deployment, you might choose to run one instance of your e-commerce website on Cloud A and another instance on Cloud B, and use global load-balancing to direct customer traffic between these two sites. In an active-passive deployment, one instance would run on Cloud A and another on Cloud B, but traffic would always go to Cloud A unless you fail over to Cloud B.
  • One-time placement. The entire application is portable between at least two cloud providers, but it only runs on one cloud provider at a time. For instance, you might have a short-term batch workload and associated data. At the time you want to run the batch job, you look at which provider is offering the lowest price, and then run the workload on that provider.

Disaster recovery from one cloud provider into another cloud provider is also a form of redundant multicloud architecture. It may have the characteristics of either the continuously replicated or one-time placement architectures.

Composite Multicloud Architecture

Most applications use a single-cloud core. In this model, the core of the application — most of its system and application infrastructure, along with much of its data — is placed in a single cloud provider. If such applications have components that use one or more services from another cloud provider, they have a composite multicloud architectures. There are two common types of such services:

  • External API services. External cloud-based API services often offer specialized capabilities, such as Twilio’s voice APIs, Stripe’s payment APIs and SendGrid’s email APIs. Customers may prefer services that are hosted in the same cloud provider as the rest of the application. For instance, an application might be hosted on AWS but use Twilio’s API services.
  • Supplementary services. A variety of providers supply cloud software infrastructure services. Customers usually choose services that are hosted in the same cloud provider that they are using for the majority of the application — preferably in the same region. For instance, an application might be hosted on AWS, but use the MongoDB Atlas database service (which is sold by MongoDB and deployed on AWS).

Other models of composite multicloud architectures — all of which can be combined with external API and supplementary services, as well as with the other models — include:

  • Multicloud core with aPaaS on IaaS. The core of the application is located in a single cloud provider, but an application PaaS (aPaaS) offered by another cloud provider is layered on top of the primary provider’s IaaS. The aPaaS may be used for some or all of the core application components. For instance, an application might use Heroku (an aPaaS that is hosted on AWS) in conjunction with other AWS services.
  • Multicloud core components. The core of the application is divided into components that are located in different cloud providers. For instance, in an e-commerce site, the web servers and other customer-facing infrastructure might be in AWS, and the SAP system used for fulfillment might be in Azure. Application components that need low-latency access to one another are typically kept within a single cloud provider.
  • Single-cloud core with redundant multicloud components. This is a form of redundant composite multicloud architecture. The core of the application is placed in a single cloud provider, but one or more application components are distributed across multiple cloud providers. The most common form of this is multicloud object storage. For instance, an application might be hosted in AWS, but use a combination of Amazon S3, Azure Blob Storage and Google Cloud Storage for its object storage needs.

Benefits and Uses

Broadly, organizations typically pursue multicloud computing to obtain greater breadth of capabilities and to reduce concentration risk.

Reasons to Adopt a Multicloud Strategy

Organizations typically adopt a multicloud strategy for one or more of the following reasons:

  • Access to a breadth of capabilities. No single cloud provider offers a comprehensive set of services. Because cloud providers are differentiated, and have strengths, weaknesses and unique capabilities, adopting a multicloud strategy allows access to best-of-breed capabilities. It allows technical teams to determine the best placement for a given application, based on its business and technical requirements.
  • Access to innovation. Cloud providers sometimes leapfrog each other in capabilities. For customers for whom immediate access to the newest innovations is of critical importance, a multicloud strategy allows them to quickly take advantage of new capabilities as soon as they are introduced into the market.
  • Access to a broader range of geographies. While there is significant overlap in the data center locations of global cloud providers, some cloud providers may have unique locations. Furthermore, customers with unusual geographic requirements may need to use local cloud providers.
  • Reduction of vendor concentration risk. Some customers believe that placing most of their applications in a single cloud provider creates the risk that a service change could have widespread impact on their overall application portfolio. Some customers are also concerned about the potential for massive outages. For instance, in 2012 and 2014, there were Microsoft Azure outages that impacted nearly all Azure regions worldwide.
  • Reduction of vendor-viability risk. Some customers, especially those who use smaller cloud providers, are concerned about their provider’s financial stability, commitment to the market or longevity of the cloud service they are currently using. Consequently, they want other cloud options.
  • Perceived vendor-negotiation advantages from supplier diversity. Some customers believe that they may be able to negotiate better prices or better contract terms if they have the option to use multiple cloud providers. However, Gartner’s extensive experience evaluating competitive contracts indicates that cloud provider prices are relatively unaffected by competitive pressures.
  • Inherited cloud providers from a merger or acquisition. Companies that grow inorganically often find that the entities obtained from mergers and acquisitions (M&As) use other cloud providers. Such companies need a multicloud strategy, even if their ultimate goal is to consolidate cloud providers.

Vendors that deliver cloud-based services — for instance, SaaS vendors, PaaS vendors, data as a service vendors and cloud MSPs — may have additional reasons for adopting a multicloud strategy, such as:

  • Access to more customers. Potential customers use different cloud providers. Some customers want their other cloud-based solutions to be hosted in the same cloud provider as the applications that those solutions integrate with. Therefore, a multicloud strategy increases the vendor’s addressable market.
  • Access to more data. Data is located in multiple cloud providers. Many cloud-based services benefit from being closer to the customer’s data.

Therefore, a vendor that benefits from being able to access and integrate with more data generally benefits from being multicloud.

Reasons to Adopt Multicloud Management

Public cloud service providers, in general, do not provide commodity services, even if some of these services might initially appear to be relatively similar. Therefore, these services cannot be managed in an identical fashion. The “single pane of glass” is an unrealistic expectation and, in most cases, will be suboptimal.

Furthermore, cloud IaaS should not be managed like on-premises infrastructure, with one exception — cloud IaaS providers that offer “rented virtualization,” typically using VMware vCloud Director, and have service offerings that are nearly identical to on-premises virtualized data centers.

Moreover, multicloud management should not be conflated with management of both cloud and traditional on-premises environments. Nor should it be conflated with managing “private cloud” environments that do not have full self-service automation and API control (in other words, that are simply “cloud-inspired” rather than true cloud services).

However, organizations have many reasons to want to achieve some multicloud commonalities in application development, operations, governance, tools and resources, such as:

  • Shared processes. Process commonalities can help disparate teams work in a coordinated fashion with one another. Best practices can be more readily applied across teams. Even if a given process flow is implemented differently for one cloud provider than another, the common steps can be beneficial. Core operational processes, such as incident management, usually benefit from being shared, even if there are specific nuances for particular cloud providers. Development teams that work with similar application stacks — for instance, in Java environments — may benefit from having a common CI/CD process, even if that process uses different tools on each cloud platform.
  • Shared skills. The more skills a group of employees has in common, the more flexibility the organization gains in the ability to allocate personnel to projects. This allows the resources assigned to a project to be augmented as necessary. For example, it is useful for some employees to be skilled at using multiple cloud platforms, even if they have a much stronger expertise with one particular cloud platform.
  • Shared visibility. It is useful to have a view across all of the cloud providers that an organization uses. This can help with cloud service expensive management (CSEM), security incident and event management (SIEM), application performance management (APM), and troubleshooting of problems that involve multiple cloud providers. Consequently, it is useful to identify tools that can be deployed in a multicloud fashion, even if they must be supplemented with additional cloud-specific tools.
  • Shared identity. It’s useful to have a single source of identity, which is then federated for use across different cloud providers. This also allows authentication and authorization policies to be centralized, even though identity and permissions are also implemented natively for each cloud provider.
  • Shared networks. There needs to be cost-effective, reliable, performant and secure connectivity between an organization’s cloud providers. It is often useful to have this planned and managed in a centralized fashion.

In other words, multicloud management is not about finding the lowest common denominator, or what is sometimes called the “commodity” functionality, and focusing on managing that. Rather, it means that points of commonality should be identified and thoughtful consideration given as to whether or not it makes sense to have a multicloud management approach to those points of commonality.

Reasons to Adopt a Multicloud Architecture

EA&TI leaders most commonly decide to use a multicloud architecture for a specific application for the following reasons:

  • Access to required functionality. No single cloud provider might have the full range of capabilities that are necessary for implementing this application. Alternatively, another cloud provider might have significantly better functionality for components of the application. For instance, the bulk of an application might be built on AWS but use Dell Boomi for integration.
  • Greater resilience. A multicloud architecture may result in overall greater application resilience by reducing the likelihood that systemic failure of any given cloud provider will result in application failure. This may be extended to encompass the potential mitigation of other vendor-related risks.
  • Lower cost. The ability to run an application on multiple cloud providers may allow the organization to lower its total cost of ownership (TCO). This is most common for pre-emptible “batch job” applications that may be able to exploit short-term deltas in provider costs. However, there may be negotiation leverage for extremely high volumes of a single service that can be used in a commodity fashion across multiple cloud providers. For instance, a consumer photo-sharing service is likely to use very high volumes of object storage and thus may have greater power to negotiate if that storage is split across multiple cloud providers.

Risks

Many organizations are currently multicloud, even if no conscious decision was made to become so. These organizations need to rationalize their multicloud usage, develop a strategy, implement multicloud management and consider when multicloud architecture is appropriate. Organizations that are not currently multicloud need to balance potential multicloud challenges with the benefits; while most organizations will decide to become multicloud, it is not the right choice for all organizations.

The Risks and Challenges of a Multicloud Strategy

The following potential drawbacks should be considered when contemplating a multicloud strategy:

  • Discounts. Because almost all cloud providers use volume-based discounts, splitting your usage across multiple cloud providers may lead to smaller discounts for each provider and, potentially, a higher overall average price.
  • Skills. Using multiple cloud providers requires maintaining skills across all of those providers. That may mean higher training costs, less flexibility in assigning staff to projects, higher pay (engineers that are expert with multiple providers typically command higher salaries), and a trade-off between depth and breadth of cloud-provider-specific skills. It may also require additional skills with multicloud architecture and engineering practices, as well as skills with multicloud tools. Finally, it may require your partners — especially IT outsourcing partners — to also possess these skills.
  • Tools. You may need to use different tools for different cloud providers to use those providers in an optimal fashion. You may also need to use multicloud tools for capabilities that should span multiple cloud providers. Thus, you are likely to need more tools, and the tools are likely to be more complex.
  • Integration. One of the greatest strengths of the leading cloud providers is the integration of their services, coupled with partner integrations with the provider, as well as integrations among partners. If you pursue a multicloud strategy, you will likely need to do more integration yourself.
  • Vendor relationship. Organizations that are very large customers of a cloud provider — or vendors that are close partners of a cloud provider — often receive significant attention and special treatment from that provider. Becoming multicloud can sometimes negatively impact this relationship.

The Risks and Challenges of Multicloud Management

In general, attempting to manage multiple cloud providers in an identical fashion is inadvisable for the following reasons:

  • Cloud providers do not deliver commodity services. While services can be superficially similar, differences rapidly become apparent, starting with the network layer and moving up the stack. Thus, they require different skills and tools to manage. When these services are integrated throughout the application stack, they also typically result in different developer tools throughout the application life cycle.
  • Tools that reduce cloud providers to the “lowest common denominator” subtract value. Most customers of hyperscale cloud providers choose these providers because of their breadth of capabilities and speed of innovation. Reducing functionality to just that which can be supported across all providers eliminates the reason for choosing a best-in-class cloud provider. Even restricting functionality based on what the tool currently supports means that the customer cannot immediately take advantage of new capabilities. Although customers sometimes believe that a least-common-denominator approach will improve workload portability and reduce lock-in, in practice, it simply changes the point of lock-in to the tool.
  • Reimplementing cloud-native functionality adds cost and risk, while reducing value. If a tool reimplements a capability across multiple cloud providers, rather than using that native capability in each cloud provider, the tool vendor now takes on the engineering costs and risks of that implementation. While it may smooth differences between providers, this usually fails to support what is differentiated and valuable about each provider's version of that capability.
  • Dependence on a third-party tool may limit the development of cloud-native skills. An organization that uses a tool may become dependent on that tool. This may lead to the organization failing to develop the knowledge and understanding of the best ways to use the cloud provider in a native fashion. Furthermore, the organization may not be able to exploit cloud-native capabilities that are not represented in its tool.

Organizations that adopt a blended multicloud management approach — taking a cloud-provider-specific management approach but using a common governance framework and tools where possible — typically encounter the following challenges:

  • It can be difficult to decide where the provider-specific versus common boundaries are. There are trade-offs between maximizing the value of a particular cloud provider and gaining the standardization-related benefits of doing more things in the same way across multiple cloud providers. This is further complicated by where the commonalities are when more than two providers are involved. For instance, AWS and Google Cloud Platform (GCP) have much greater similarities to one another than to Microsoft Azure. If a customer uses all three cloud providers, their multicloud management approach might separate out Azure more distinctively, while sharing more in common across AWS and GCP.
  • Most multicloud management tools are IaaS-centric. While cost-governance tools may span IaaS, PaaS and SaaS, nearly all other multicloud management tools are focused on IaaS. Some of those IaaS-oriented tools may also support the PaaS capabilities of the major integrated IaaS+PaaS vendors (especially AWS and Microsoft Azure), but often do not support competing independent PaaS vendors with similar capabilities.
  • Tool support varies across cloud providers. Most multicloud tools vary in their depth of functionality for each of their supported cloud providers, and all support only a select number of cloud providers. Consequently, you may find that there are capabilities that your tools only support on one cloud, which effectively means that tool is not currently multicloud for that piece of functionality.
  • Tool developers cannot keep up with each cloud provider’s rate of change. The developers of multicloud tools are enormously challenged to keep up with the rate of change of the cloud providers they support. There can be a significant delay in support for new cloud provider capabilities — if the tool ever supports them at all.
  • Tool vendor viability. Many of the independent software vendors (ISVs) that sell multicloud management tools are startups. Many such ISVs have been acquired by larger vendors, and, in many cases, the acquirers have either significantly reduced investment in the tools or have withdrawn them from the market altogether.
  • Managed service providers (MSPs) encounter similar issues. MSPs experience the same challenges with multicloud management that internal IT organizations do. Furthermore, many MSPs have varying levels of support for different cloud providers, making it difficult, and sometimes suboptimal, to use a single MSP.

The end result is that organizations that perform multicloud management generally need to develop different operational run books — for both manual and automated processes — for different cloud providers. These provider-specific efforts increase complexity and may increase cost. Yet efforts made to maximize common management approaches across cloud providers may actually contribute to increased complexity and cost, rather than decreasing them.

The Risks and Challenges of a Multicloud Architecture

Risks and challenges that apply to multicloud architecture in general include:

  • Complexity. Applications that use a multicloud architecture are typically more complex than applications that use only one cloud provider. This increases the number of potential risks, as well as the scope of the development and operations challenges.
  • Unmet expectations. Stakeholders may have the tendency to overestimate the benefits that will be created by a multicloud architecture. This can be particularly severe for expectations of a good return on investment for application portability between cloud providers. Stakeholders may also significantly underestimate the technical challenges of building and running multicloud applications.
  • Cost. The complexity of a multicloud application typically leads to higher costs throughout the application life cycle. Initial and ongoing development of the application is typically more costly, and ongoing operations costs are also often higher.

Risks and Challenges of a Redundant Multicloud Architecture

A redundant multicloud architecture requires that the application be ported to a minimum of two cloud providers. This requires porting the application itself, its infrastructure, and the associated infrastructure and application configurations. It also requires developing parallel management capabilities on those cloud providers. Even if a portable cloud-enabled application platform is used (for instance, Cloud Foundry), the customer must still configure, manage and operate that platform within the different environments. This simply shifts the nature of the infrastructure challenges, rather than eliminating them.

This may substantially increase the cost of developing and maintaining the application, and requires significant additional quality assurance (QA) testing. The complexity of testing such applications may have an impact on agile development, especially in CI/CD environments. The most severe impact may be on continuous delivery environments, where speed of change is especially prized.

Risks and Challenges of a Composite Multicloud Architecture

An application with a composite multicloud architecture must have solutions for the following challenges:

  • Networking. Each of the application components on different cloud providers needs to be able to communicate with other application components. In many cases, there will be a cost associated with all such communications. Network latency may contribute to application performance challenges. The network connectivity needs to be reliable and adequately performant, yet not be excessively expensive.
  • Data management. Some multicloud architectures require data to be replicated across multiple cloud providers, either synchronously or asynchronously. This also requires data integrity and consistency to be maintained across cloud providers. This increases architectural complexity as well as cost.
  • Security. All components of the application — and all communications between those components — need to be secure. However, there are likely to be components that cannot share a single security context, requiring a tool to unify security visibility across all the components. Identity, authentication and authorization are also likely to be handled differently by the different cloud providers used in the solution.
  • Regulatory compliance. Every cloud provider involved in the solution needs to meet the regulatory compliance requirements of the application. Data is likely to flow across multiple cloud providers, and the application architect needs to ensure that it does so in a compliant fashion.
  • Monitoring and tracing. Complex composite multicloud applications can be difficult to troubleshoot. The ability to trace application performance in real time across multiple cloud providers and application components is vital.
  • Availability. The use of multiple cloud providers increases the probability that, at any given point in time, at least one of these providers will be in the midst of an outage. Similarly, each of the integration points between these providers is a potential point of failure. The architect must ensure that the overall design is resilient.

Recommendations

EA&TI leaders play a vital role in directing an organization’s multicloud strategy and approach to multicloud management, and in guiding the use of multicloud architecture for specific applications. The following summarizes our recommendations for EA&TI leaders.

Multicloud Strategy Recommendations

EA&TI leaders responsible for multicloud strategy should:

  • Adopt a long-term multicloud strategy. To maximize your access to innovative capabilities and technology choices, plan to use more than one cloud provider for a given purpose. If you do not currently have plans to use more than one provider, ensure that your strategic cloud computing plan includes the possibility of additional providers in the future. For guidance on incorporating this into your overall cloud computing strategy, see “Designing a Cloud Strategy Document.”
  • Choose strategic cloud platform providers. Choose a primary strategic provider for broad capabilities — for instance, an integrated IaaS+PaaS provider (such as AWS or Azure) or a SaaS provider with an integrated PaaS (such as Salesforce with Force.com). You may have two or three providers that are centered on a particular set of broad use cases that are strategic to your organization. These providers should be the first choice for all of your cloud-based workloads.
  • Sign agreements with other cloud providers that you may use in the future. Do not feel pressured to be multicloud immediately. However, it is useful to sign agreements with the cloud providers that you expect your organization might want to use tactically in the next two years or that are of long-term strategic interest.
  • Consider running pilot projects on multiple cloud providers. If you are not already multicloud, you may benefit from running pilot projects in multiple different cloud providers to understand future multicloud management challenges.
  • Establish multicloud networking. Work with your network engineering organization to develop a strategy for multicloud networking — including securely connecting cloud providers to your enterprise network as well as securely connecting cloud providers to each other. Connections should be established to new cloud providers as needed.
  • Invest in integration capabilities. Work with your development and operations teams to develop skills for multicloud integration, especially integration between applications and data sources that live on different cloud providers.
  • Educate the finance and sourcing organizations. Finance and sourcing organizations often do not understand that cloud services are not commodities. They may attempt to pressure the business or the IT organization to buy what they perceive as the cheapest service because they do not understand that these services are not equivalent. Ensure that finance and sourcing leaders understand that a key value of cloud providers is their pace of innovation and differentiation. They must also understand that attempting to treat them like commodities is likely to lead to frustration and a loss of business value, while potentially yielding no cost savings or even increasing costs.
  • Treat vendor “lock-in” as an application portability problem. Applications are unlikely to move between cloud providers. Long-term strategic applications may need greater portability, since cloud capabilities will change dramatically over the decade or more that such applications may be in use. However, short-term tactical applications do not usually benefit sufficiently from cloud portability to warrant the extended development time and cost. OS containers such as Docker, container orchestration technologies such as Kubernetes and PaaS frameworks such as Cloud Foundry may simplify some aspects of portability, but do not expect them to significantly reduce portability challenges.
  • Provide guidance to developers for choosing cloud providers. The organization should have a cloud computing policy — created by a cross-functional team that is led by the organization’s chief cloud architect — that specifies what applications (and application components) can be placed with particular cloud providers. In addition, there should be a guidance document that recommends appropriate cloud providers for particular uses. In general, this guidance will be aligned to application type, application design, the application stack and integration dependencies. Application architects should decide what cloud providers are used to deliver each application.

Multicloud Management Recommendations

EA&TI leaders working within a cloud center of excellence should lead the adoption of the following multicloud management approach:

  • Extend management best practices from your single-cloud management. Once you have developed good cloud-native management practices in your primary cloud provider, extend those practices to multicloud management. It is useful to plan for multicloud management from the beginning. However, this should be secondary to ensuring excellent management of your primary cloud provider, especially if 80% or more of your workloads are in a single provider.
  • Use a common governance framework for multicloud management. Adopt a set of guiding principles and a unified governance approach when you need to do multicloud management. Select multicloud management tools to support this governance approach where possible. However, do not feel obliged to use the same tools for each cloud provider if a nonmulticloud tool can provide additional necessary functionality.
  • Manage strategic cloud platform providers using native capabilities. If you select a market-leading cloud platform provider, there should be a set of well-documented best practices as well as a strong ecosystem of tools surrounding that provider. Strongly consider adopting the cloud provider’s native management tools, since they are preintegrated with the platform and typically keep pace with the platform’s capabilities. Supplement these tools with third-party tools when those tools can provide better functionality or when multicloud capabilities are desired. However, third-party tools should overlay native capabilities (i.e., calling the native APIs) rather than reimplementing those capabilities, unless the reimplementation provides significantly greater functionality.
  • Take a developer-centric, application life cycle view of tools. For new applications, or applications that are under active development, developers are critical stakeholders for tools. Organizations vary in the degree to which they allow developers to choose the tools that are used across the application life cycle. Most organizations will benefit from using similar tools across teams that perform similar work. Cloud providers simply represent another integration point for those tools. However, some tools and application stacks may be highly aligned to a specific cloud provider. For instance, Microsoft-centric teams building .NET applications with Microsoft middleware, using Visual Studio with Visual Studio Team Services, will have tight integrations to Azure. In such cases, it makes more sense for such teams to use cloud-provider-specific developer tools.
  • Debunk the myth of the “single pane of glass.” Infrastructure and operations (I&O) leaders may be attracted to the notion of a “single pane of glass” to manage everything, and vendors may heavily promote products that they claim will fulfill this desire. However, not only is this capability mythical, it is generally also undesirable, especially if the vendor claims that this approach works equally well for on-premises environments as it does for cloud environments. EA&TI leaders must educate I&O leaders on the futility of attempting to take this approach. Rather, evaluate the possibility of unified management on a per-function basis. For instance, many organizations are able to implement multicloud CSEM using a single tool.

Multicloud Architecture Recommendations

EA&TI leaders involved in multicloud application architecture should:

  • Balance the complexity challenges of multicloud architecture with the benefits. When a multicloud architecture is being contemplated, the benefits and drawbacks should be clearly laid out. Such architectures introduce complexity during development and operations, and all stakeholders must understand and be prepared to address this complexity.
  • Consider multicloud placement for portable one-time workloads. One-time workloads (jobs) can potentially be good candidates for multicloud placement. They generally need to be associated with data that will be used just for one particular run of the job. Alternatively, they may be associated with large datasets that do not change and can be economically hosted on multiple cloud providers. If the workloads are potentially interruptible, you may be able to save money by combining on-demand compute instances with pre-emptible instances, on cloud providers that support these options. This requires the jobs to be written in a portable fashion and benefits from multicloud placement software that can determine the optimal cloud provider at the time and orchestrate the deployment.
  • Use external API services or supplementary services for unique capabilities. A necessary capability might be missing from the solution portfolio of the cloud provider that is being used to host the bulk of the application. The missing capability can be built by developers, obtained via third-party software or obtained through some other cloud service provider. Balance integration complexity against the convenience of obtaining a capability as a service.
  • Meticulously plan the life cycle of applications with multicloud core components. Applications whose core components are distributed across multiple cloud providers require exceptionally careful planning for each stage of the application life cycle. All stakeholders need to be involved in this planning, and integration challenges should be addressed from the beginning.
Source: Gartner Research Note G00357437, Lydia Leong, 16 August 2018

Evidence

Gartner analysts have discussed multicloud computing with thousands of clients during 2017 and 2018.