In the following section, we will take a look at the basic Microsoft Azure key concepts. This should provide an overview and an idea of how to use Azure.
In the previous major version of Azure, a deployment backend model called Azure Service Manager (ASM) was used. With higher demand on scaling, and being more flexible and standardized, a new model called ARM was introduced and is now the standard way of using Azure.
This includes a new portal, a new way of looking at things as resources, and a standardized API that every tool, including the Azure portal, that interacts with Azure uses.
With this API and architectural changes, it's possible to use such things as ARM templates for any size of deployment. ARM templates are written in JavaScript Object Notation (JSON) and are a convenient way to define one or more resources and their relationship to another programmatically. This structure is then deployed to a resource group. With this deployment model, it's possible to define dependencies between resources, as well as being able to deploy the exact same architecture again and again. The next section will dive a little deeper into resources.
Azure resources are the key to every service offering in Azure. Resources are the smallest building blocks and represent a single technical entity, such as a VM, a network interface card, a storage account, a database, or a website. When deploying a web app, a resource called app service will be deployed along with a service plan for billing.
When deploying a virtual machine from an Azure Marketplace template, a VM resource will be created as well as a storage account resource holding the virtual hard disks, a public IP Address resource for initial access to the VM, a network interface card, and a virtual network resource.
Every resource has to be deployed to one specific resource group. A resource group can hold multiple resources, while a single resource can only exist in one resource group. Resource groups also can't contain another resource group, which leads to a single layer of containers regarding resources.
One resource group can contain all resources of a deployment or multiple resources of different deployments. There are no strong recommendations on structuring resource groups, but it's recommended to organize either the resources of one project/enrollment/deployment in separate resource groups or distribute resources based on their purpose (networking, storage, and so on) to resource groups.
Azure as a global cloud platform provides multiple regions to deploy resources to. One region consists of at least one highly available data center or data center complex. At the time of writing, 54 regions are distributed all over the world and include community clouds, so-called sovereign regions.
Microsoft also divides its regions into geopolitical zones, which can be found at the following URL: https://azure.microsoft.com/en-us/global-infrastructure/regions/.
These sovereign clouds where built by Microsoft to fit customer or governmental needs, such as for special compliance and/or data privacy laws. At the moment, the following sovereign clouds are available:
- Microsoft Azure US Department of Defense (DoD)
- Microsoft Azure US Government
- Microsoft Azure China
- Microsoft Cloud Germany
Microsoft Cloud Germany is also special among the sovereign clouds. Because of customer demands, Microsoft built up Microsoft Cloud Germany differently. Microsoft does not operate the cloud in Germany itself; they use a data trustee to operate the cloud for them.
Microsoft Azure staff and all Microsoft employees are not allowed to enter the data centers or lay hands on the servers or framework. Everything is operated by the trustee, starting with hardware maintenance up to updates of the framework.
Note
Fun fact: Before Microsoft moved into its data center in Berlin, I used to be allowed to walk straight through the data center with a guide to reach my peer, who is a regional director of the data center provider. Since Microsoft moved into the data center, I can no longer use the shortcut and need to walk around the outside of the building to reach the office of my buddy. So, Microsoft is very serious with their policies.
Regions can also have an impact on the performance and availability of some resources. Some services may not be, or are only partially, available in a specific region.
The costs of offered services also vary by region. For reduced latency, it's recommended to choose a region next to the physical location of the consumer. It might also be important to see which legal requirements must be met. This could, for example, result in a deployment only in EU regions, or even regions in specific countries:
- Available Azure regions: https://azure.microsoft.com/en-us/regions/
- Lists all the services available in specific regions: https://azure.microsoft.com/en-us/regions/services/
Microsoft operates two types of following data centers:
- The first type is the production data center, where Microsoft calculates all workloads of its customers and stores all the data.
- The second type is the edge or delivery site. Those sites connect all Microsoft Cloud services to the internet and Microsoft's customers. Edge sites come in two stages of expansion. The smallest one allows Microsoft public direct peering through the internet. With the second stage of expansion, Microsoft allows customers and providers to establish a private connection to the Microsoft backbone using the Microsoft Azure ExpressRoute service.
The following diagram shows a schematic of the Microsoft data center structure:
Edge and production sites are connected through the Microsoft backbone. Currently Microsoft owns and operates the second largest and fastest full meshed provider backbone of the world.. Microsoft also owns and operates own see cables such as the MAREA cable from Bilbao (Spain) to Virginia (US).
This map shows the current Microsoft Azure backbone with the new MAREA cable:
Note
Fun fact: What was the hardest thing for the Microsoft backbone teams when building the MAREA cable? To create and get the purchase order for the submarine approved because of Microsoft processes.
While building its backbone, Microsoft acts differently to the other cloud providers. Microsoft builds its own dark fibre cables or leases dark fibre cables and operates the whole backbone itself. Microsoft runs a fully software-defined network and infrastructure for its backbone, using firewall appliances built for network function virtualization.
If you ever have the chance to see a server rack that connects the Microsoft backbone or represents a Microsoft Edge site, it will probably look like this:
If you want to know more about Microsoft regarding data center equipment and software defined, I highly recommend you consult open source and open compute projects. Microsoft is investing highly in these and is very open in the following projects:
- Microsoft cloud servers:
- Open cloud server platform: https://www.opencompute.org/projects/server
- ARM-based cloud server project olympus: https://www.opencompute.org/wiki/Server/ProjectOlympus
- Microsoft network cards for backbone and cloud services:
- Smart NIC: https://www.opencompute.org/wiki/Server/Mezz
- Microsoft networking and switch software:
Note
Microsoft also makes heavy use of Field Programmable Gateway Arrays (FPGAs), to make Azure as flexible as possible and adjust the hardware layer as much as possible to the needs of their workloads. If you really want to become an insider in this technology, I would high recommend the session, Inside Microsoft's FPGA-Based Configurable Cloud, by Mark Russinovich, CTO of Azure. You can find the session here: https://www.youtube.com/watch?v=v_4Ap1bjwgs.
The Azure portal is a web application and the most straightforward way to view and manage most Azure resources. The Azure portal can also be used for identity management, to view billing information, and to create custom dashboards for often used resources to get a quick overview of some deployments.
Although it's easy to start with using and deploying services and resources, it's highly recommended to use some Azure automation technologies for larger and production environments. The Azure portal is located at https://portal.azure.com.
Azure automation is a service and a resource, as well as an Azure concept in the context of cloud computing.
It's very important to see automation as an essential concept when it comes to cloud computing. Automation is one of the key technologies to reduce operational costs and will also provide a consistent and replicable state. It also lays the foundation of any rapid deployment plans.
As Azure uses a lot of automation internally, Microsoft decided to make some of that technology available as a resource called automation account.
Azure provides several ways of interacting and automating things. The two main ways to interact with Azure besides the portal are Azure PowerShell and the Azure Command-Line Interface (CLI).
Both are basically just wrappers around the Azure API to enable everyone not familiar with RESTful APIs, but familiar with their specific scripting language, to use and automate Azure. The Azure PowerShell module provides cmdlet for managing Azure services and resources through the Azure API. Azure PowerShell cmdlet are used to handle account management and environment management, including creating, updating, and deleting resources. These cmdlet work completely the same on Azure, Azure Pack, and the Azure Stack, Microsoft's private cloud offerings.
Azure PowerShell is open source and maintained by Microsoft. The project is available on GitHub at the following link: https://github.com/Azure/azure-powershell. The Azure CLI is a tool that you can use to create, manage, and remove Azure resources from the command-line. The Azure CLI was created for administrators and operators that are not that experienced with Microsoft technologies, but with other server technologies, such as Unix or Linux. The Azure CLI is an open source project as well, and is available for Linux, macOS, and Windows here: https://github.com/Azure/azure-cli.
All Azure services, including the Azure Management Portal, provide their own REST APIs for their functionality. They can, therefore, be accessed by any application that RESTful services can process.
In order for software developers to write applications in the programming language of their choice, Microsoft offers wrapper classes for the REST APIs.
These are available as an Azure SDK for numerous programming languages (for example, .NET, Java, and Node.js) here at https://github.com/Azure.