Challenges of moving to a multi-cloud strategy
Hybrid or multi-cloud strategies are used by businesses for a variety of reasons from legal to cost saving, and application agility. Often businesses want the flexibility to take advantage of best prices or capabilities from differing public cloud vendors. Avoiding vendor lock-in is another reason a business will desire a multi-cloud strategy.
While a business may not want to be tied to any one cloud provider indefinitely, moving to a multi-cloud strategy is not right for everyone. In fact, the risk of being tied to one cloud provider is not necessarily the risk it’s often perceived to be.
This article sheds light on why moving to a multi-cloud strategy is not for everyone, and the barriers and challenges to overcome if this is option is considered.
Not all clouds are the same
In theory an application can be stretched over multiple cloud providers environments, however “True Application Portability” involves barriers that must be overcome prior to the app becoming portable, or truly multi-cloud enabled.
First, Virtual Machines (VM’s) must be eliminated from the application architecture. Not all clouds are the same under the covers. Each cloud has its own underlying abstraction layer, often called the Cloud Service Fabric, this is where network, compute and storage are presented to the VM that is usually used to host applications. For Example, AWS Networking is significantly different to Microsoft Azure Networking and in turn both AWS and Azure Networking are significantly different in their set up from GCP Networking. It is the same for virtual machines, a VM running on Azure cannot be automatically moved to AWS and an AWS VM cannot be directly moved to GCP.
If a VM is to be moved to a new cloud provider, the VM image will need to be modified to match the cloud fabric of the underlying target platform. Compute and storage offerings differ between cloud providers and often provide their own challenges in relation to application portability. These issues are compounded if the application uses Platform-as-a-Service (PaaS) offerings, for example Database-as-a-service (DBaaS), WebApps, or message broker components where the underlying data storage elements, website delivery mechanisms and application logic are proprietary to that particular cloud offering.
If the application uses Functions-as-a-Service (FaaS) (cloud services that provide an automated platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure themselves) then the task of portability becomes even more complex as once again each cloud’s FaaS nuances are specific to the cloud provider.
But if VM’s, PaaS and (serverless) FaaS architectures aren’t available, what can a developer do?
This interoperability issue between clouds can be viewed as the problem an international traveller has when they want to charge their laptop in several different countries. You either carry a plug for each power system (so one for the UK, one for Europe and one for the USA) or you carry an adapter that works anywhere.
For application architecture, that adapter would be a product like Docker, a container framework that is the same no matter what cloud it sits upon. However, containerising an existing application is not necessarily an easy or cost-effective thing to do. Containers are a lightweight hosting architecture designed to spin-up and shut-down rapidly, scaling to match resources directly to demand. Containers allow you to pay the least while delivering the most from your cloud. The heavier a container the less portable it is.
Challenge one: Breaking an application down to microservices
To be able to run containers at scale across any cloud, the first thing you need to do is to break the application up into small component parts called microservices. Each microservice has its own container.
