What is Multi-Cloud Development and Top 5 Strategy for Multi-Cloud development

What is Multi-Cloud Development and Top 5 Strategy for Multi-Cloud development

One of the strategic decisions that enterprises need to take is how they can be cloud-agnostic due to various drivers that includes cost model, customer affinity towards a particular cloud vendor, availability of cloud regions, disaster recovery strategy or compliance and regulations.

From a development and deployment perspective, multi-cloud development basically tries to address one common concern -

“How can I build applications once and deploy on any cloud platform or virtually in any environment”.

We have over 100+ services offered by various cloud platforms. So how do you build cloud applications, so you are cloud-neutral and get the flexibility to choose and deploy on any cloud platform without any changes or with very minimal changes?

I am sharing my learnings on the principles applied to one of my earlier products to be multi-cloud ready, which helped us migrate across public cloud vendors. Let's move on to the first principle-

Design For Containerization

As part of this step, you leverage container-based development and make software applications as independent units that can be deployed in any cloud environment, supporting container-managed services, like Google Kubernetes Engine or Azure Kubernetes Service (AKS) or Amazon container-managed services.

For those who are not aware of what microservices are, it is basically an architecture style, to break down large applications into loosely coupled services that can be independently deployed and scaled. For a banking app, microservices could consist of various transaction services, like credit card transactions, domestic bank-to-bank transfers, international transfers, etc.

If you like to know more about how the technology trends (i.e Monolithic, Web Services, SOA, MicroServices, Container, CI/CD, Cloud Neutral, and DevOps ) have evolved over the last two decades, check out my video - @?https://www.youtube.com/watch?v=scHl4YcQBdo

Following is the visual card, which summarises the first strategy.

Cloud Agnostic

There are 100+ compatible services offered across cloud platforms. For a list of services offered by the cloud vendor, I have developed a cloud comparison tool - https://cloudsolutions.academy/cloud-compare/ that compares various offerings offered by the cloud vendor and help choose a compatible service.

But compatibility doesn’t always imply interoperability in all cases. For instance, if you take an example of a No-SQL database, you can use open source distribution like MongoDB instead of using compatible versions offered by AWS like DocumentDB.

There might not be 100% portability across services, so you need to be aware of any limitations or features that are not supported by looking at the cloud vendor product documentation.

So you need to select the right services and evaluate trade-offs based on your application requirements. For instance, for a relational database, you can choose PostgreSQL, SQL Server or MySQL as these are widely supported (including the latest versions) on all cloud providers.

Secondly, pick up services where managed offerings of open source version are offered by the cloud vendor, like for Prometheus (open source monitoring tool) use Google Cloud Managed Service for Prometheus for Google Cloud or Amazon Managed Service for Prometheus for AWS Cloud. This ensures a migration path if you choose to move to a different cloud provider.

In cases, where you need to go with proprietary cloud services, follow the third strategy - API abstraction.

Following is the visual card, which summarises the second strategy.

API Abstraction

Next, as you build real-world applications, you might not always get the flexibility to choose a service that is 100% compliant across cloud platforms.

So how do you ensure flexibility and can change services with minimal changes?

You can design and create well-defined interfaces and APIs as the level of abstraction between your application and the cloud services. For example, instead of using an API for a cloud service directly, you can create your own generic API and the generic API can call the cloud-specific API.

Your application always deals with the generic APIs that you have created, providing you the flexibility to change the implementation without affecting the overall application

The following visual card summarizes the third strategy.

Data Lifecycle Strategy

Data from a regulation perspective can be broadly classified as PII or no-PII. PII stands for Personal Identifiable Information. Examples of PII data are identity details like SSN numbers, passport numbers, contact details, and basically any piece of information that can help identify an individual, directly or indirectly. And based on data sovereignty and regulations, the PII data can’t leave the geographical boundary, like personal data from the Europe region can’t reside in India or US.

And there are other sets of data, like analytics, click-through data, and general non-PII data like geography, age range, etc., which you might require for downstream processing, either for analytics or training AI models for generating insights.

The idea is to decouple the PII and non-PII data, right from your design, for example through unique non-PII identifiers for your primary data, so storage and processing can happen independently.

And this decoupling is important because it provides flexibility to use required specialized cloud services and regions for non-PII data, even from other cloud providers, and avoid vendor-lock-in, while PI data runs on a given cloud region and provider as per the required data regulations.

The following visual card summarizes the fourth strategy.

Standardize On DevOps Tools

The last strategy is to standardize DevOps tools. For those who are not aware of DevOps, DevOps is basically a methodology on how you can build, develop and deploy applications consistently and have a tight collaboration between developers developing the application and the operating team deploying, securing and monitoring the application.

And CICD (Continuous Integration and Continuous Delivery/Continuous Deployment.), provides the methodology and tools to make it happen. Like Jenkins is one of the open-source tools for CI/CD, which is used in conjunction with source repositories and version control applications like GitHub.

So for CI/CD, ensure you use open-source tools like Jenkins and monitoring tools like Prometheus to provide a vendor-neutral DevOps and monitoring process across any cloud provider.

For more details on What is CI/CD and DevOps, please check out our video - @?https://www.youtube.com/watch?v=scHl4YcQBdo

The following visual card summarizes the fifth strategy.

This completes the multi-cloud strategy principles. Do share your feedbacks and inputs in the comments section.

#cloud #multicloud #IndiaPostingChallenge #devOps