Building A Hybrid Cloud With Azure

July 07, 2020 by Corbin Swagerty
In this day and age who would bother developing solutions on anything but the public cloud? The answer: more people than you would think. Many companies provide essential services to a loyal customer base but have not invested in moving their infrastructure to the cloud. Why is this?

In many cases, companies achieved early success with applications running on-premise or in a data center, which naturally led to costly investment into incremental improvements and maintenance. Often, this sunk cost and perceived risk of moving solutions to the cloud may not seem worth the rewards that come with building a cloud infrastructure such as cost-savings, scalability, and developer productivity. However, companies do not have to make a massive upfront investment to move their infrastructure to the cloud. Cloud resources can be built gradually alongside the existing legacy system, and services can be moved to the cloud as dictated by business needs. This is called a hybrid cloud.


What is a Hybrid Cloud?

A hybrid cloud combines resources built on a cloud provider such as Microsoft Azure, with resources running on an internal network. According to Microsoft “Hybrid cloud computing is a ‘best of all possible worlds’ platform, delivering all the benefits of cloud computing — flexibility, scalability, and cost efficiencies — with the lowest possible risk of data exposure.” In practical terms, a hybrid cloud allows you to build new applications on the cloud while leveraging on-premise data and services that have made the business successful up to that point. These services developed on the cloud can more easily incorporate DevOps best practices such as Continuous Integration/Deployment and Infrastructure as Code which often relies on access to cloud services. This all seems vague…because it is. Let’s see an example.


An Automotive Sales Company

Let’s take a look at a hypothetical company that sells cars. This particular company relies on servers running on-premise on an internal network to provide their salespeople with information about the cars in their inventory. The system works brilliantly for the steady amount of salespeople who access the system. But what if the business wants to begin selling their cars on a public-facing website? The on-premise servers may not have the capacity to handle the spike in traffic, leaving you with a decision: invest in additional, expensive on-prem hardware or begin developing the new website on the cloud.

Even if you decide to develop this new website on the cloud, you still run into a fundamental problem. How do you access the car inventory data to display on the website? Also, how would you interact with other systems running on the company’s internal network? A hybrid cloud architecture shines in this exact scenario.


Creating a Hybrid Cloud Architecture

Let’s assume you’re developing your car website with a standard 3-tier architecture:

A standard 3-tier architecture for our car website
A standard 3-tier architecture for our car website

The website user requests a page from a web server that displays a list of cars. On Azure, this could be an application running on App Services or even an Azure Storage instance that serves static files. In order to display car data, the web server would make a request to the application server, which could also be an application running on App Services. When the application server receives a request for car data, it queries the cloud database and returns the results.


Creating a Virtual Network

Despite our efforts, the car data we need is still located on-premise and cannot be accessed by our cloud application. The simple, but risky solution is to expose resources on the internal network via port forwarding and access them directly. A more secure option is to create an Azure Virtual Network that will house our Azure resources, then connect this network to our internal network. Here is our updated architecture after creating the Azure Virtual Network and connecting the application server:

System architecture after creating our Azure Virtual Network
System architecture after creating our Azure Virtual Network

Connecting the Networks

A simple, secure way to connect our two networks together is via Site-to-Site VPN. A Site-to-Site (S2S) connection uses a VPN tunnel to securely transfer data between networks. Under the hood, the VPN tunnel embeds packets within other packets to ensure that only the desired recipient can access its contents. Note that an on-prem VPN device with a public IP is required for this type of connection. We must then create a VPN Gateway in our Azure Virtual Network and configure our on-prem VPN device to connect to this gateway. More details can be found in this article. Once this connection is complete we can access on-premise car inventory data from any Azure resource connected to the virtual network.

System architecture after connecting Azure VNet to an internal network
System architecture after connecting Azure VNet to an internal network

Handling Spikes in Traffic

The application server can now access car inventory data from the on-prem database and display it on the website. But what if our on-prem database cannot handle the spikes in traffic during peak website hours? One solution is to create a service on our Azure Virtual Network that performs a periodic ETL (Extract, Translate, Load) job that extracts data from our the on-premise database and loads it into a cloud database:

System architecture after adding cloud database and ETL job
System architecture after adding cloud database and ETL job

Now if our application server receives an influx of requests, this load is handled entirely by cloud resources. Isolating this problem to the cloud opens up a variety of solutions including scaling up the cloud database to a higher tier or adding an Azure Cache for Redis. Also, our interaction with the on-prem database is restricted to the ETL service, thereby isolating any database retry logic or job scheduling considerations. Now our application server can simply focus on pulling car inventory data from our cloud database.


Addressing Security with the Hybrid Cloud

By connecting to the hybrid cloud via an Azure Virtual Network, we have now enabled many security improvements. First of all, we have avoided publicly exposing resources on the internal network that may not have been designed with that consideration in mind. Secondly, we can now utilize Azure’s many security features including Azure Firewall, role-based access control (RBAC), Front Door DDOS protection, and KeyVault secret storage. Best of all, these features can be added virtually without the need for additional hardware or manual installations.


Based on a True Story

Although the car dealership is fictional, it is inspired by actual problems that Callibrity solves for clients whose business previously depended upon on-premise resources. We’ve utilized this architecture for a company in the healthcare industry that allowed their website to handle a prolonged spike in traffic due to COVID-19 with ease that previously would have caused their business to grind to a halt. A hybrid cloud can promote the development of ambitious, cloud-based applications and enable a gradual low-risk migration of essential services to a cloud infrastructure.

Corbin Swagerty
Corbin Swagerty Corbin is a JavaScript specialist with full-stack experience. His obsession: writing high-quality, maintainable code. Corbin has a B.S. in Electrical Engineering and over 7 years of professional software experience ranging from startups to Fortune 500 companies. In his free time, Corbin enjoys writing and recording music in his home studio.