The Forrester Guide To Hybrid Cloud

Hybrid Cloud Isn’t A Specific Strategy — It’s A Sanity Statement

Forrester 
Tracy Woo
with Lauren Nelson, Audrey Lynch, Diane Lynch
September 16, 2021
wire19

Summary

Hybrid cloud is an obvious strategy, and despite cloud migration interest, it’s here to stay. Cost of change and compliance are the two biggest proof points for hybrid’s continued relevance, but no single deployment model serves all use cases. This report serves as a primer on multicloud and hybrid cloud to help cloud leaders understand hybrid definition, current status, best practices, and how hybrid has advanced over the past few years.

Topics

• Hybrid Cloud Is The Obvious Strategy — And You Already Have One
• The Top 10 Facts Every Tech Leader Should Know About Hybrid Cloud
• Supplemental Material

Hybrid Cloud Is The Obvious Strategy — And You Already Have One

Forrester frequently fields questions from cloud leaders asking whether hybrid cloud will survive in the world of cloud migration. The answer is obvious: Yes, it will. Executing on new technology can be complex and costly. Completely switching from today’s current infrastructure reality to one based 100% on public cloud is so prohibitively expensive that the practice is almost nonexistent. Even General Electric (GE), exemplar of the cloud migration movement, has HIPAA-compliant apps on either OpenStack or VMware on-premises. The specific mix will vary by organization and evolve over time, but it’s hybrid, nonetheless. Hybrid cloud articulates a balance of leveraging existing investments while wrapping in new cloud technologies to bring powerful improvements. In 2020, 80% of North American and European enterprise infrastructure decision-makers defined their strategy as hybrid (see Figure 1). However:

• Hybrid cloud means very little. The National Institute of Standards and Technology’s (NIST’s) cloud definitions are the standard in all things as-a-service — except when it comes to hybrid cloud. NIST defines hybrid cloud as the ability to burst between two or more clouds for load-balancing data and applications. This vision has little relevancy in today’s cloud reality. Hybrid cloud, as the market defines it, is the use of cloud in parallel with other technologies — cloud or noncloud (see Figure 2). It’s cloud plus anything. More recently, it’s been used to note a mix of deployment models in use. This means that it describes every organization but with absolutely no specificity. Lastly, major public cloud providers have used this term to describe their “at customer” options like Amazon Web Services (AWS) Outposts and Microsoft Azure Stack.
• Multicloud isn’t any better. To break free from this definition and its vague variations, some organizations have replaced the term hybrid cloud with multicloud. Multicloud requires the use of multiple cloud technologies — specifically, multiple public clouds. The difference is minimal. Although the term is fresh, many use it interchangeably with hybrid cloud. Today, 39% of North American and European enterprise infrastructure decision-makers define hybrid cloud specifically as multicloud, either using multiple public and private clouds for different use cases (28%) or using multiple public clouds (11%) (see Figure 3). At times, this added nuance creates clarity, but it can also lead to confusion.
• Management gets tacked on to these same definitions. Facilitating this reality of hybrid and/or multicloud is complex. It can mean different API standards and cloud platform skills along with painful architectural decisions to mitigate performance-diminishing latency and unbearable egress charges. Cloud management solutions, both hybrid cloud and multicloud, seek to help govern these platforms, mitigate painful challenges, and navigate complex decisions. Hybrid cloud management platforms serve environments that span deployment models across public, private, and even edge environments. They tend to include “build” capabilities and list at a price to match their significant depth in capabilities. Multicloud management solutions focus on management across multiple public cloud platforms in lightweight modules, often at lower price points.

Figure 1North American/European Enterprise Decision-Makers See Their Cloud Strategies As Hybrid

Figure 2Defining Hybrid Cloud Versus Multicloud

Figure 3Hybrid Cloud Definitions Vary

The Top 10 Facts Every Tech Leader Should Know About Hybrid Cloud

Being an expert in hybrid cloud requires massive breadth and depth in knowledge. Experts understand the various roles they must fill, processes they must use, and technology they must leverage across the full spectrum of as-a-service and supporting technologies. This includes cloud apps, cloud application and developer services, cloud platforms, cloud management tools, and solutions that help connect their solutions of choice. As your enterprise starts to build its hybrid cloud strategies, be aware of these 10 key principles.

