This blog entry is the third in a series regarding virtual machines within Microsoft’s Azure Infrastructure-as-a-Service (IaaS) platform. This entry will focus on understanding the perquisites to virtual machines.
With naming squared away, one might think the best way to dive into Azure is to start with virtual machines. After spending years explaining Azure to a host of audiences, I have found that this is not the case.
The reason is simple: to talk about a VM, we should understand all the prerequisites before a VM can be created. Spoiler alert, there are quite a few prerequisites to understand, so be patient.
Azure Subscriptions:
Before we do anything, we should understand where the Microsoft costs will arise.
You may hear the term tenant thrown around, however there is no such thing as an Azure IaaS tenant. Any reference to an Azure tenant would be referring to an Azure Active Directory tenant, a separate concept from Azure IaaS, but it does interact with IaaS in that it provides the basis for identities for accounts in Azure. We will discuss this more when we get to security.
To deploy any Azure IaaS resources, you will need an Azure IaaS subscription. A subscription is an agreement with Microsoft that states you are going to pay for the consumption-based resources that you deploy. There is no cost for an Azure subscription. You can have a subscription and not deploy any resources and get charged nothing. Only once you start deploying resources will you see the bill start to go up.
You can sign up with a credit card on a “Pay as you go” subscription, but while I like getting bonus miles as much as anyone, this isn’t the most efficient way to do things. While the direct Microsoft support is available to you regardless of purchase method, you will likely get better support going through a Cloud Service Provider (CSP). A CSP can still provide you with support from Microsoft and can usually provide you with consulting services for design, planning, and deployment assistance. If you are going to Microsoft directly, you will be on your own for that. When you work with a CSP, your bill will come from the CSP as they are billed by Microsoft.
You can also work through an enterprise agreement with Microsoft in which you are essentially buying “credits”. You can see some cost savings here; however you will be paying up front for a minimum of three years of anticipated consumption.
An organization can have any number of Azure subscriptions. A large company may have a subscription for each of their development teams, one for their manufacturing division, one for the corporate infrastructure, etc. The resources in these subscriptions are completely separate and distinct and generate their own bills. Generally, law firms are small enough in size to require only a single subscription.
Azure Geographies and Regions:
Azure is a global solution. It is currently commercially available in 142 countries from Afghanistan to Zimbabwe. Those countries are divided into 31 distinct “geographies” each of which will contain one or more “regions” which will contain multiple “datacenters”.
A geography is a boundary where all contained regions are subject to the same laws surrounding data residency and governance. A simple example is the United States geography. Any object created in the United States geography would be subject to the privacy laws created and enforced by the United States federal government. Considering that data privacy laws, compliance regulations, and other laws can vary significantly by country, the selection of a region can be a critical decision. For example, an organization with a European presence may not want its data subject to the Patriot Act, in which case, selecting a region in a European geography would almost certainly be preferable.
Within a given geography there will exist one or more regions that define more specifically where your resources exist. Using the US again as an example, there are 8 regions within the US (Central US, East US, East US 2, North Central US, South Central US, West Central US, West US, West US 2) with a 9th region (West US 3) coming online soon. Each of these regions are made up of multiple datacenters. For example, the datacenters for the East US region are located in Virginia while the datacenters for the Central US region are in Iowa.
Each region is paired with a “partner region”. These pairings come into play when talking about certain features that have built in redundancy. When we talk about “globally redundant” storage, this means that the data is replicated outside of the region to the partner region. East US is paired with West US, meaning that globally redundant storage in East US will exist in Virginia, with data replicated to West US in California. All regions are paired with a region in the same geography, with the exception of Brazil, which pairs with the South Central US region (note that this is a one way pairing from Brazil. The South Central US region pairs with North Central US).
Selecting a geography is NOT a technical decision that IT should be making on its own. The compliance and data residency concerns are such that they should be handled by someone who understands the legal ramifications of these issues.
Selecting a region IS a technical decision, and an important one at that. The first thing to consider is where your user base is. If you are in New York, latency is likely to be lower to Virginia than to California. Another thing to consider is that regions are not all created equally. New features do not roll out across all regions simultaneously and resource pricing may differ from one region to another. Most resources can be moved to another region, but this is a somewhat complex maintenance task so a region should be chosen carefully when initially deploying resources.
In the next entry in this series, we will start to look at laying the groundwork for an Azure infrastructure.
To continue to the conversation with our team, please get in touch.
