Deploying a SaaS Application in Azure (Networking)
If there is one thing that is absolutely true about deploying an application within “The Cloud” like Azure, it is that there are so many great services that no one person can be an expert in all of them. Taking that sentiment, how does one plan, design, and then eventually deploy a SaaS application within Azure when it could include as many as 20+ different services that Azure provides? This type of deployment with its many complexities may require one person that understands the networking architecture at a deep level, someone that understands the application deployment at a deep level and then another to understand monitoring and continued operations.
So with that, I thought that it would be good to try and understand how such a deployment would come together and have it be available all in one place. Over the next few months, I would like to walk through a series of posts that can be used by other architects out there on how you might go about deploying such an application within Azure. There are many possible ways and I will try to at the very least to talk about all of them and where I can, provide demonstrations or examples of each one.
Use Case - Harrison Hotel Management
The Harrison Hotel Management application is a SaaS based solution that needs to be deployed into Azure so that it can be used by small to medium sized hotels and their customers around the world. This application will provide the capabilities for customer reservations, hotel service management, and of course payment and billing management. The application has already been developed and is ready for deployment. We just need to figure out the best way for it to be deployed so that it is elastic, scalable, and completely redundant & resilient. Of course, we will also need to be able to monitor both the architecture and the application to understand how it is being used and do a troubleshooting should a problem arise.
NOTE: Developing such an application for Azure also has a large set of requirements and possibilities and as such the development of the application would need to be a completely separate series of blog posts. Maybe we will look at that in the future.
Deployment Steps
Over the next several months, I will be putting together a blog post for each step that would correspond to a piece of the deployment for a multi-national SaaS application that will be deployed within Azure. Here are those proposed steps:
Lab 1 - Regional Network
Lab 2 - Data Tier (SQL Server or MariaDB)
Lab 3 - API and Worker Tier (Queue Service)
Lab 4 - Web Tier
Lab 5 - Active Directory Integration
Lab 6 - Global Redundancy and Elasticity
Lab 7 - Monitoring
Lab 8 - Automation and DevOps
Lab 9 - Data Tier Part 2 (Azure Search & Redis Cache)
Due to the fact that all of these labs are using the same Use Case application, they will each build on top of one another. This means that instead of creating all new scripts from scratch each time, we will be updating the existing scripts that we create in the first few Labs.
Deployment Methods
As I am sure you are aware, even within each of these steps, there are up to five different ways that each one of them can be accomplished within Azure:
- Portal UI
- PowerShell
- Cross-Platform CLI
- Azure SDK
- Azure Resource Manager (ARM)
NOTE: There are going to be certain Labs that cannot be completed using just one of the methods above. I will of course make sure to call this out and try to provide an explanation where possible.
Considering the number of different deployment options, there will be no way that I will be able to cover all of the available deployment methods or provide demonstrations of each of them. I can however provide as much useful information as possible. To that end, I will be deploying each Lab within three different regional data centers of Azure and in each one, I will be performing the required tasks using a different deployment method, but only showing the Portal UI demonstration within the Blog post. However, at the end of each post, I will provide links to any scripts that I may have created using the other tools through a GitHub repository.
Why Method A vs. Method B?
This is a great question and one that should definitely be understood before you make a decision which one works the best for you. Be aware that you may have to use multiple methods throughout the entire deployment.
Portal UI - First of all, for most services, the Portal UI is a great way to do single deployments of a service, because not only do you get the service deployed in a very visual way, but it is also a great way to learn what all of the available settings and properties are. However, this is not the most efficient way to deploy multiple versions of the same service.
PowerShell, SDK, & XPLAT CLI - I am lumping all three of these together, because they encompass the programmatic ways that someone would script or develop an automated way of deploying multiple services and multiple versions of the same service. Using either of these three methods will give you the most control over the entire environment and they are fully functional across almost all services within Azure.
Azure Resource Manager (ARM) - This is the newest of the deployment methods and is therefore not fully featured with respect to all available services within Azure. The one big advantage that it has over any of the other methods, is that it lends itself very well to the DevOps method of maintaining your different environments. You build a JSON based template of your architecture, you then deploy that into an environment and lastly version control the template. If you need to make a change, you create a new version of the template and then re-deploy. This will only make the modifications that you made to the template without affecting any of the existing pieces of the architecture. More information can be found in the Reference links at the bottom of the post.
Lab 1 - Networking
Now that we have a good overview of what we will be accomplishing and how, let’s get started with this deployment by focusing on the regional networking architecture. In this Lab we will just be building out the base Virtual Networks to support the primary tiers of our application. We will not be putting any security in place until we are sure what routes and traffic flows we want to allow and deny. This means that we will be focusing on the Virtual Networks and corresponding Subnets for each of the regions and then add in Network Security Groups in later Labs.
INFO: You may notice when looking around within the Portal that there are two different versions of certain services such as Virtual Networks, Virtual Machines, Storage Accounts, etc. These are available and can be deployed using Azure Resource Manager, but they are still in Preview and not available within all regions. There will definitely be some advantages to using the new versions when they are available, such as Tagging and more Granular Role Based Access Controls. However, for the purposes of these Labs, we will be strictly using V1 of the different services. Should the services become generally available in the middle of this process, I may decide to retrofit all of the scripts and process to work with the newer versions.
Let’s get started:
1.) Click New Button -> Networking -> Virtual Network
2.) Enter information for your virtual network and initial Subnet (Web Tier) setting the VNet IP range and Subnet IP range using standard CIDR notation.
NOTE: Please notice that in addition to creating a new Virtual Network and Default Subnet, I am also creating a new Resource Group. Resource Groups are a way to organize your resources into logical groupings that make sense to you and the people that need to manage them. For more information about Resource Groups, please see the first reference link at the bottom of the post.
3.) Click on the Subnets Blade within the new Virtual Network screen and then Click Add Subnet button
4.) Enter information for new Subnets to correspond to remaining needed tiers. (API, Data, and Management Tiers)
Deploying to Other Regions
Walking through the steps above got you one Virtual Network in one region, however for a SaaS application like Harrison Hotel Management, we will need to make this deployment work in numerous regions around the globe all of them with similar architectures. So how would we do that using some of the other deployment methods? When it comes to V1 networking in Azure, there are really only two possibilities for full deployment: Network Config documents and ARM templates.
TIP: Before deploying into other regions, make sure that each network configuration does not have overlapping IP ranges, otherwise you will have definite problems trying to connect them through VNet gateways later on.
Network Config
The Network Config document is a XML based representation of all network based resources that are currently within your defined subscription. This document can be retrieved through PowerShell, CLI, SDK, or the current Portal UI. Once you make a change to it and then import it, Azure will take care of making any necessary modifications. This is very similar to the way that ARM templates are used, but this is only done for networking resources.
NOTE: Please be aware that both the Portal and the PowerShell command will produce a XML based Network Config document, where as the CLI command will produce a JSON based document.
Once you download the file, the XML should look like the following, assuming that you started with a clean Azure subscription, otherwise there may be other networking resources listed:
<NetworkConfiguration xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi=https://www.w3.org/2001/XMLSchemainstance
xmlns="https://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
<VirtualNetworkConfiguration>
<Dns />
<VirtualNetworkSites>
<VirtualNetworkSite name="Group HotelMgmt Vnet-HarrisonHotel-ProdEast" Location="East US">
<AddressSpace>
<AddressPrefix>10.1.0.0/16</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-Web">
<AddressPrefix>10.1.1.0/24</AddressPrefix>
</Subnet>
<Subnet name="Subnet-Api">
<AddressPrefix>10.1.2.0/24</AddressPrefix>
</Subnet>
<Subnet name="Subnet-Data">
<AddressPrefix>10.1.3.0/24</AddressPrefix>
</Subnet>
<Subnet name="Subnet-Shared">
<AddressPrefix>10.1.4.0/24</AddressPrefix>
</Subnet>
</Subnets>
</VirtualNetworkSite>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>
To add new Virtual Networks and corresponding Subnets within different regions, all that you really need to do is to copy and paste the entire VirtualNetworkSite tree of the one we just created and do that for each region that you plan to use. You will of course need to make sure that you use new IP address ranges as I mentioned in my Tip above. The final version of my document can be found in the GitHub repository: https://github.com/azuresaas-deploy/Lab 1 - Network.
Once you have finished modifying the config file, you will need to import it back into your subscription either using the correct CLI, PS or UI functionality.
ARM Template
As I described earlier, an ARM template is nothing more than a JSON document that describes one or more resources that are part of a single Resource Group. If you will remember, I created the first VNet within a Resource Group called HotelMgmt. Using the Azure Resource Explorer tool, you should be able to find the JSON notation for that VNet that you just created. That JSON notation can then be used either within Visual Studio Online or Visual Studio 2013 to produce a larger template that is made up of multiple VNets in different regions, each with their own four subnets. Then that template can be added to over time as we add in more and more resources to the Resource Group and complete the overall deployment.
Instead of just providing a finished JSON template, I have instead provided you with a full Visual Studio project that you can import. Over time, I will add to the JSON template to include each new set of resources as we deploy them and I will do it all within one template, but there is no reason why you couldn’t create a nested deployment where there is a template for each required region. https://github.com/azuresaas-deploy/HotelMgmtRG/.
References
INFO: Azure Resource Manager Overview
HOWTO: Configure a Virtual Network using a Network Configuration File
INFO: Network Configuration Schema
HOWTO: Author Resource Group Template
HOWTO: Deploy an Application with Azure Resource Manager Template
In the next lab we will focus on the data tier and specifically the deployment of a SQL based deployment using either IaaS services with MariaDB or the SQL Azure Service.