1. The business perspective:
Companies consider adopting a multicloud strategy for various reasons. It could be driven by specific customer requirements, the need for risk diversification, or expansion into new markets. In some cases, customers may demand their solution to run on a specific cloud platform, often due to compliance considerations. If the financial resources are available to accommodate such requests, a company can implement a multicloud strategy.
Unfortunately, the technical implications of multicloud are often overlooked. It's not something that can be done quickly, especially for modern architecture. There is a significant technical aspect that needs to be considered.
The most common multicloud scenario is when a Software-as-a-Service (SaaS) provider wants to host its solution across different clouds, or an enterprise that wants to distribute its resources across multiple clouds. Ultimately, the use cases overlap to a large extent. However, this means that you need to manage cost control, monitoring, and security, and stay informed about new features, changes, and deprecations for both cloud platforms. Although it doesn't necessarily mean that your IT department needs to expand immediately when the number of public clouds increases, it does require more effort and management to mitigate risks.
So while a multicloud approach may seem promising from a business perspective, the technical implications are often overlooked. Choosing multicloud can impose limitations on the variety of technologies you can use.
2. The technological perspective:
When considering the major clouds (Azure, AWS, and GCP), it becomes evident that multicloud not only involves different hosting providers but also different technology stacks. And although each cloud may have its virtual machines, the similarities between the clouds ends there.
When utilizing a public cloud, ideally, you would adopt its specific features to achieve the best efficiency, scalability, and security. The days of 'lift and shift' from a local hosting provider to a public cloud are long gone. While such migrations still occur, not everyone is rushing to host their workloads in the cloud to that extent. Therefore, we optimize our software architecture for the specific cloud in which we are hosting. For example, we may invest in adjustments to our solution to utilize Azure Key Vault or modify our code to integrate with Azure Storage Accounts using Blob Storage SDKs.
If our solution currently runs on Microsoft Azure and communicates with storage accounts, it becomes problematic when we host the solution on AWS. S3 buckets and Azure Storage accounts are different technologies. From a software perspective, this means we need to support different storage types within our solution. This can be achieved through code by ensuring that the solution identifies the cloud it is running on and uses the appropriate storage connector. Alternatively, maintaining multiple codebases is possible, but let's be honest, nobody really wants that.
For Platform-as-a-Service (PaaS) solutions, multicloud can indeed pose significant challenges. You are limited in the technology you can deploy specifically for multicloud, and it requires considerable development time and attention.
3. The overall perspective: Multicloud? It depends
Up to now a we stressed some challenges for multicloud. However, what about containers and Kubernetes? If you run your solution in containers and utilize platforms like Kubernetes, the idea of multicloud suddenly becomes more feasible. Each major public cloud typically offers its own implementation of Kubernetes, often as a 'managed offering'. This means that the public cloud takes care of running the control plane while you focus on other operations and development tasks.
With solutions like Azure Kubernetes Service, it's even possible to integrate native Azure offerings like Azure Key Vault or Azure Active Directory. This means that even with Kubernetes, you already have a cloud-specific configuration. The challenge lies in minimizing configuration drift between clouds. From an operations perspective, it's ideal to focus on GitOps solutions like Flux (Flux Documentation | Flux (fluxcd.io)) or ArgoCD (Argo CD | Argo (argoproj.github.io)). From a development perspective, solutions like Dapr (Dapr - Distributed Application Runtime) can be employed, offering a middleware layer to make your application cloud-agnostic.
The examples mentioned above are just a few possibilities. From a technological standpoint, multicloud is certainly possible, but it requires careful consideration and, more importantly, close collaboration between development and operations teams.
Wrap up:
Wrapping up, we can safely say that multicloud is no longer just a buzzword; companies are increasingly embracing it as strategy. What we have learned is that a multicloud strategy is entirely feasible, but it does require a careful consideration on both levels, busines and technical. With a great alignment between the business and technology risks are mitigated, and both the application / software and the business model are prepared to run on multiple clouds. Leaving you with the best of both worlds. Or should we say clouds? ;)