Two-Factor authentication with Azure sphere and Azure IoT hub - Step by step

Introduction

The story began in my previous post Two-Factor authentication with Azure sphere and Azure IoT hub where I introduced the idea of using Azure sphere and Azure IoT to create a two factor authentication solution. In this post, we will look deep into the technical details of implementation. This is a little longer blog post. I have tried my best to make it as simple to understand and follow as it is possible. I start off by given out the high-level architecture mentioned in my previous blog post and then the technical architecture that is the technical evolution of the high-level architecture. Then I start with how the authenticator application will carry out two factor authentication. I show the screens so that it is easier to grasp the technical details that will follow. Then we take a look at the key components of the technical implementation of two-factor authentication with Azure Sphere and Azure IoT hub. At the last section, we will take a look at the step by step flow of the technical details.

If you have any questions or need any details on part of this implementation, please feel free to contact me at: mnabeelkhan@gmail.com

Prerequisites

1. Since Two-Factor Authentication using Azure Sphere is based on Azure Sphere device connected to user's machine, it is important to mention that the prerequisite of this system is to have Azure Sphere device properly connected the user's machine. Information on setting up Azure Sphere device with a machine is provide in previous blog post Getting started with Azure Sphere
2. The second prerequisite is to make sure the Azure Sphere device has been added to an Azure IoT hub. More information for that can be found at Microsoft Docs article Set up an IoT Hub for Azure Sphere
3. The final prerequisite is that the Azure Sphere device has a deployed version of the code that is part of the Two-Factor authentication. The last section before the conclusion mentions the code that is needed for the Azure Sphere part of the solution under the heading Azure Sphere - main.c code.

Let us start by taking a look at the high-level architecture design for presented in the post  Two-Factor authentication with Azure sphere and Azure IoT hub

Figure 1 - High-level architecture

Taking the high-level architecture forward, the evolved technical architecture is created as shown below:

Figure 2 - Technical Architecture

Before taking a detailed look at the technical architecture, let us start with looking at how the Authenticator application will work. This will give a good overview of what we are building (in terms of the end goal) and it will make it easier for us to understand the technical details.

User Interaction Flow

This sections illustrates the step by step interaction of user with the authenticator using screen shots.

1. Login page to initiate the first factor authentication

Figure 3 - Login screen

This step is quite simple. The above screen just carries out the first factor authentication.

2. User enters the user name and password for first factor authentication

Figure 4 - Login screen with user input

3. After successful first factor authentication, user is presented with a page to complete the second factor as show below:

Figure 5 - Second factor authentication screen showing status as "Pending"

4. As instructed in the Second factor authentication page, user presses the button "B" on the Azure Sphere device and the clicks the "Validate Second Factor" button on the screen.

5. As the result the authenticator validates the second factor and shows the authentication result as show below:

Figure 6 - Second factor authentication screen showing status as "true" (authenticated)

Now we have seen how the Authenticator application will look like and how it will interact with user, let delve into key components of the Two-Factor authentication using Azure Sphere and Azure IoT hub.

Key Components

User

User is initiator and the requester of the two factor authentication. It represents the user using a machine or device that is connected to Azure Sphere. The prerequisite section of the post Two-Factor authentication with Azure sphere and Azure IoT hub mentions the essential prerequisites for the user. 

Azure Sphere

This is the device that is attached to the user machine. It is responsible for second factor authentication. The request are received by the Azure Sphere by the Azure IoT hub and based on the request, it creates the security code that constitutes the essential part of the second factor authentication.

Authenticator

This represents the application that needs carries out the Two-Factor authentication. This can be a web app or an API. The authenticator acts as the controller of the Two-Factor authentication system by coordinating the calls that are requesting for first factor or second factor authentication. It talks to Azure Table Storage and sends requests in form of notifications to IoT hub when it needs to talk to Azure Sphere.

Azure IoT hub

