A hands-on approach in the journey to demystify Multi-Cloud
By: Mauro Krikorian
Tags: AWS, Multi Cloud, Serverless, Azure, Serverless Framework

A couple of years ago we, with my colleague and friend Gabriel Barzola, got deeply involved into an amazing project which aimed building a Multi-Cloud Business Platform for one of our main customers in the US. At that time the cloud providers of choice were AWS and Azure, so we leveraged our years of experience working on each platform into brainstorming and putting together the best solution at hand to support business requirements — anyway the scenario was kind of new to us: combine something that we have had been using separately through the years, and before facing this exciting challenge, into a technical synergy that fulfills customer’s needs.

Luckily, business have kept us busy since then, but during this COVID year we had the opportunity to sit down and to write about our experience, share some tips and advice with the everyone out there who wants to give its first steps into this world.

Before moving forward I want to mention the group of people that collaborated on creating this article, the reference implementation linked to it and/or provided valuable feedback to allow me sharing it with you: Gabriel Hector Barzola, Elias Sebastian Cáceres, Lorenzo Luis Chiabotto, Waskar Alejandro Daza Millone, Marcos Oscar Jaule, Fabio Orlinski & Martin Vergara.

We all hope you enjoy it 😃

A little bit of history

No more than 20 years ago, most companies had their applications and services deployed within their facilities. This provided them with greater security, they maintained total control of the information, controlled their hardware, and the uptime of their services depending on their facilities; of course all these benefits were at the palm of your hand but you had to do it right — you needed to hire the right IT people for the job. It is currently a practice that is still in use, although alternatives have emerged over the years.

In the mid-2000s, cloud service providers began to emerge offering the possibility of having virtual technology to host a company’s applications off-site, without the need for capital investments, with the possibility of regularly supporting and paying just for the resources that were used. Little by little, companies began to partially or totally migrate their services to a cloud provider.

Today, the number of cloud providers is growing, their services are improving and they continue to increase significantly, seeking to reach the largest number of geographic regions. There is a wide array of decisions to be made when choosing between one provider or another, but you need to stick with just one. Using a multi-cloud brings into the picture a lot of possibilities and, taking the best offerings from each one of them, you can choose all those that meet your needs more efficiently.

Finally, if you decide to go down this path, you end deploying services to multiple clouds according to your best convenience and necessities, but how?

If you have ever wondered: ‘Is multi-cloud for my solution?’, then keep reading

The model of using the services of multiple cloud providers to host your business features and functions, as most choices you have in life, has both advantages and disadvantages.

For many midsize companies and enterprise-grade organizations, multiple cloud architecture is a smart investment strategy, as it can help increase efficiency, enable rapid scalability, and retain the flexibility to innovate quickly. Today the boom of open source technologies makes it easier to move from one cloud to another if you have chosen the right toolbox — languages, platforms, stacks and frameworks like NodeJs, Python, Spark/Databricks, Docker, Kubernetes, and so forth and so on, are among the right choices to develop a perfect combination that allows you avoiding a vendor-lock cloud solution.

However, to get a better answer to this question as not only choosing the right set of tools to do the job, it is better to make decisions considering the advantages and disadvantages of adopting this type of architecture.

Let’s see the good things first…

Risk Mitigation

Besides most cloud providers have high levels of availability within their Service-Level Agreements (SLAs), the continuity of the services delivered by your solution can be ensured, in case a cloud provider fails. Since, and if well-architected, your solution relies on having within each cloud provider a full working environment that sometimes can stand as a fallback for the primary or work together (we will see more about this later on).

Avoid Vendor Lock-In

You can reduce your dependency on a single provider and benefit from the best features each provider offers, as well as combine their services to address your business needs. This is simpler if you implement your solution relying on IaaS services provided by each of the cloud providers you want to use as the approach makes the management less troublesome when considering strategies that allow us to define our workloads without coupling ourselves to specific vendor’s services; of course if within your implementation some of their SaaS services are being used this would be a little bit more tricky as you might want to consider using some abstraction layer (we will see more about this later on).

Lower Latency