1. Hybrid-by-accident is common. Cloud strategies are often a compilation of the best tools available at the time of selection. Companies undergo digital transformation because they realize that stagnant businesses can’t survive. Subsequently, these organizations have jumped into this rapidly moving space to serve a variety of use cases, teams, and developer types. This world is hybrid. However, it’s not a carefully selected hybrid reality but rather an accidental hodgepodge of technologies. Although this is chaotic at times, it preserves productivity above all else, often sacrificing compliance and governance in the name of innovation. This is by no means ideal, but it’s a starting point.
2. Hybrid-by-design has also fallen short of expectations. The alternative to hybrid-by-accident is hybrid-by-design — an approach that follows the “get out in front of cloud usage” mantra. The cloud management team picks the tools to serve multiple teams and use cases. Decisions consider ease of integrations, ability to leverage existing systems, and total required budget. Although the goal is to uphold productivity, governance, and compliance, in practice, productivity suffers. This can kill momentum and raises the question of the value of operations in cloud strategies altogether. For this reason, some organizations start out with open gates, allowing developers to utilize cloud technologies easily and eventually pivot to a more strategic model that positions specific usage patterns or rules of usage.
3. New application brokerage differs from strategic rightsourcing efforts. Both old and new workloads require sourcing, but the urgency differs. Developers and business groups want a fast decision about what new solution serves their needs. Application rationalization and rightsourcing efforts tend to be less urgent. Follow a systematic approach to determine anticipated life and value of the workload, ideal hosting solution, and the timeline for moving to the preferred location. Business leaders rarely care about application rationalization unless it means retiring an app, replacing an app, or substantially changing performance of an application. Place less effort on your own marketing bandwidth for this effort, instead emphasizing those that affect acquiring new capabilities. Treat these as separate efforts, and expect ambivalence when it comes to infrastructure-as-a-service (IaaS) cloud migration.
4. Hybrid applications are common. Apps are hybrid, too. Some apps include multiple coding languages as well as multiple platform/service heritages, locations, and hosting environments. Hybrid applications are often intergenerational or cross-team, where productivity or functional advantages outweigh the technical difficulty of added technologies. From a cloud hosting perspective, hybrid applications come in several forms: 1) an app split across multiple platforms within a single data center; 2) a legacy application composed of traditional code and surrounded by native cloud application services; or 3) an app split across multiple data centers. The last requires due diligence for workloads sensitive to latency. In the era of cloud migration, hybrid apps are becoming increasingly common.
5. Bursting is here, sort of. Cloud bursting may be the single most overhyped topic from the early cloud days. It describes an enhanced portability between private cloud and public cloud environments, based on changing workload circumstances. Facilitating bursting is hard, complicated by latency between sites, cost of data movement, and lack of consistency between public and private cloud environments. Bursting is by no means the definition of — or a requirement of — hybrid or multicloud. However, it seems that some enterprises are just starting to explore this possibility. Adobe shared its bursting story at an OpenStack event in November 2017. Many vendors, including Avere and Google, are beginning to target these use cases. The “bursting” that’s more common today is simply the use of cloud services to scale up in response to increased demand. These scenarios are a compilation of cloud migration, software-as-a-service (SaaS) adoption, and autoscaling of on-demand instances. During the pandemic, there has been no shortage of these scenarios to facilitate increased e-commerce demand or remote work/learning. However, these scenarios aren’t split across deployment models, nor are they doing this in real time.
6. Multicloud can mitigate vendor lock-in, but be wary of the trade-offs. Every technology leader knows the harsh reality of vendor lock-in. Today, the fear focuses on megacloud providers. Basic cloud services are each unique but can easily convert in the event of migration. Where megacloud providers are stickiest is in their application and developer services. Forrester encounters two major approaches to avoid vendor lock-in: 1) building alternative skills, services, and templates in several cloud environments and 2) banning the use of application or developer services. The first can slow early cloud strategies and bloat spend, and the second denies useful tools to developers. Today, cloud leaders early in their journey focus on success and skills on a single platform, whereas more mature cloud strategies look at minimizing supplier risk vulnerabilities by building out skills and solutions on multiple platforms rather than trying to intentionally avoid app and dev services.
7. Common API targets portability. “Common API” refers to consistent APIs between a public cloud and a private cloud environment. In 2017, Microsoft launched Azure Stack, the first common API offering. It promised to deliver all public Azure app and developer services to Azure Stack. This allows a workload to move freely between public and private deployment models, based on app characteristics in the application lifecycle. However, this approach doesn’t address vendor lock-in. Several others in the market claim common API, including Alibaba, AWS Outposts, IBM Cloud Satellite, and Oracle at Customer. Today, 21% of North American/European enterprise infrastructure decision-makers believe that API-consistent public and private clouds best describe hybrid cloud in their organization.
8. “Invisible clouds” is the goal for some. For some tech leaders, the goal is to guardrail cloud usage by providing tools that abstract away from the clouds they’re using. For some developers, this places the focus on code rather than worrying about the “where,” the cloud platform APIs, or even what they’re provisioning. However, developers often feel frustrated at the poorly designed UIs that slow their productivity rather than enhance their experience. The major single-pane-of-glass attempts to abstract away from the underlying cloud platforms are hybrid cloud managers (HCMs), multicloud container development platforms, and low-code platforms. The first focuses on the operator experience, whereas the final two focus on developer productivity from the perspective of the developer. Furthermore, abstraction often has two side effects: 1) opinionated solutions to problems and 2) limited support of application and developer services. Each has implications on productivity for various teams. The right solution will vary by group, use case, and company.
9. “Invisible management” is the alternative model. Some developers are less productive when their preferred clouds are invisible. These developers are more productive with direct access to specific application and developer services, i.e., direct access to public cloud platforms. Rather than having management get in front of the development process, these services enable access to the developer experiences and clouds that developers want. Developers can insert cloud knowledge, best practices, and governance rules directly into the native-cloud API experience via agents or review them retroactively to correct violations. This approach treats the cloud provider as the standard and places a high value on being current with the latest services available.
10. Coordinating across systems isn’t simple. Developers have a long list of tools they want to use. Enterprises struggle with piecing together the preferred tools in a meaningful and sustainable way. Hybrid cloud managers strive to do this from a cloud platform perspective to unify the metrics and alerts. However, they lose many of the services and unique features of each cloud in this abstraction. Multicloud container platforms (e.g., Google Anthos, Red Hat OpenShift, or VMware Tanzu) and integrated software delivery platforms (e.g., CloudBees, Digital.ai, GitLab, or HCL Urbancode) attempt to do this across the development lifecycle and coordinate among stakeholders. Similarly, various open source service mesh approaches attempt to solve data-sharing between systems. Other enterprises try to standardize their infrastructure automation (e.g., Ansible, Chef, or Puppet) or templating (e.g., Hashicorp Terraform) across their systems.

Supplemental Material

Research Methodologies

This is an update of a previously published report; Forrester reviews and revises it periodically for continued relevance and accuracy.

Originally published at