You might think "multi-cloud" and "hybrid cloud" mean the same thing, but they are, in fact, quite different stages in the evolution of cloud computing.
We live in a world where we like to name things. In cloud computing, the names revolve around patterns of use: public cloud, private cloud, and hybrid cloud. Now there's a new term, multicoloured, for an emerging way of service for cloud computing.
Terms and definitions
"Multicloud" means using more than a single public cloud. That usage pattern arose when enterprises tried to avoid dependence on a single public cloud provider, when they chose specific services from each public cloud to get the best of each or wanted both benefits.
Defined: "Multicloud" vs. "hybrid cloud."
So, how does multi-cloud relate to hybrid cloud? Some people use them interchangeably, but they do have distinct meanings. A hybrid cloud is pairing a private cloud (an on-premises data centre built on cloud technologies) and a public cloud.
If you use multiple public clouds with a private cloud, that is still a multi-cloud. (Some people might call it a hybrid multicloud, which is fine.)
"Pragmatic hybrid cloud" defined
There's also a beast called a pragmatic hybrid cloud, which is the pairing of a traditional enterprise datacenter with a public cloud; these exist because many enterprises have been disappointed with private clouds and so sought a way to combine them had with the public cloud.
By contrast, a multi-cloud architecture uses two or more public clouds.
What's behind the multi-cloud trend
As a trend, cloud computing is getting more complicated. The vision a few years ago was of placing workloads on a single cloud, whether public or private. But then the hybrid cloud architecture became a more attractive option because it gave enterprises more choice.
Because these are all viable public cloud options, enterprises began to mix them through formal architectural processes and through "shadow IT," where groups in companies that used a public cloud without enterprise IT knowledge. Various shadow IT efforts often picked different public clouds and then wanted those cloud operations to be managed by enterprise IT.
No matter how you got there, most enterprises now manage a multi-cloud infrastructure.
Although many IT organizations manage these complex multi-cloud environments using the native tools and services from each cloud, a few are getting smart and abstracting themselves away from the complexity.
Using tools such as cloud management platforms (CMPs) and cloud service brokers (CSBs), enterprises can manage multiple clouds as if they were a single cloud. However, the trade-off is that you can only use a subset of features from each cloud; that is, take the "least common denominator" approach.
Advice: Focus on what cloud technologies do, not what they are called
Public cloud, private cloud, hybrid cloud, pragmatic hybrid cloud, multicloud: semantic overload? Indeed.
However, I suggest that you not get caught up with what things are called but instead focus on what they do. It's a fact that cloud architectures will evolve in the new few years, and new patterns will emerge. New names will come, too, I'm sure.
Why you should care about multicloud
The use of cloud-based platforms in the technology industry continues to evolve into more complex arrangements. Why? The business world now demands a mix of many best-of-breed cloud services to form the optimal solution. The answer is proving to be a concept called "multicloud."
What is multicloud? It's more complicated than a hybrid cloud, which is typically a paired private and public cloud. Multicloud adds more shadows to the mix, perhaps two or more public IaaS providers, a private PaaS, on-demand management and security systems from public clouds, personal use-based accounting -- you get the idea.
This is where we've been headed in the last few years, creating solutions from an intricate set of best-of-breed private and public cloud computing services. This is much the same process as when we moved to elaborate distributed internal systems in the past: We integrated various technologies to form a business system that met our exact requirements. This is no different, but it uses cloud-based technologies.
Why should you care about all this? I wouldn't get down too much with the "multicloud" buzzword.
What's critical is the cloud computing architecture, which typically incorporates multiple public and private cloud providers. These days, the number of projects involving just one or two cloud computing providers or technologies are few and far between. It's more likely there are a half dozen involved.
In that multicloud reality, keep these core concepts in mind:
- Multiclouds require more thinking around security and governance, given their complexity and distribution.
- Multiclouds may develop resiliency issues, considering the number of moving parts.
- Multiclouds have value only if you select the right providers, whether on-demand or private, to meet your requirements.
It's essential that you take the lessons learned from building complex distributed systems to multicloud deployments. You need to understand that integration drives complexity, which must then be managed. There is no substitute for planning and architecture. As long as you take a disciplined view of multicloud, you'll do just fine.
Your multicloud strategy is all wrong
Multicloud seems like such a great idea. Unfortunately, it doesn't work. It would be OK if multicloud helped customers but vendors were hurt in the process, but the opposite is true: Vendors are cleaning up by selling multicloud snake oil. In contrast, customers keep getting stuck with lowest common denominator cloud strategies and sky-high expenses.
There's got to be a better way.
The multicloud dream
Much of what enterprises say about their multicloud strategies is complete and utter rubbish. The idea of buying into multiple clouds to pit them against each other for price negotiations is one of my favorites, because the result of buying into multiple clouds is various ways to lose track of cloud expenses. Not only that, but it's beyond bizarre to think that, hard as it is to master just one cloud, adding others somehow will result in less cost::
It is an indisputable fact that to be good at just one cloud, never mind many, you have to invest in trained and experienced people, evolved processes, and new tooling and technology. This can cost millions of dollars and months of experience. Some people never get good at one cloud, [therefore…]
1: You will have much higher overheads the more clouds you have
2: The more clouds you have, the more shallowly you will experience each cloud.
That "shallow" experience, in addition to increasing costs, will tend to diminish the very benefits enterprises seek in the cloud: agility and innovation. I've seen this up close when the decision to embrace a second cloud sent costs skyrocketing as we straddled two clouds with our workloads.
The workloads never worked as well on the second cloud as they had on the first, partly due to a lack of familiarity with the second cloud and somewhat because the second cloud lacked many of the features we needed. Worse, it became that much harder to achieve resilience and security when juggling workloads across clouds.
"But… but... but... vendor lock-in!" you say. Well, the idea of being vendor agnostic is just that: an idea, and one that doesn't work well in reality:
From a strategic direction perspective, it can make a great deal of sense to back multiple horses. "No vendor lock-in," they promise. The fallacy here is that if you don't back a horse, you will lose all vendor safety valves when you go beyond the "least common denominator" of cloud services: storage, network, compute. To some in the C Suite, we hear that this is a good thing! "We'll be vendor agnostic and move workloads between any cloud we choose." No. You. Won't. And if you try, you'll lose time, money, and, tragically, data….
The naysayer will say, "Oh, we're just gonna use containers for everything, and then we'll truly be agile and cloud agnostic." No. You. Won't. All cloud providers offer a common denominator of computing, storage, and networking—this we've discussed. But you cannot possibly take into account all of the nuances of each cloud's specific implementation of containerization technology or governance any more than you could have a shared storage endpoint for all clouds or a standard networking model for all clouds or a common... And if you try, kernel panics and failed PODs will happen. I've seen it, I've hugged the engineers that have been attempting it.
In short, the reasons enterprises often cite for going multicloud don't hold up when put into practice.
Partnering for success
As one cloud vendor told me, "If you want consistent management across clouds, you can't use any of the unique features of those clouds. As soon as you decide 'I'll use RDS or Cosmos DB,' then all of a sudden your application isn't portable to another cloud."
Forced to choose, my guess is most enterprises want the higher-order services from particular clouds more than they want that portability across clouds. The latter may appeal to accounting, but the former appeals to the teams tasked with driving agility and innovation within an enterprise. If you had to pick one of those teams to appease, pick the developers. Every. Single. Time.
However, siding with developers doesn't mean that an enterprise needs to cede its IT control to a vendor. Instead, by going deep with a vendor, not only does that enterprise put itself in a position to develop more expertise with that cloud, but it also sets itself up as a VIP with that cloud.
Anyone who has worked in enterprise software knows that while "all animals are created equal," following Animal Farm logic, "Some animals are more equal than others." Vendors always tend to listen to their most committed customers, and that "commitment" isn't merely a matter of money.
Like all enterprise IT vendors, the cloud vendors will tend to partner with those customers who help them push the envelope on innovation and publish success stories (case studies, conference keynotes, etc.).
As Martin writes, "Back a horse and become a partner to that provider, not merely a customer. Trust me, we're looking for a few good true partners to not only help you digitally transform but help us digitally transform with you."
This is the right way to think about agility, security, innovation, and cost in the cloud. Multicloud sounds nice, and it offers second-tier cloud vendors hope that they can serve some niche role within your cloud stack. Don't be fooled. Enterprises that spread themselves between multiple clouds will slow innovation and agility, not increase them while increasing costs and decreasing security. There's not much to love in that "strategy."
Two mistakes that will kill your multicoloured project
Multicloud should be easy, right? I mean, it's just deploying and managing more than a single public cloud. This has, unfortunately, not been the case. As more enterprises deploy multicloud architectures, some avoidable mistakes are happening over and over again. With a bit of understanding, perhaps you can avoid them. Let's review the top two:
Not designing and building your multicoloured with clouds in mind.
Many enterprises deploy two, three, or sometimes more public clouds without a clear understanding of how this multicloud architecture will be managed long term.
When a multicloud deployment moves to production, there's a significant number of cloud services caused by leveraging multiple public clouds with redundant services (such as storage and compute). It all becomes too much for the cloudops team to deal with. They can't operate all of these heterogeneous cloud services as well as they should, and the quality of service suffers. It also places way too much risk on the deployment in terms of security and governance operations.
There are a few ways to avoid this. First, don't do multicoloured if you're not willing to step up to the operational needs. Stick with single cloud deployments only. This takes all best-of-breed services off the table and reduces the value of using the cloud at all. The second, and the proper approach, is to automate everything and leverage abstractions (single pane of glass) to manage the complexity and still provide best-of-breed benefits
You are choosing "cloud-native" everything.
Keep in mind that tools that span the public clouds are the most useful. You can use the same interfaces and automation from one cloud to another in your multi-cloud.
This seems like the obvious choice, but many enterprises moving from single to multiclouds keep the native tools that came with a particular public cloud, such as security and operations tools. Companies that opt to stay specific management and monitoring tools for AWS, Microsoft, or Google will have to learn and leverage a tool per public cloud. Not very efficient.
Avoiding this problem is easy to understand but not so easy to pull off. Although cloud-native applications are acceptable, only using native tools for all sorts of management and security tasks is not a good idea. You'll need people who understand each device, there won't be intercloud communications and coordination, and automation will have to occur in multiple places instead of one. The solution is to look for tools that span clouds and provide consistent interfaces across clouds.
Multicloud is still an evolving science. Public cloud providers are not offering useful guidance and tools because it's not in their best interest to push their customers into multicloud. However, if they try to lead you to a design pattern that increases your complexity, costs, and risk, avoid that path.