As cloud providers have data centers in different regions of the world, your company can choose to use those ones closest to your customers according to that availability and the regions where you deliver your services.

Moving workloads to the right cloud

It is possible, by using a smart load balancing strategy, to redirect requests to the provider that has more resources at the time being.

Now… What’s not so good when you take this road?

Talent Management

You need people with the knowledge to manage multiple providers, some might need to be certified on specific set of services provided by each of the different clouds you want to take into consideration to take the full advantage of them. The costs of staff training & certification must be considered. This disadvantage will be notorious based on the type of solution you implement: for example using SaaS services will require a deeper/tailored knowledge on what those services provide to take full advantage of them; as a counter-example if you use IaaS services, where you just have the infrastructure available to deploy your solution, things might become easier. Anyway, at the end, each one will highly depend on your specific scenario.

Cost Estimation

Each cloud provider has its own prices for the different services it offers, and in most cases, it is necessary to know them precisely to have more ‘accurate’ estimates on the final costs for your solution. This requires an additional effort when analyzing all the possibilities.

Security Risks

When applications are deployed in multiple cloud providers you potentially increment the number of security threads and vulnerabilities that attackers might exploit on your solution. It is necessary to have a good knowledge on how to tackle each of them in their respective clouds, and to implement and monitor the security aspects of the solution accordingly and continuously. This disadvantage is, in part, mitigated if we leverage SaaS services where the ‘main’ responsibility falls into the security mechanisms on top of those services supplied by each cloud provider; on the other side, when relying on IaaS services, you have a bigger responsibility as you have more security alternatives to make them available to the world.

Operational Overhead

When it is necessary to perform updates or operational tasks, they may require more effort since each change must be replicated to each cloud provider and adds an extra layer of complexity. This might be more or less of an issue whether you use SaaS or IaaS services, as we mentioned this will mainly depend on your scenario, abstraction, security layer, etc. you might use but it is still a factor to take into consideration (more likely when relying on SaaS services the impact will be bigger).

What’s the difference between Multi-Region vs. Multi-Cloud Applications?

Cloud providers work very hard to get as close as possible to 100% uptime. This is incredibly difficult and gets much harder as you get closer to the 100% mark. All it takes is one small blip and suddenly you’re at 99.95% instead of 100%.

One way that businesses can survive an outage is by spreading their applications across regions leveraging a load balancer that distributes traffic. If one region experiences an outage, the other region can continue to serve traffic. The trade-off is that your deployment and running costs are higher than a single region, but your reliability goes up. If you understand the full cost of an outage to your business, then it becomes very easy to justify a multi-region approach.

Multi-region is a great start, but it isn’t enough for some businesses. When an outage happens: As your loses increase, your need to move beyond a single cloud provider also increases. An even higher level of availability is achieved by running your solution across multiple providers and multiple regions in each provider, taking advantage of better coverage.

Main cloud providers’ locations:

As we already mentioned, building in more than one cloud can increase development and administration costs, so it is very important to analyze what type of architecture best suits the needs of your company/solution. This way better decisions and optimizations can be made regarding costs — as an example, effort and cost will reduce drastically when applications are designed to run on containers and independent cloud platforms.

So… What Multi-cloud flavors do we have?

The multi-cloud architecture provides a way for companies to create environments outside of traditional infrastructure approaches using various clouds that host multiple services. When implementing a multi-cloud architecture, it is possible to choose to implement an Active-Active or Active-Passive architecture.

Active-Passive

In an active-passive architecture deployment, a service is deployed to one cloud provider and a copy (or backup) exists into another cloud provider.

The second provider is activated only if the first provider has a failure of some kind (i.e., as a fallback mechanism). In the second cloud provider, we have the service up-to-date and working like the service offered by the first provider.

The difference between the two providers is that in the second provider there are no active sessions or connected users during normal periods of operation, all traffic is directed to the main (or primary) cloud provider. If there is a failure in the main cloud provider, the active provider, the second provider can be activated manually or automatically depending on the case.

Active-passive architecture

Active-Active

An Active-Active architecture is provided when a service is deployed to at least two cloud providers and both are up and running, that is, they receive and respond to requests simultaneously and this is totally transparent to the service consumer.