Azure IoT hub is the central point of contact for requests and responses that are received to complete the second factor authentication. The Azure IoT hub receives the requests from the Azure Sphere device and forwards it as an event notification. The event notifications are then consumed by the Azure functions for processing. As mentioned in the prerequisite section of  Two-Factor authentication with Azure sphere and Azure IoT hub the Azure Sphere device has to be provisioned with Azure IoT hub.

Azure Table Storage

Azure table storage acts as the backing store for all the requests. When authenticator receives a requests, it creates a record in the TwoFactorRequest table which constitutes the Azure table storage. When Azure Sphere creates the security code, the security code is saved in the TwoFactorRequest table under the column "CreatedSecurityCode". When Azure Sphere retrieves the security code from its mutable memory, it is stored under the column "RetreivedSecurityCode". The authenticator uses these two columns to validate if the user has completed the second factor authentication or not.

Let us take a look at the structure of TwoFactorRequest Azure table storage.

Figure 7 - TwoFactorRequest table structure

Here is a quick view of the TwoFactoRequest table structure.

Figure 8 - Azure table storage quick view

Azure Function

There are two Azure Functions created for this solution. These are "Recorder" Azure function and "Validator" Azure function. The primary purpose of the these two Azure Functions is to receive notification for Azure IoT hub and post the results to Azure table storage in the TwoFactorRequest table. These Azure functions uses the built-in endpoints in Azure IoT hub to hook into event notifications. More detail on how to use built-in endpoints can be found on my previous blog post Leveraging Built-in endpoints in Azure IoT Hub

Although the architecture proposes to two use two separate function, we can use one function to be consumer of all the events and based on the request type, it can route to functions that will fulfill the tasks of either the "Recorder" or "Validator" functions. 

Here is the code snippet for the Azure function

Let us take a look at the code real quick. The Azure function is represented in form of static class called "DeviceMessageRecorderFunction". This class listens to event hub triggers by the user of its "Run" method. In the "Run" method the Azure Function looks at the message that it received from the Azure IoT hub. As mentioned the Azure IoT hub sends the event notification for two times. These are when the security code is created and when the security code is retrieved for validation. The Azure IoT sends these event notification messages as a result of being invoked by the Azure Sphere. For these two events, the message body is different. The message is "|" separated string.

When the security code is generated by the Azure Sphere it posts the message to Azure IoT hub in the following format.

Message format: userName|uniqueId|correlationId

Message example: admin|d6c28aef-8da6-4678-806d-2634b30266fc|e386a74be1ef4795a41432f2d59f8136

When the security code is retrieved for validation, the Azure Sphere sends the message to IoT hub in the following format

Message format: userName|uniqueId|correlationId|securityCode

Message example: admin|d6c28aef-8da6-4678-806d-2634b30266fc|e386a74be1ef4795a41432f2d59f8136|32322|retrieved

Going back to the "Run" method code, the code checks for the method type and based on its type it enters the data in the Azure table storage. This method takes care of both "Recorder" and "Validator" functionality.

Step by step flow

Let us take another look at the technical architecture:

Figure 9 - Technical Architecture

Let us take a look at the technical architecture in detail in terms of steps.

1. The user sends the first factor authentication request in form of the user name and password as a secured post request.
2. The authenticator validates the user name and password request thus completing the first factor authentication.
3. In this step the authenticator creates a record in the TwoFactorRequest Azure table storage. It will have both "CreateSecurityCode" and "RetrievedSecurityCode" fields as null. This represents that a new request is going to go through the second factor authentication.
   Here is the code that that creates a new record in the TwoFactorRequest Azure table
   
4. After creating a new request in TwoFactorRequest table, the authenticator sends a message to Azure IoT to request the Azure Sphere device to create a new "SecurityCode" using direct method to Azure Sphere.
   
   
   Here is the message format that is sent to Azure Sphere through Azure IoT.
   Message format: userName|uniqueId|correlationId
   
   
   Message example: admin|d6c28aef-8da6-4678-806d-2634b30266fc|e386a74be1ef4795a41432f2d59f8136
   
   Here is the code that invokes a direct method to Azure Sphere through Azure IoT:
   
