How to Simplify Your Hybrid Multicloud Strategy

THE COMPLEXITIES OF MULTICLOUD

As the following Forrester report (Assess The Pain-Gain Tradeoff of Multicloud Strategies) shows, the world of hybrid multicloud is a complex business. Sure, with a hybrid multicloud platform you get the data security and uptime reliability of on-premises architecture combined with the agility and on- demand growth of the cloud, but that combination comes in many different forms.

First of all, “multicloud” can mean various things to various people, including:

• Multiple clouds hosting different apps based on app characteristics.
• Multiple clouds hosting parts of an app ecosystem
• Multiple deployment options, with common APIs, on the same cloud
• Multiple clouds being used simultaneously for a single app.

Furthermore, a multicloud strategy appeals to different organizations and stakeholders for unique reasons, ranging from improved performance and disaster recovery through to the unique strengths of outside platforms and the desire to diversify risk.

For organizations looking to grow their infrastructure, it may seem that a hybrid multicloud environment is the most obvious cloud strategy. However, this isn’t always the case. Sometimes—as when you become faced with problematic latency and bandwidth, or double the work for half the productivity—a hybrid multicloud approach just isn’t feasible.

That’s why when you over-complicate your hybrid multicloud strategy you risk increasing your costs while still getting unimpressive results.

SIMPLIFYING YOUR STRATEGY

The best approach to establishing a simplified multicloud strategy, as Forrester explains, is to drill down into your needs: “Get specific about your multicloud plan and goals before jumping into decisions about public or private cloud and complex sourcing algorithms for determining the fate of your application portfolio. What greater purpose does your cloud strategy serve? What specific efficiencies — process and resource utilization — do you seek for your company, and why are those important?”

The following suggestions can help you ensure that your strategy is actually strategic, and not just ineffectively complex:

1. Make sure that you’re getting more out of your hybrid multicloud than you’re putting into it, meaning that the effort you’re expending doesn’t exceed the value of the end result.
2. Don’t overly complicate your cloud strategy. The easiest, most simplified approach is often the best one.
3. Avoid altering too much at one time unless you’re at a point of significant change in your organization, allowing you to make more radical adjustments all at once.

By focusing on simplification, you can find the right hybrid multicloud solution for your organization and assure that you’re getting way more “gain” and far less pain.

The Pain Is Usually Worth The Gain (But Not Always)

Hybrid cloud and/or multicloud is your obvious cloud strategy — or is it? Forrester outlined the basics of hybrid and multicloud in our report “Top 10 Facts Every Tech Leader Should Know About Hybrid Cloud.” But a larger story is emerging that questions the very nature of using multiple platforms — cloud or noncloud. Factors favoring variety are freedom of choice, heightened resiliency, and application-specific sourcing optimization. In opposition is the inefficiency associated with managing multiple versions, adding complexity and redundancy as enterprises veer toward cloud strategy pragmatism. As enterprises question the very nature of multiple platforms, they come to obvious conclusions:

• At times, vendor variety is worth it. Multicloud is popular for good reason. Different platforms have different strengths. By leveraging multiple cloud platforms, organizations see freedom of choice and application-specific sourcing optimization. This can meet a variety of app or end user demands, whereas forcing all workloads to fit on a single platform can be detrimental to regulation, cost, performance, or user experience. Secondarily, using multiple platforms reinforces the concept of heightened resiliency by not putting all one’s eggs in a single basket.
• On the other hand, strategic partnership creates great value. Some companies believe that maintaining multiple platforms can be expensive, whether for a portfolio of workloads or, even more, for a single application, and thus decide to focus on a single strategic partnership.1 The streamlined productivity, unified native management tooling, single data location, reduced redundancy, and ability to leverage unique and maintained services outweigh the benefits of added freedom.2 Strategic partnership can also reduce the risk that too much complexity can introduce.

KEY DRIVERS FOR MULTICLOUD

