What are you talking about when you talk about multi-cloud?[3 x definitions]
Even if you're not yet operating in multiple clouds simultaneously, the shift is inevitably ahead of you. What does the term "multi-cloud" mean? There are at least three correct answers.
Get on board or be left behind, because the fact is that multi-cloud environments have become part of the transformation of work practices. Just as monoliths were replaced by microservices and functions, or waterfall projects gave way to agile methodologies and DevOps cultures, we now see that single-cloud strategies may no longer be sufficient.
Multi-cloud, multicloud, or monipilvi: how do you define the term? In everyday conversations, I quickly notice how the word means different things to different people. Next, I'll go through three different multi-cloud strategies. These examples describe situations in a public cloud scenario, so private "clouds" won't be mixed in this time. If you're interested in a more in-depth look at good multi-cloud practices, download... whitepaper multi-cloud -haasteiden taklaamisesta.
Three multi-cloud strategies
There are at least three different definitions of what the term "multi-cloud" means. Choose the one that fits the situation best and make sure you're on the same page with your conversation partner.
1) Workloads on different cloud platforms
Multi-cloud means running workloads on different cloud platforms so that they move seamlessly from one cloud to another, for example, based on price or available resources. In other words, the systems utilize two or more clouds as their runtime environment. This kind of environment can be implemented using container platforms, for instance.
The idea of continuously shifting capacity from one platform to another originated in the early days of the cloud. That’s why, today, the idea is as valid as if you were to look up spaceship construction instructions in an old sci-fi movie.
There were no rapidly updating cloud exchanges, and the cloud didn’t turn out to be just a virtual version of on-premises servers. Instead, we got cloud service providers who compete on more than just price: we got component libraries, transaction-based solutions, and entirely new features for building serverless applications.
However, the scenario of movable resources still surprisingly persists in many people’s minds. In reality, cost challenges are not solved by quickly shifting applications back and forth between different platforms. The price differences are minimal, and the architectural differences are significant.
On the other hand, leveraging container technology is very much in line with today’s needs. In container architectures, a platform is built for the application, and the services on it can be moved from one cloud to another. You might not want to tie the entire system to the native capabilities of a specific cloud, or the requirements imposed on your organization might dictate that the system must not be locked into a single platform but must remain portable. Even then, the intention is not to constantly move it but to ensure readiness for such a move. One could critically argue that this first option isn’t “true” multi-cloud work, but rather risk mitigation. In this model, you also lose the advantages brought by the native features of the cloud.
2) Parts of the system in different clouds
Multi-cloud means that different parts of a system are run in different clouds. For example, the AI interface might be in one cloud, while the database services run in another. In this case, the system can have various loosely coupled components across different cloud platforms.
The system is initially built on a specific public cloud. Over time, it’s noticed that a competing cloud has excellent capabilities and ready-made components for handling a particular type of data. Could these features be utilized without completely redoing the system’s foundation?
It’s possible: one system can leverage multiple clouds, either through ready-made services or APIs.
This approach takes advantage of the “loosely coupled” principle, where different parts can operate independently but also together, providing flexibility and scalability.
This scenario is prone to errors. The risk factor increases when the system’s functionality depends on the continuous and seamless operation of services from two or three different cloud providers. In this context, using loosely coupled components can reduce dependencies and thus lower risks.
It’s a different situation if the system aggregates its data from several different systems. Different data sets might be located in three or four different clouds. Is it still a true multi-cloud system in this case? Opinions may vary. It’s about integrations. And if one integration is temporarily down and a certain type of data flow is interrupted for a moment, the application itself continues to function nonetheless.
3) Different systems in different clouds
Multi-cloud means that we utilize multiple clouds as the runtime environment for our various systems, depending on their specific needs. For instance, a company might have a customer service system running on AWS and a BI system operating on Azure. Individual systems are always within one cloud, but different systems of the company are in different clouds.
It is quite common for a company to have different applications and systems running in different clouds. This situation can be described as the most typical multi-cloud strategy.
The advantage is that the organization can leverage the best features of each cloud. For a specific use case, the option that is truly the best in terms of features can be chosen (or developed), meaning that the choice does not have to be cloud-platform-centric.
Some systems may operate entirely separately. However, it is now common to build integrations between systems, for example, if there is a need to transfer data from a customer service system running on AWS to a Business Intelligence application operating on Azure.
This multi-cloud strategy also comes with challenges, whether the systems are separate or interconnected. The problem is administrative. Costs need to be measured, landing zones need to be set up, and security must be ensured – all across multiple clouds simultaneously.
Okay, moving towards multi-cloud, but what should we do with this information?
Applications and their complexities are increasing. Your digital department might swear by AWS-based solutions while the production side relies on Azure applications. Multi-cloud environments subtly creep into the picture, even if they’re not specifically targeted. Too often, the problem is “solved” within the company simply by closing one’s eyes.
Data might flow so poorly that the internal IT department doesn’t even know what solutions have been implemented in different business units. Cloud governance practices are often disjointed, and even if they’re not completely inadequate, a lot of redundant work has been done.
A centralized cloud management model and creating an overarching view are definitely among the most crucial solutions to the challenges of multi-cloud governance. A good multi-cloud management model considers risks and requirements but isn’t too cumbersome or restrictive. It helps you get more out of your multi-cloud environments.
How do you start building this model? Next, download the whitepaper that provides concrete tools for adhering to best practices in multi-cloud governance.
Updated 2024