5. As a result of the "DirectMethod" invocation, the Azure Sphere device generates a "Security Code" for second factor authentication. 
6. Azure Sphere device then saves the created "Security Code" in its mutable memory and notifies the Azure IoT. The message that is sent to Azure IoT from Azure Sphere is show below:
   
   Message format: userName|uniqueId|correlationId|securityCode
   
   
   Message example: admin|d6c28aef-8da6-4678-806d-2634b30266fc|e386a74be1ef4795a41432f2d59f8136|2123
   
   In the above message the last segment "2123" represents the security code created
7. Message is forwarded by the Azure IoT to Recorder function that is listening to events coming out of Azure IoT hub. The code mentioned in the section under "Azure Functions" takes care of that.
8. The Azure function then updates the TwoFactorRequest table with the "SecurityCode" received from Azure Sphere through Azure IoT hub.
9. As part of the Two-Factor authentication flow, the user has to press the button "B" on the Azure Sphere device. This ensures the user has access to the Azure Sphere device and the Azure Sphere device is properly provisioned with Azure IoT hub.
10. Once user presses the button "B" on the Azure Sphere device, the Azure Sphere device retrieves the "Security Code" as the second factor from its mutable memory and posts it Azure IoT hub.
    For this step, the message that is sent to Azure IoT hub is in the following format:
    
    Message format: userName|uniqueId|correlationId|securityCode|retrieved
    
    Message example: admin|d6c28aef-8da6-4678-806d-2634b30266fc|e386a74be1ef4795a41432f2d59f8136|32322|retrieved
11. The Azure IoT hub receives the retrieved message for validation and generates an event hub notification. This event hub notification is received by the Azure function. The code mentioned in the section under "Azure Functions" takes care of that.
12. The Azure Function then validates that the security code that is retrieved is same when the first time Azure Sphere sent message as part of step 6.
13. The Azure Function, then updates the TwoFactorRequest table with the retrieved "Security Code".

Once all the steps are completed and the security code is verified to be the same, the authenticator then notifies the user of successful authentication.

Azure Sphere's main.c code

Conclusion

In this blog post, we have seen how to implement Two-Factor authentication using Azure Sphere and Azure IoT hub. We have started off with the user interaction screens to have an overview of what we are building. Then we looked deeply in each key component of this system. After that the steps help us explain the technical architecture in detail.

If you have any questions or need any details on part of this implementation, please feel free to contact me at: mnabeelkhan@gmail.com

How to read appSettings JSON from Class Library in ASP.NET Core without modifying the Class Library

Back story

I recently ran into an issue where I needed to read the settings from ASP.NET Core app into a Class Library project. Since I was creating the ASP.NET Core, I had the access to the source code. But the class library was already written and I had no access to source code and hence any change that I was suppose to do had to be done in the ASP.NET Core app.

I looked for solution and found one here : https://corderoski.wordpress.com/2017/09/18/how-to-read-appsettings-json-from-class-library-in-asp-net-core/

The solution was great as long as you have the ability to change both the ASP.NET Core app and the Class Library. Since I did not have the access to source code for the Class Library, I could not use that solution.

So I came up with following solution.

Solution

On the constructor of the ASP.NET Core app, I added the following code:

        public MyController(IConfiguration configuration)
        {
            this.configuration = configuration;
            var configFile = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
            var settings = configFile.AppSettings.Settings;
            configFile.Save(ConfigurationSaveMode.Modified);
            ConfigurationManager.RefreshSection(configFile.AppSettings.SectionInformation.Name);

            // Remove previous settings to ensure new settings are applied.
            if(settings[Settings1Key] != null)
            {
                settings.Remove(Settings1Key);
            }
            if (settings[Settings2Key] != null)
            {
                settings.Remove(Settings2Key);
            }
            if (settings[Settings3Key] != null)
            {
                settings.Remove(Settings3Key);
            }

            settings.Add("Settings1Key", this.configuration["Settings1Key"]);
            settings.Add("Settings2Key", this.configuration["Settings2Key"]);
            settings.Add("Settings3Key", this.configuration["Settings3Key"]);
            configFile.Save(ConfigurationSaveMode.Modified);
            ConfigurationManager.RefreshSection(configFile.AppSettings.SectionInformation.Name);
        }

