Multi-cloud Architectures for Applications

Multi-cloud architecture for distributed application

Back story

Companies are embracing cloud as part of their key business strategy. Huge part of this embrace is moving their applications to cloud. This created a challenge for major cloud providers, like Amazon, Microsoft and Google, to offer a slew of services that would help companies move to cloud. That brought us to era of cloud architectures. Huge progresswas made (and still is being made) in this area.

As progress was being made in moving to cloud, a risk emerged called “vendor lock-in”. This essentially meant that when the applications where being moved (or even when new applications where being created), the architecture was focused on the services that were provided by on cloud one cloud vender. This is critical because this makes the consumers of applications more vulnerable to dependencies. This was not the only risk that emerged but this was the most significant
and attention.

To remedy that “Multi-cloud” or “Portable” architecture was embraced. Applications were architected in such a way that they could be ported from one cloud provider to another without any major rewrites. New technologies like Kubernetes, Docker and services orchestration technologies went along way to provide underlying technologies to mitigate the “vendorlock-in” risk.

What is Distributed Application Multi-Cloud architecture?

The multi-cloud architectures were great in providing resiliency and removing underlying dependencies which would have locked in to a particular vendor. This made solutions architects to focus on treating their solution as one big entity deployed in redundant fashion. It took focus away from actual application architecture and its nitty gritty details that would have been leveraged by cloud.

“The basic idea of Distributed applications multi-cloud architecture is to architect a solution that is leveraged to the max by cloud and not bounded by the offerings of a cloud provider”.

Every application, albeit micro service or not, is made of constituent components, services or layers. In Distributed Application Multi-Cloud architecture, the architects focus on application’s different components and treat them as components, services or layers that can be deployed to any cloud to gain the maximum benefits.

Advantages of Distributed Application Multi-Cloud architecture

As stated earlier, Distributed Application Multi-Cloud architecture is the evolutionary form of Multi-Cloud architecture, it carries all the advantages of Multi-Cloud architecture. In addition to those advantages, Distributed Application Multi-Cloud architecture offers following advantages:

1. Extra layer of robustness: Since the focus is on the on application’s different constituent components/layers/services, the architecture achieves an extra layer of robustness.

2. Best use of resources: Cloud providers (mostly big cloud providers like Amazon, Google and Microsoft), offer different services with their own pricing model. When a service offering comparison is made between these cloud providers, it would be apparent that some services would be cheaper than other cloud service providers and some would be more expensive than other cloud providers. A Distributed Application Multi-Cloud architecture can provide a solution that would take advantage of the difference in pricing model for different services offered by cloud providers to the advantage of the company for which the solution is being architected. This can translate into considerable cost
advantage.

Here is an example:
You have an API that needs to be deployed with access to general public. This API requires a backend storage. It might make sense to use Azure App Service to host the API and use Azure’s blob storage for the backend storage. But hypothetically, it might appear that using Google’s cloud storage product be a cheaper option without sacrificing application performance.

3. Higher level of services statelessness: As the application’s constituent services are distributed to different cloud providers, a higher level is achieved for the constituent services.

Tenants of Distributed Multi-Cloud Applications Architectures

• Distributed multi-cloud application architectures is the concept for architecting solution to achieving maximum advantage by harnessing service offerings from any cloud provider.

• Focus on looking at the Application’s constituent components as separate entities that can be leveraged to achieve maximum benefit.

• Not every cloud architecture would be a good fit for Distributed Applications Multi-Cloud architectures.

Step by step guide

1. Review application architecture. The end result of this step is an in-depth understanding of the application, its behavior and environment.

2. Identify constituent components of the architecture. This step should yield a list of all the constituent components of the architecture that make up the whole architecture. This very important step as if the constituent components are not identified properly then benefits of the multi-cloud would not apparent.

3. For each constituent component, identify components that can be deployed/hosted on cloud. This would yield constituent components that can be moved/hosted on cloud.

4. For each cloud component (constituent components that can be moved/hosted on cloud), identify the cloud component that can be deployed/hosted on multi-clouds.

5. Re-architect the application based on previous step. This step should yield an architecture that is multi-cloud.

6. Go through each component of the multi-cloud architecture and use a decision tree (give below) to identify if that component should leverage multi-cloud or not. At the end of this step, you will have each component identified for multi-cloud or not.

7. Analyze the architecture as a whole for determine if the multi-cloud should be used. The rationale of this step is to see if there is cost/performance/security benefit that would be leveraged using multi-cloud. If there is only one component that can be leveraged using multi-cloud (and produces considerable benefits as one), then it might not make sense to use multi-cloud.