First of all, one should distinguish between Multi-Cloud and Multicloud Native Service approaches.Multi-Cloud assumes multiple cloud providers, but sharing them is not necessarily intended to maximize the resiliency of your applications.
For example, due to price or other considerations, you can use the services of one provider to collect or store data and the services of a second provider to analyze it. Or, you can use one cloud for the main application and the others – exclusively for the backup storage of the database. In both cases, the application itself is not necessarily deployed to all available clouds. Accordingly, the ability to switch between clouds in the event of a failure is not always respected.
The Multicloud Native Service approach assumes that you design your product so that it follows the principles of Cloud Native and completely abstracts from the particular cloud provider. First of all, this is achieved by abandoning proprietary services, which we will discuss in more detail. This approach allows you to deploy your applications to multiple clouds of your choice simultaneously and easily migrate them from one cloud to another with no downtime.
You will be insured as much as possible against the risks that we talked about above: even a complete failure of one of the providers will not affect the availability of your system because the second provider will always be able to act as insurance.
Thus, if Multicloud is about the number of cloud providers, then Multi-Cloud Native Service is more about the applications themselves, compliance with all Cloud Native principles, and the ability to deploy on several independent sites. Multi-Cloud Native Service is often built based on Multi-Cloud, but this is not always the case. In this case, public clouds or hybrid infrastructures can act as platforms and options with the company’s data centers.
Options for building Multicloud Native Service architectures
There are two main ways to build architectures using the Multicloud Native Service approach:
1. Using multiple public providers
In this case, one leg of the infrastructure is built on one public provider and the second on the side of another provider. For example, you can combine a local provider operating in the Russian Federation (Mail.ru, Yandex, MTS, Rostelecom, and others) and a global provider operating all over the world (AWS, Google Cloud, Alibaba, Azure, and others), or use two local providers at the same time.
I know large companies that now use the services of a couple of Russian providers, thereby ensuring the maximum fault tolerance of their systems. However, in practice, a complete abandonment of its infrastructure favoring public providers is rarely used due to the high cost and customers’ distrust of the cloud.
Developers of start-up solutions most often turn to the services of cloud providers, while for medium and large businesses, the very decision to completely switch to the cloud is still difficult, especially when it comes to banking and other areas with increased security requirements. Therefore, more often, companies come to hybrid infrastructures.
Combination Of Private Infrastructure And Public Provider
This is a more common option in Russian realities when the client continues to use the traditional infrastructure on his side (it can be “bare metal”, virtualized environment, or even a private cloud) plus adds a public cloud provider to it. Most often, the resulting architecture is called a hybrid cloud (Hybrid), but if the software and infrastructure, in this case, implement all the principles of Cloud Native applications, then the system as a whole can be called Multicloud Native Service.
Regardless of which of the two schemes you apply in practice, in the end, you will get the most resilient architecture, protected from all types of risks discussed above. Even a complete loss of all the provider’s data centers will not stop the system as a whole since the second leg will continue to function.
Also Read: What Are The Security Risks Of Cloud Environmental
