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, being more flexible and more standardized a new model called the 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 Azure Resource Manager 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 part 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 like a VM, a Network Interface Card, a storage account, 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 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, what 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 resource 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 at. One region consists of at least one highly available data center or data center complex.
The (at the time of writing) 34 regions are distributed all over the world and include community clouds like Azure Germany or government clouds like US Gov Virginia. Additionally, to the implicit high availability inside a region and a data center, it’s possible to select a region and creation of most resources. This region represents a set of data centers that are connected through Microsoft owned high-speed network to replicate the data in near real-time between the specific data centers.
Regions can also have an impact on the performance and availability of some resources. Some services may be not or 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 which legal requirements must be met. This could, for example, result in a deployment only in EU regions or even regions in specific countries.
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 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 to any rapid deployment plans.
As Azure uses very much 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 the Azure PowerShell and the Azure Command-Line Interface (CLI).
Both are basically just wrappers around the Azure API to enable everyone not familiar with REST APIs, but their specific scripting language to use and automate Azure.The Azure PowerShell module provides cmdlets for managing Azure services and resources through the Azure API. Azure PowerShell cmdlets are used to handle Account management and Environment management like creating, updating and deleting resources.
These cmdlets work completely the same on Azure, Azure Pack and Azure stack, Microsoft's private cloud offerings.
Azure PowerShell open source and maintained by Microsoft. The project is available on GitHub at the following link:https://github.com/Azure/azure-powershellThe 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 like 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 a so-called Azure SDK for numerous programming languages (for example, .NET, Java, Node.js) here:
https://github.com/Azure