Multi-cloud is top of mind for many technology leaders. What are the benefits? The challenges? And ultimately, is it a right fit for the business and its teams? There’s no consensus about multi-cloud—as evidenced in a recent Twitter thread I started. So, let’s break down why. I’ll share my view of multi-cloud and possible approaches to cloud strategy implementation without (yet) getting into how VMware speeds your cloud journey. Then, let’s hear about yours. There are lots to cover about strategy, so I’ll start with definitions.
What is Multi-Cloud?
One of the biggest challenges that surfaced in the discussion of multi-cloud is that we all have slightly different definitions of multi-cloud.
First, as a starting point, a commonly agreed-upon definition of hybrid cloud:
Hybrid cloud: consistent infrastructure and operations between on-premises virtualization infrastructure/private clouds and public cloud.
Hybrid cloud is about connecting on-premises environments and public cloud. The key distinguishing characteristic of a hybrid cloud is that the infrastructure (and thus operations) is consistent between on-prem and cloud. This means the same operational tools and skillsets can be used in both locations and that applications can easily be moved between locations as no modifications are needed.
Now to define multi-cloud:
Multi-cloud: running applications on more than one public cloud.
This definition could mean a single application/app that is stretched across clouds but more often means multiple apps on multiple clouds (but each app is contained entirely on a single cloud). It could mean that the underlying cloud is partially or completely abstracted away, or it could mean that the full set of cloud capabilities is available to the apps. Perhaps confusingly, multi-cloud can include on-premises clouds too! This is just a generalization of the “many apps in many locations” definition.
Multi-Cloud Approaches
Having apps running on multiple clouds presents challenges: How do you manage all these apps, given the vastly different tooling and operational specifics across clouds? How do you select which cloud to use for which apps? How do you move apps between clouds? How much of this do you want to expose to your developers?
There are a variety of approaches to multi-cloud that offer different trade-offs to the above problems. I see four primary approaches businesses are taking to multi-cloud:
- No Consistency: This is the default when a business goes multi-cloud. Each cloud has its own infrastructure, app services (e.g., database, messaging, and AI/ML services), and operational tools. There is little to no consistency between them and the business does nothing to try and drive consistency. Developers must build apps specifically for the cloud they’re using. Businesses will likely need separate operations teams and tooling for each cloud. But apps can take full advantage of all the cloud’s capabilities.
- Consistent Operations: The business aligns on consistent operations and tooling (e.g., governance, automation, deployment and lifecycle management, monitoring, backup) across all clouds, each with its unique infrastructure and app services. Developers still build apps to the specifics of the cloud and moving apps between clouds is still a large amount of work, but the business can standardize on an operational model and tooling across clouds. This can reduce the cost of supporting multiple clouds through consolidated operations teams with less tooling and increase app availability through common, well-tested, and mature operational practices.
- Consistent Infrastructure: The business leverages a consistent infrastructure abstraction layer on top of the cloud. Kubernetes is a common choice here, where businesses direct their developers to use clouds’ Kubernetes services. VMware Cloud is another option, as it’s the consistent VMware SDDC across all clouds. Common infrastructure standardizes many parts of the app, allowing greater portability across clouds while still leveraging the common operational model (which is now more powerful as the infrastructure has been made consistent!). Developers can still take advantage of each cloud’s app services though, which is where some cloud stickiness can creep in.
- Consistent Applications: The business directs its developers to use consistent infrastructure abstraction and non-cloud-based app services for their apps. This builds on Consistent Infrastructure by also specifying that any app services used must not come directly from the cloud provider. Instead, app services can be delivered by ISVs (e.g., MongoDB, Confluent Kafka) as Kubernetes operators or as a SaaS offering (e.g., MongoDB Atlas, Confluent Cloud). Apps are now easily portable across clouds and cloud selection is totally predicated on cost, security, compliance, performance, and other non-functional considerations.
It’s important to note that no approach is generally “better” than any of the others. Each approach comes with tradeoffs and it’s up to the business to decide which is best for it based on its unique needs and requirements. And in some cases, businesses may leverage more than one approach, with different apps or development teams taking different approaches.
Strategy or Inevitable Outcome?
The natural next question is whether you should go multi-cloud. In an ideal world, running all your apps on a single cloud is likely best for most businesses. You can standardize everything you’re doing to that one cloud, simplifying app implementation and operations. Apps can take advantage of all the specific innovative features of that cloud. You can negotiate higher discounts with the cloud provider because you have higher usage than you would if you spread your workloads over many different clouds.
The problem, though, is that it’s very hard to run all apps in only one cloud. Acquisitions may be using a different cloud. After the acquisition closes, the question is then whether to move all the apps onto a single cloud (likely using precious time and resources that could be invested in integrating that acquisition) or living with multi-cloud. Shadow IT is still happening in many businesses, where developers or lines of business make independent decisions to use another cloud technology, meaning you’ll likely end up in a multi-cloud situation even if you try to avoid it. Finally, even if you can deal with those problems, what if your preferred cloud isn’t innovating in a new area as fast as another cloud? It may be necessary for the business to start using that other cloud, putting you into a multi-cloud world.
The general takeaway is, try as hard as you might, being a single cloud likely won’t be the case for very long. Something will happen to make you go multi-cloud. Really, it’s just a question of whether it’s due to a proactive strategy or an inevitable outcome because of one or more of the above reasons. In either case, having a multi-cloud plan is a must!
Author: Kit Colbert, VP & CTO, Cloud Platform BU at VMware
Source: https://octo.vmware.com/multi-cloud-strategy-or-inevitable-outcome-or-both
FOR A FREE CONSULTATION, PLEASE CONTACT US.