Here the code change that I made to the Startup.cs file in the ASP.NET Core app:

        public void ConfigureServices(IServiceCollection services)
        {
            services.Configure(options =>
            {
                // This lambda determines whether user consent for non-essential cookies is needed for a given request.
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });

            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
            services.AddSingleton(Configuration);
        }

That is it. What we have done here is that we pulled the settings from the appsettings.json file on run time and modified the ConfigurationManager on runtime and saved it. Now when the Class Library is called, it had the access to the configuration that it was looking for.

Happy coding!

Two-Factor authentication with Azure sphere and Azure IoT hub

Introduction

This blog post introduces to a new way of carrying out two factor authentication using Azure Sphere. As more and more devices are being added to IoT world, there has been increasing need for a device that is secure and connects to Azure IoT to further automate the process. Azure Sphere fills that gap of secure communication. More information on Azure Sphere can be found at: https://azure.microsoft.com/en-us/blog/introducing-microsoft-azure-sphere-secure-and-power-the-intelligent-edge/

The intended goal of this blog post is to present a use of Azure Sphere. The best way to understand any technology is by creating a product or use that shows how the technology works and how it can be leveraged. This blog post presents a use of Azure Sphere by introducing a way to implement "Two factor authentication".

Information on how to setup Azure Sphere can be found in my previous blog post at: Getting started with Azure Sphere

Disclaimers

The information provided in this blog is intended to demonstrate a novel use of Azure Sphere. It does not recommend the "Azure Sphere based two factor Authentication" be used in production environment. The recommendation is to use the material provided in this blog as an opportunity to learn and understand Azure Sphere and Azure IoT.

Typical two factor authentication

Let us start by looking a typical two factor authentication. In traditional two factor authentication, a user (using a supported device like, smart phone, desktop or tablet), initiates the authentication by providing a user name and password to the authentication provider. Typically an authentication provider is the system that is part of a web site or an application. The authentication provider takes the user name and password and authenticates the user. This user of user name and password constitutes the first factor of the authentication. On successful authentication of the first factor (user name and password), the authentication provider sends a code to device that is associated with the user who is requesting the authentication. Typically the code sent through text or a phone call. The user receives the code. The authentication provider then provides a page for the user to enter the code that is sent. This code constitutes what we call the second factor. On receiving the second factor (code) the authentication provider verifies the code and completes the authentication process. 

Following diagram illustrates the typical two factor authentication flow.

Figure 1 - Typical two factor authentication flow

Two-Factor Authentication using Azure Sphere

The Two-Factor Authentication using Azure Sphere uses the same authentication mechanism for the first factor (i.e. username and password). But for the second factor it leverages the Azure Sphere device. The Azure Sphere device is attached to a device that is being used by the user requesting the authentication. This replaces the need to have the authentication provider send a code to a user device (such as phone for text message). Instead it relies on the Azure Sphere attached a users device to carryout the second factor authentication. The Azure Sphere device is connected to Azure IoT and that communication is secured by design.
The inspiration of using Azure Sphere as the second factor authentication device came from a paper called "The Seven Properties of Highly Secure Devices" published by Galen Hunt, George Letey, and Edmund B. Nightingale of Microsoft Research. Here is the link for that paper: https://www.microsoft.com/en-us/research/wp-content/uploads/2017/03/SevenPropertiesofHighlySecureDevices.pdf

Why use Azure Sphere for second factor authentication

1. Hardware based security. As mentioned in the "The Seven Properties of Highly Secure Devices" paper, the "Highly secure devices have a hardware-based root of trust." Here is the excerpt from that paper.
   Highly secure devices have a hardware-based root of trust. Device secrets are protected by hardware and the hardware contains physical countermeasures against side-channel attacks. Unlike software, hardware has two important properties that may be used to establish device security. First, single purpose hardware is immune to reuse by an attacker for unintended actions. Second, hardware can detect and mitigate against physical attacks; for example, pulse testing the reset pin to prevent glitching attacks is easily implemented in hardware. When used to protect secrets and device correctness, hardware provides a solid root of trust upon which rich software functionality can be implemented securely and safely. 
2. Secured Communication: The communication between the Azure Sphere device and Azure IoT hub is secured by Azure. As system implementor we would not need to secure the communication as we are leverage Azure for that. 

Prerequisites

1. Since Two-Factor Authentication using Azure Sphere is based on Azure Sphere device connected to user's machine, it is important to mention that the prerequisite of this system is to have Azure Sphere device properly connected the user's machine. Information on setting up Azure Sphere device with a machine is provide in previous blog post Getting started with Azure Sphere
2. The second prerequisite is to make sure the Azure Sphere device has been added to an Azure IoT hub. More information for that can be found at Microsoft Docs article Set up an IoT Hub for Azure Sphere

Authentication Flow with Azure Sphere

As mentioned above the first step is validating the factor 1 which is typical user name and password authentication. The following steps illustrates the flow information and authentication mechanism for the factor 2 (security code):

1. User provides the user name and password that is passed on to the authenticator (authentication provider). 
2. The authenticator validates the user name and password thus completing the factor 1 authentication. 
3. After that authenticator sends message to Azure Sphere device attached to the user's machine to generate a security code and instructs the user to press the Button 2 on the Azure Sphere device. Information on setting up Azure Sphere device is provide in prerequisite section mentioned above. 
4. The Azure Sphere device receives the request through its connection to Azure IoT hub. 
5. It then generates a security code, saves the security code in its mutable memory and posts the result to Azure IoT hub. 
6. Azure IoT hub informs the authenticator (authentication provider) about the generated security code. 
7. As instructed by the authenticator, the user presses the Button 2 on the Azure Sphere device. 
8. The Azure Sphere device retrieves the saved security code and posts the information to Azure IoT hub. 
9. The authenticator then receives the notification that user has pressed the Button 2 along with the security code that was retrieved by the Azure Sphere device from its mutable memory. 
10. The authenticator then validates the security code retrieved previously when Azure Sphere generated the security code and when the Button 2 was pressed. 
11. Based on the authentication result, the user is deemed authenticated or not.

Figure 2 - Two Factor Authentication using Azure Sphere

Conclusion

Although Azure Sphere is quite powerful and versatile, we have seen how we can leverage Azure Sphere and Azure IoT hub to provide the second factor authentication for a two-factor authentication system. There are other systems that can be build on top of the design that is presented here. If we look further, we can connect another device with Azure Sphere device that provide other uses. For example, we can provide a display to show the security code that is generated by the Azure Sphere device that can be entered into an interface provider by the authenticator.

In my next blog post, I have taken provided technical details on how Two-Factor authentication is implemented using Azure Sphere and Azure IoT hub. The details are provider at: Two-Factor authentication with Azure sphere and Azure IoT hub - Step by step

Comments are welcome.

Leveraging Built-in endpoints in Azure IoT Hub

Introduction

One of the great features of IoT hub is its built-in systems endpoints. This allows us to quickly hook into event hub belonging to an IoT hub without the need to an EventHub, Azure Storage containers, Service Bus queues and Service Bus topics.

In this post, we are going to look into how to easily we can leverage the built-in endpoints in Azure IoT hub by creating a simple application using Azure Functions.

When you have an Azure IoT hub and want to hook into events generated by Azure IoT hub, you have two main choices.

1. Events provided as part of Azure Event Grid
Using Azure Event Grid we can use resources such as Logic Apps, Azure Functions, Web Hook, Storage Queues, Event Hubs, and Hybrid Connections.

2. Built-in endpoints

This is the built in endpoint that every Azure IoT hub offers as part of its infrastructure. Using Built-in endpoints we can hook into system and device messages. So when a device sends a message to Azure IoT hub, this "Built-in endpoints" to receive those messages.

Figure 1 - Built-in endpoints view

Using Built-in endpoints

To use built-in endpoints, we will create a custom Azure functions that uses the built-in endpoint to listen to messages emitted by the device to Azure IoT hub. We will  use the following steps to accomplish that.

Step 1- Get Event Hub-compatible endpoint

1. Open the Azure portal and navigate to Azure IoT hub. 
2. Click "Built-in endpoints" in the navigation pane. This will show a view that is similar to view show in Figure 1.
3. Copy "Event Hub-compatible endpoint" and save it to be used in the Azure Function app that is mentioned in Step 2.

Step 2 - Creating Azure Function App

1. Using the boiler plate project that is created when Azure Function App is selected, we can modify the code  as shown below.

Figure 2 - Azure function code

2. Update connection string:

Using the connection string saved in Step 1, update the local.settings.json as shown below:

Figure 3 - Event hub connection string using Built-in endpoint

3. Managing dependencies:

In order to use the Event Hub triggers, we have to add the following NuGet packages:

Figure 4 - Dependencies

Conclusion

We have seen how easy it is to use Built-in endpoints to hook into  Azure IoT hub events. Although we have used Azure Functions app to demonstrate the application that is listening to Azure IoT events using Built-In endpoints, we can use any application platform that can be invoked using EventHubTrigger.

Getting started with Azure Sphere

Azure Sphere - MT 3620 on my work desk

Note: This is first of a series of blog posts that are related to my work done on Azure Sphere. Stay tuned for more on Azure Sphere.

Introduction

One of the best to learn a new technology is to just get hands dirty start work on the new technology. In this blog,  I will take you through the steps that I carried out in order to start work on Azure Sphere.

Once you have received the Azure Sphere device, it's time to get started. Here is the link https://azure.microsoft.com/en-us/services/azure-sphere/get-started/that will take you through the steps of acquiring a Azure Sphere device.

1. The very step is to attached the device with your development machine. If you have the correct operating system then the device manager should automatically install the drivers. In my case the drivers for the device did not install automatically so I had to go to a special page that allowed me to download the drivers. Visit http://www.ftdichip.com/Drivers/VCP.htm to download the driver. The following image shows the driver that I downloaded for my development machine:

2. Once you downloaded and install the drivers, your device manager should look like as the following image.

Notice the three USB Serial Ports (in my case I got COM 4, COM 6 and COM 7)


3. Download Install Azure Sphere SDK for Visual Studio Preview.

4. The Azure Sphere SDK for Visual Studio Preview would install the Azure Sphere Developer Command Prompt Preview. This command line utility is your bridge between the Azure Sphere device and your development effort.

5. Run azsphere login command on  "Azure Sphere Developer Command Prompt Preview" to ensure you can Azure Sphere SDK has been properly installed and you can access your subscription.

6. Creating a Tenant
azsphere tenant create --name mytenant

0000000-xxxx-xxxx-xxxxx-xxxxxxxxxx mytenant

7. Claiming the device

azsphere device claim

Claiming device.

Successfully claimed device ID 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' into tenant 'afrinish' with ID '0000000-xxxx-xxxx-xxxxx-xxxxxxxxxx'.

Command completed successfully in 00:00:03.3873192.

8. Configure Wi-Fi

azsphere device wifi add --ssid [[yourSSID]] --key [[yourNetworkKey]]

Running the command would yield the following output.

Add network succeeded:

ID                  : 0

SSID                : XXXXXXXXXX

Configuration state : enabled

Connection state    : unknown

Security state      : psk

Command completed successfully in 00:00:02.0253617.

Conclusion

In this blogpost, we have gone through the steps of getting started with Azure Sphere. We started off by acquiring the device, installing necessary software and drivers, configuring the device and connecting it the Wi-Fi. If there any any issues, please use the comments section to ask questions.

The next step would be to start developing. Happy coding!

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.