When Forrester asked North American and European infrastructure technology decision makers employed at enterprises why they leverage multiple cloud platforms, the three most common responses embraced the concept of strategic rightsourcing: to improve performance of latency-sensitive apps (31%); because different apps require different cloud services (28%); and for disaster recovery (26%).3 Most cloud-savvy companies are familiar with these efficiency principles. However, via inquiries and briefings, Forrester has uncovered other common reasons that enterprises turn to multicloud:

• Unique strengths outside a primary provider. Some enterprises reluctantly leverage clouds outside their primary cloud platform due to unique value-adds that they can’t find on their primary platforms. Examples include adtech and video streaming companies drawn to bare metal services, or favorable pricing for high I/O configurations while leveraging a megacloud provider for workloads without these characteristics.
• Compelling discounts. Microsoft has long used discounting on Office 365 and Skype as a way of incentivizing the selection of Azure as a primary platform.4 Microsoft can clearly hold its own in the public cloud platform market — it’s a Leader in in “The Forrester WaveTM: Full-Stack Public Cloud Development Platforms, North America, Q2 2018” — but many enterprises note that its discounting program lured them to Azure and resulted in a multicloud strategy. These accounts were often early Amazon Web Services (AWS) users, heavily leveraging the platform for net-new development and ease of portal use. Such users have more recently moved some of their traditional enterprise applications to Microsoft Azure to use up the credit hours granted to them via negotiation.5 Google Cloud has been similarly leveraging Google Ads discounts as a way of drawing more enterprise workloads onto its platform.
• Users. In highly distributed IT environments, developers and business users often make their own sourcing decisions. In many situations, preference alone leads to a multicloud strategy. At times, a centralized group takes over some or all environments to provide more cohesion. Rarely do such multicloud strategies transform into a single cloud story. Initial selection may be the result of early testing or of the role of the individual doing the early testing. Factors could include fit to a particular use case, a specific cloud provider’s geographic presence, or word of mouth. Less distributed groups may select multiple clouds to satisfy the demands of users they serve and gain credibility across business groups for delivering the desired capabilities.
• Customers. The everyday B2C customer doesn’t care much about where you host your website or free software-as-a-service (SaaS) product. But B2B companies serving other businesses through digital platforms or a SaaS solution find that sourcing can make or break a deal. Not only is initial selection important, but in some cases, hosting that same workload on multiple clouds is critical (e.g., simultaneous multicloud). Customer opinion in these situations can be a result of: 1) industry stances, such as mortar and brick retailers avoiding AWS, given Amazon’s dominance in eCommerce, or 2) proximity to their primary platform to minimize latency and egress costs to their other apps.7
• Partners that pick for you. Just as B2B clients enforce their choices, powerful partners may insist that you connect and work with them in a specific cloud platform that may differ from your primary cloud platform. The most cost-effective solution in this case is typically branching out into the preferred platform rather than switching primary providers — creating a multicloud scenario regardless of original intent.
• Diversification of risk (in theory). Regulators and internal auditors push for single-vendor risk mitigation in the event of cost escalation or complete failure. The fear typically isn’t about a short- term outage but rather a massive pivot that puts a provider out of business or drastically changes its prices. Financial regulators have started to ask for this next-level redundancy, but the reality behind the ask seems to miss the mark. These “doomsday” scenarios are fear mongering at its worst, given that there are no examples of cloud providers increasing pricing and that the major providers are arguably more financially stable than the financial institutions themselves.8
• Strengthening the power of negotiation (also in theory). Overconfident enterprises believe that having presence and experience on two platforms makes them more powerful in contract negotiation. Unfortunately, most enterprises don’t spend enough on a given platform to unveil favorable discounting. Splitting between multiple platforms further decreases their spend size.And to truly claim portability, you’d need to build for it. This driver makes sense for very large cloud consumers but is often not relevant for the average enterprise unless it’s considering heavily investing in a smaller player.

Get Clarity On The Types Of Multicloud

Before exploring the pains and remedies for various multicloud circumstances, first clarify the specific multicloud variations. At the most basic level, some scenarios leverage multiple platforms across a portfolio of workloads, and others do so for a single application or app ecosystem. Most assume portfoliowide or a large subset of applications. Top scenarios include

• Multiple clouds hosting different apps based on app characteristics. This model involves leveraging multiple cloud platforms for parts of your application portfolio due to different strengths in each platform or preferences of your developer or business users. Sourcing is decided on an app-by-app basis, looking at the organization’s users or characteristics as they map to the various services available. To speed up the process, enterprises create rules regarding characteristics of an application that make one choice suitable over another.
• Multiple clouds hosting parts of an app ecosystem (hybrid app architecture). Some applications or app ecosystems are designed to leverage multiple platforms — both cloud and noncloud. This is often due to availability of a service from a specific cloud provider, to avoid cost escalation, to meet required regulation, or to satisfy preferences of those accessing the workloads. This can be architecturally challenging. Common examples include customer- or partner-facing websites with elements subject to regulation, or heavily opinionated customers with deep pockets, edge scenarios, and medical research. Although a hybrid architecture may help mitigate latency where it matters, e.g., local decisions for the edge, internet-of-things (IoT) devices, or the shopping experience on a retail website, it isn’t easy designing a network architecture that considers cost and acceptable latency for each connected element in the ecosystem.
• One cloud, multiple deployment options, and similar operations using common APIs. For some, multicloud doesn’t mean multicloud platforms of vendors but multiple deployment environments with the same APIs. The ability to choose where the environment lives is a bigger concern than vendor flexibility. Today, Azure paired with Azure Stack tells this story, and to a more limited extent, so does VMware Cloud Foundation paired with VMware on AWS.9
• Multiple clouds being used simultaneously for a single app. Simultaneous multicloud is multicloud in its most extreme form. It entails running the same application simultaneously on multiple cloud platforms. This requires building the application identically on two or more cloud platforms. Due to complexity and cost, it’s very uncommon. Consideration is often limited to independent software vendors (ISVs) delivering SaaS solutions to highly opinionated clients with deep pockets and inflexible public cloud vendor preferences. Regulators in the financial services industry are trying to push for this to mitigate risk of “complete business failure on part of a cloud provider” and to avoid overdependence on a cloud provider. Regulators may ultimately find that it has the opposite effect. But, in practice, you’ll find few examples.

SOME ORGANIZATIONS FOCUS THEIR MULTICLOUD STRATEGIES ON BUILDING FOR PORTABILITY

The options outlined above describe infrastructure decisions for hosting an application, but for some, multicloud isn’t about today but rather about choice later down the road; they want flexibility of vendor choice in the future. If the circumstances change, they learn more about the platform, or the platformcapabilities improve radically, will they have the portability to move their applications to other cloud platforms? This simple question has widespread implications. Cloud platforms aren’t the same, and portability between them will always require significant work.10 Use of application or developer services unique to the provider makes it even harder to move. Enterprises face a big decision about whether the loss of value and speed to market is worth this portability. Even those that choose portability identify areas for exceptions where they’re willing to accept vendor or platform lock-in, all in the name of value and speed. Those that choose portability use these approaches:

• Leverage Kubernetes (K8s) for abstraction. Developer platforms, like Cloud Foundry and OpenShift, segregate app and infrastructure layers, often through K8s, while discouraging the use of services specific to a cloud platform. It’s then up to your own consumption and vendor selection to ensure that this decoupling from the platform continues. Amazon, Google, Oracle, and Rackspace all have their own managed K8s flavors on their platforms, which provide ongoing management (e.g., day 2) support, but to remain unattached, you’ll need to continue to limit the use of easily accessible services unique to the platform.
• Leverage a management tool for abstraction. Through their portals and the use of proprietary template patterns, hybrid cloud management tools (e.g., Rightscale, Scalr, and VMware vRealize Suite), also decouple the app and infrastructure layers while discouraging the use of services specific to a cloud platform. This allows for changes in sourcing decisions later. Using other templates or orchestrating elsewhere requires discovery and conversion to gain full management control over those launched resources.
• Write for the “least common denominator” or “if-then” logic for each platform. Using an alternative approach to decoupling is ill advised. If you choose to take that path, you must limit yourself to solutions consistent between providers or plan logic for multiple platforms. Early attempts at multicloud did just this. Limiting to the basics enabled conversion tools to easily convert to an alternative offering. Building for each platform, with logic for each, translates to bulky, inefficient code that’s time-intensive to create and maintain.
• Seek vendor-neutral app and dev services (that don’t currently exist). There’s a belief that a market of third-party services will emerge to deliver consistent app and developer services on all the major cloud providers. The vision is giving value regardless of location, with a responsible party taking on the development, updates, and stack management. Cloud Foundry’s ecosystem approach showed early promise but little momentum. The market is anticipating the release of multicloud marketplaces, but it’s still just a concept.11
• Minimize the impact of the lock-in. Some enterprises willingly opt in on lock-in if they can minimize the required operational time through a managed version of an offering. Smart practitioners follow two simple rules: 1) Limit yourself to services that deliver a managed version of a technology that’s highly common elsewhere (e.g., Kubernetes or SQL) and 2) limit yourself to services that don’t impact the normal running of the application (e.g., DBaaS or monitoring).12 With these guidelines, they get the value they seek without a painful rework.

When Multicloud Isn’t The Answer

 

Being multicloud in some form is the obvious solution for most companies, but there are exceptions.13 When they evaluate the economics, logistics, or partner relationships, multicloud simply doesn’t make sense for some situations. Some fringe cases consider this on a macro level, disregarding the value of micro-level efficiencies of app-by-app sourcing. The US Department of Defense’s JEDI proposal is one such example.14 These companies intentionally limit platform types, accepting high levels of lock-in in the name of simplicity. For other companies, the micro-level efficiency is missing. When they look at the logistics and specifics of an app, app ecosystem, or relationship, multicloud escalates costs for them. When you believe your mutlicloud options are limited:

• Determine whether this is opinion or fact. Theory is great, but if the numbers don’t work out, it’s useless. Before diving too far into the decision about your multicloud or single-platform approach, do testing to determine if performance or resource investments play out favorably in that model.
• Define the scope of the limitation. Most limitations aren’t total. Does the decision apply to a single app hosting decision, on a team level, or to apps that connect to a certain data set? Or does it represent a corporate-wide need? Sometimes this is easy to discern; for example, when your .NET users want to use Azure and a separate team is already heavily using AWS and its many app and dev services. But at times, it’s harder to define, especially if there are cost, latency, or compliance implications to a multicloud approach.
• Push the limitations to see if you can overcome the barriers. Creativity and problem solving is key in the cloud era. If you’re experiencing a very real pain for the desired multicloud strategy, explore whether those are truly barriers or simply hurdles that require flexibility. Forrester has seen many “barriers” break away — steadfast capital expenditure budget preferences may dissolve; patient records might get nonidentifying codes; inspirational leaders may be able to turn around hard-headed, long-time employees; or bursting could happen, with extensive changes, at the right moment.

MULTICLOUD MAY NOT BE PLAUSIBLE

Creating two isolated cloud environments across two or more cloud platforms has few barriers other than the increased burden of more vendors and the requirement of more skills. But as these environments connect with a data set, an app, or an app ecosystem splitting across these platforms, challenges can arise. At times, these challenges make multicloud implausible:

• Painful networking charges. Each of the cloud providers has different ways of charging for networking usage. For example, AWS doesn’t charge to move data onto its cloud or inside an availability zone (AZ). However, any traffic that moves from inside an AZ to other AZs, regions, platforms, or public areas will incur a cost of $0.01 per gigabyte (on AWS). Many companies don’t realize the amount of traffic that moves between different tiers of an application and have been shocked that network costs are higher than any other part of the bill.
• Problematic latency and bandwidth. Application services and data are no longer separated by feet but possibly by thousands of miles. Communication times can grow by orders of magnitude and make application experiences painfully slow.15 In addition, 10, 40, and 100 GbE connections found in data centers don’t exist as readily outside of them. The bandwidth is throttled by competing traffic from other customers in the data center or across WAN connections. Network traffic can be held in buffers or slowed down to accommodate the limited bandwidth, which adds more latency to application communication.
• Different types of tools. The public cloud providers allow customers to use their own networking and security services within compute cloud platforms, but that comes with a cost. The cloud providers offer free versions in the hope that customers will choose a free version and weave it into the application, such as proprietary API calls. Writing code to leverage a particular cloud service will make it difficult to develop or move an application to a different public cloud platform.
• Double the work (or more) with half the productivity. Manufacturing in the airline industry strives toward a lean supply chain to streamline processes by eliminating waste and non-value-added activities such as vendor maintenance. Similarly, organizations setting up new instances on new platforms will repeat the same activities — such as IP address management, security profiles, and account management — for little added value through business continuity or redundancy.
• Cost-affordable disaster recovery. Enterprises may leverage multiple cloud data centers; availability zones; or, in theory, multiple cloud platforms to provide business continuity for all or a portion of their applications. In practice, achieving active-active, even in a single cloud provider’s availability zones or regions, is too expensive for most workloads, let alone creating versions and maintaining them on multiple cloud platforms. Although the theory allows a range of disaster recovery approaches, cost and time create real limitations that make a disaster recovery plan less tangible if it stretches across clouds.

Your Strategy Is Multicloud — Now What?

Knowing that their strategy will leverage multiple clouds doesn’t answer many questions for I&O professionals. Get specific about your multicloud plan and goals before jumping into decisions about public or private cloud and complex sourcing algorithms for determining the fate of your application portfolio. What greater purpose does your cloud strategy serve? What specific efficiencies — process and resource utilization — do you seek for your company, and why are those important? This report should help you decide which multicloud approach you’re targeting and which you deem too painful to implement. Here are some of the early questions you’ll be asking:

• Is the pain worth the gain? For most companies, a basic multicloud strategy is the clear answer — the value outweighs the cost without need for significant cost analysis. If you’re considering more involved multicloud strategies or a radical single-platform environment to serve all apps, you have some significant work ahead. Rarely is this an easy yes-or-no question. You’ll need due diligence to creatively overcome the barriers or cost escalators.
• Are we over-architecting our multicloud strategy? You may be overly complicating your cloud strategy, building in significant inefficiency without reason. There’s no problem with the most simplified approach to multicloud. Those contemplating a more complex multicloud strategy are doing so because they have no other choice. An executive, a regulation, latency, or customer demand is forcing their hand toward a harder version of multicloud. If that’s not your situation, go with the easiest path.
• Is this the moment for change? Too much change at once can spiral costs, and your business, out of control. However, there are moments when you should evaluate more radical change. These “change moments” typically occur when contracts end, massive refreshes are pending, new leadership enters an organization, or staffing radically changes. Change moments occur when it’s more tolerable to pivot direction due to compelling cost avoidance figures, higher appetite for change, or dire need. If your organization is planning to build a new data center, refresh a colocation contract, reduce tech organization staff size, hire cloud skill sets, replace C-level leadership, or undergo a massive infrastructure refresh, it’s worth evaluating a more radical approach. Determining whether this is your moment of change may determine whether you should consider a more involved multicloud or an even more radical idea — a single-platform strategy.