The same service is implemented in both clouds, and a load balancer takes care of distributing the requests between both providers considering the location, the state of each one of them and/or simply using load distribution algorithms.

Each of these providers responds to requests based on the decision of the load balancer. If any provider becomes unavailable, the load balancer becomes aware of that situation and the other provider can start responding to requests.

Active-active architecture

What’s the best one?

Neither type of architecture is better than the other, the best option depends largely on your business needs, internal processes, and specific standards of your organization.

Both types of architectures want to guarantee high availability, they ensure that if any cloud provider fails, requests to services can be resolved and the final users will ‘not notice’ the failover.

It should be considered that in an active-passive architecture, the cloud backup providers are ‘active’, that is, the entire infrastructure is active and waiting to respond to requests. This architecture is usually more cost-effective than active-active, the internal data syncing mechanisms (if any) can be more relaxed than using an active-active scenario, but still generates costs and demands workloads.

Regardless of whether you choose one architecture or the other, it is necessary to keep both cloud providers always active, up-to-date, and tested. There are costs, not minor, related to the training of the personnel responsible for the management since, beyond the fact that both cloud providers provide similar services, each one has its own set of services and there is always a small/big learning curve when implementing those services as their best. How can you do this then, without writing everything twice or thrice?

Serverless to the rescue

What are Serverless Computing and the Serverless Framework?

Most cloud providers offer compute runtimes also known as function as a service (FaaS) platforms. Serverless Computing is a cloud computing execution model in which the cloud provider runs your services, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. The management and details of these resources are transparent to the application developers.

The Serverless Framework is open source software that builds, compiles, and packages code for serverless deployment, and then deploys the package to the cloud. Finally, it copies the code to the target cloud provider and initiates the CI/CD pipelines for stack creation or update, which provisions cloud provider services for the serverless application.

Why to use Serverless?

Nevertheless, this is not the only benefit, it has autoscaling built-in, when requests came in the service our application scales to meet that demand, also, you don’t pay for the provisioned capacity, instead, you only pay for the resources you consume, reducing clouds costs.

Finally, due to the function isolation, the developer is able to know faster where an issue is and focuses on the specific function he is trying to provide.

How does it help us with a Multi-Cloud solution?

Each cloud provider has its own serverless implementation, but what happens when you want to use multiple cloud providers? A potential customer may view it as a challenge with considerable operational costs and impact. Therefore, you can use a framework like Serverless Multi-Cloud to solve this.

The Serverless Multi-Cloud Library

At SOUTHWORKS we have developed a Serverless Multi-Cloud Library that can help you implement your solution targeting more than just one cloud.

With this library, you can easily implement serverless handlers in Node.js in a cloud agnostic way that can be deployed to supported cloud providers such as AWS or Azure.

Also, it’s open source, open to contribution and it can be extended using middlewares, the same way express does, to support more cloud services.

Its main goals are to:

Create a cross-industry solution

Support a cloud-agnostic API that interfaces with microservices wherever they are deployed

Support a GitOps CI/CD process workflow for development, testing, and deployment on all supported cloud platforms

Use API-based access via an authenticated cloud gateway

Load balance between cloud platforms by using the gateway as a router

Out of the Box Middlewares

The Serverless Multi-Cloud Library includes several middlewares that can be added to the handler depending on the functionality you are looking for.

Processing pipeline example

HTTPBindingMiddleware

The HTTPBindingMiddleware allows you to abstract your code from each cloud provider specific request and response using a unique interface to use the information through common elements such as parameters, status code, etc.

ValidationMiddleware

The ValidationMiddleware gives you the chance to abstract the validation logic of your handler out of the implementation itself. To use it, you simply define two objects, one with the validation you want to do, called ValidationOptions, and another one called ValidationResult which is created by the latter, contains the result of the validation and whether it was successful or not.

By doing this, you can abstract the handler from its validation business logic as well as any other type of validation you want to do, for example, authentication or authorization logic.

StorageMiddleware

The StorageMiddleware adds the proper abstraction layer with a context that abstracts the write and read functions for each cloud provider.

This allows you to read from any cloud provider with the container name (Bucket name in AWS or GCP and Container name in Azure) and the file path as parameters, and write by adding a third parameter called body that specifies the content you want to write.

/** Read **/ context.storage.read({ CONTAINER, PATH }); /** Write **/ context.storage.write({ CONTAINER, PATH, BODY });

Ok, let’s stop talking theoretically, and build something!

We’ve prepared a simple workshop so you can get started using the Multi-Cloud library.

What are we going to build?

What you are going to build in this section is a calculator API that allows addition, subtraction, multiplication, and division operations, and has the ability to save the current result in storage, simulating a calculator with a paper roll.

A paper-roll calculator. Yes, they are real.

You will write the code for this only once, and deploy it to AWS, GCP and Azure clouds getting two different endpoints to use it.

When you want to start an operation, include the two operands and the operator in the request to the endpoint. The response has the result of the operation and the session id where the ongoing calculation is stored. If you want to keep operating over the stored value, simply remove the first operand from the request and include the session id from the previous response.

Now that you already have an idea of what our goal is, let’s start by creating the project that you want to deploy. The following image is an architecture diagram representing a calculator with storage in a multi-cloud environment.

Calculator with storage workshop’s architecture

If you want to run this workshop locally, complete the Prerequisites section of this README to setup your dev environment.

Let’s get our hands dirty!

Start by creating a clean Node.js project into an empty folder called calculator-with-storage. Follow the prompts and accept defaults:

npm init

Once that’s done, install the Multi-Cloud Framework Library:

npm install @multicloud/sls-core @multicloud/sls-azure @multicloud/sls-aws @multicloud/sls-gcp --save

Then, proceed to install the Serverless and Azure Functions support for Serverless Framework:

npm install -g serverless

npm install serverless-azure-functions serverless-google-cloudfunctions --save-dev

We have been developing a GCP module while working on this article. If you are trying to install it and it has not yet been published by the serverless team, you can find the necessary files to run it here.

You are ready to write some code! Create a src folder at the root of the project and create the following files in there with the respective content:

calculator.js: Includes the calculator logic. That is, the operand and operator definitions of your calculator.

validate-input.js: Includes the custom validation options that will be used by the validation middleware in order to verify that the calculator inputs are correct.

storage.js: Includes some auxiliary functions to perform write and read as a string to the Azure container, GCP bucket or AWS bucket.

calculator-handler.js: Contains the handler definition, which orchestrates the whole process. This is the entry point of the app.

Then, create the following files with the respective content into the root of the project folder:

serverless-aws.yml: Includes the definition of AWS services to run the calculator.

serverless-azure.yml: Includes the definition of Azure services to run the calculator.

serverless-google.yml: Includes the definition of GCP services to run the calculator.

config.aws.json: Includes the definition of AWS environment parameters. Replace the region with yours.

config.azure.json: Includes the definition of Azure environment parameters. Replace the region, *azAccount, and *azAccountKey with yours.

config.google.json: Includes the definition of GCP environment parameters. Replace the bucketName with yours.

azuredeploy.json: Includes the properties to create the resources in Azure.

Finally, update your package.json scripts with the ones from this file.

* In the How to Deploy section on this README you can find the entire steps guide to obtain your own azAccount and azAccountKey. In this repository you can find the entire implementation of the sample, in case you prefer to clone the repository instead of creating every file manually.

Deploying

Run the following commands to deploy the multi-cloud calculator with storage.

Deploying to AWS

npm run deploy:aws

Deploying to Azure

npm run deploy:azure

Deploying to GCP

npm run deploy:google

Done! You got yourself a multi-cloud calculator with storage API.

In this repository you can find the entire implementation of the sample.

Next steps

We’ve created samples to help you guide your implementation of a multiple cloud solution. Here are some resources in case you want to know more about it or add a different cloud provider.

Looking for more information about Serverless Framework multi-cloud solutions? We also suggest you have a look here

Searching for more about AWS serverless? Look more about it here

Need some information about Multi-Cloud Architecture Migration and Security

Needing some repositories with samples in order to start? Here are some links: