The book "Fundamentals of Microsoft Azure"

    This book provides the most important information about key services of the Azure platform for developers and IT professionals with no experience with cloud technologies. Provides detailed step by step instructions that will help the reader learn the basics of working with all important services.

    The material will be useful not only for beginners to learn Azure, but also for professionals who need to restore the material in memory, as well as for people who are familiar with only some of the topics covered. The chapters of the book are independent: to understand the contents of any chapter, it is not necessary to study the examples from the previous chapters.

    Today we publish part of the first chapter of this book. You can download the full version for free at the link .

    Table of contents

    • Introducing Azure - 1;
    • Azure App Service and Web Apps - 32;
    • Virtual Machines - 70;
    • Storage Service - 101;
    • Azure virtual networks - 133;
    • Databases - 157;
    • Azure Active Directory - 181;
    • Controls - 206;
    • Additional services Azure - 231;
    • Usage scenarios - 238.

    Discover Azure

    What is Azure?

    Azure is a Microsoft cloud platform.

    Cloud Technologies - General Information

    Cloud technologies are a modern alternative to familiar local data centers. All tasks for the purchase and maintenance of equipment are entirely the responsibility of the public cloud service provider. It provides customers with access to various platform services. Customers rent hardware and software resources that they only need from time to time. So they convert the capital costs of purchasing equipment into operating costs. In addition, this approach allows customers to rent access to hardware and software resources, the purchase of which would be too expensive. Only those devices that the cloud platform provider offers are available to customers, but they only pay as they are used.

    Web portals are used to manage cloud environments (their computing resources, storage, networks and applications). For example, a user can create a virtual machine (VM) configuration in the Azure portal, which will define the following characteristics: virtual machine configuration (processor, RAM, and local disks), operating system, pre-deployed software, network configuration, and virtual machine location. After that, the user can deploy a virtual machine based on this configuration and start working with it in a few minutes. Previously, it would be necessary to deploy a physical machine, the purchase of which alone could take several weeks, so the possibility of rapid deployment looks very attractive.

    We talked about public clouds. There are private and hybrid clouds. A private cloud is a cloud environment that is created in the company's own data processing center, and users (employees of the company) are provided with tools for independent use of its resources. Users work with such an environment in almost the same way as with a public cloud, but all the tasks of purchasing and maintaining equipment, choosing hardware and software resources are entirely the responsibility of the company. A hybrid cloud is an environment that combines a public and private cloud. This approach allows you to choose the most appropriate placement option for workloads. For example, if the load on a website varies widely,

    Microsoft solutions support public, private and hybrid clouds. The Microsoft Azure platform to which this book is dedicated is a public cloud. Microsoft Azure Stack is an extension for Windows Server 2016 that allows you to deploy many of the basic Azure services in a local data center and provide users with a self-service portal. These components can be integrated with a hybrid cloud through a virtual private network (VPN).

    Local Environment and Azure - Comparison

    When using local infrastructure, the hardware and software components that you deploy are completely under your control. Therefore, in the past, when purchasing equipment, they usually sought to scale up (that is, they tried to acquire a server with a large number of cores to ensure the required performance). If you are using Azure, you can use only those devices that Microsoft offers. In this case, horizontal scaling is used to improve performance: you simply deploy additional compute nodes. This feature has to be taken into account when designing the architecture of software systems, however, as practice has shown, horizontal scaling (deployment of low-cost devices) is much more cost-effective,

    At the time of this writing, Microsoft Azure data centers are open in more than 22 regions of the world: from Melbourne to Amsterdam, from São Paulo to Singapore. In addition, Microsoft has entered into an agreement with 21Vianet, and now the Azure platform is available in two regions of China. Microsoft has announced the deployment of Azure in eight more regions. Only the largest corporations in the world can open data processing centers on such a scale. Therefore, with the help of Azure, companies of any scale can deploy their services at the concentration sites of their customers in any regions of the Earth. And all this - even without leaving the office!

    Azure allows young companies to start with very small costs and quickly scale infrastructure as new customers emerge. Running one or more new virtual machines does not require large upfront payments. Modern young companies usually scale quickly and quickly learn from their mistakes. The use of cloud technologies is fully consistent with these principles.

    Azure helps you quickly and flexibly launch new development and test environments. You can use scripts to deploy such environments. So you can, if necessary, run the development or testing environment, test and delete it. As a result, the company saves a lot and almost does not spend money on infrastructure support.

    Another advantage of Azure is the ability to test new software versions without replacing local hardware. Suppose you need to know how your application changes when you upgrade from Microsoft SQL Server 2014 to Microsoft SQL Server 2016. To do this, you simply create an instance of SQL Server 2016 and launch a copy of your services, connecting it to a new database - no need to allocate equipment, no pulling wires. Or you can run a virtual machine running Microsoft Windows Server 2012 R2 instead of Microsoft Windows Server 2008 R2.

    Cloud offer

    Cloud services typically fall into one of three categories: SaaS, PaaS, or IaaS. However, with the development of cloud technologies, the boundary between them becomes less and less clear.

    SaaS: software as a service

    Software that is hosted in a centralized environment and managed on behalf of a client is called SaaS (software as a service). Typically, this approach uses a multi-tenant architecture, that is, all clients are provided with an application of the same version. It can be scaled to multiple instances to ensure optimal performance regardless of location. For licensing SaaS, subscriptions with monthly or annual payments are usually used.

    One example of SaaS is Microsoft Office 365. Users pay for a monthly or yearly subscription and get access to several products: Exchange as a service (web client and / or Outlook desktop app), storage service as a service (OneDrive), and other components of Microsoft Office (desktop and (or) web versions). At the same time, subscribers are always provided with the most current version of the product. So you can, in fact, get at your disposal a Microsoft Exchange server without having to buy, install and support it — managing the Exchange server, including installing patches and updates, will be taken by others. This option is much cheaper and easier from a service point of view than installing the Microsoft Office software and updating it annually.

    Other examples of SaaS products include Dropbox, WordPress, and Amazon Kindle.

    PaaS: platform as a service

    As part of the PaaS approach, you deploy your application in a special application hosting environment that is hosted by your cloud service provider. The developer creates the application, and the PaaS provider provides the ability to deploy and run it. As a result, developers do not need to engage in infrastructure maintenance, which means they can devote all their time to development.

    As part of Azure, there are several PaaS offerings that include the “web application” component of the Azure App Service, as well as Azure cloud services (web role and work role). In all cases, there are many ways for developers to deploy an application without having to understand the details of the supporting infrastructure. Developers do not have to either create virtual machines, or connect to them via the Remote Desktop Protocol (RDP), or install an application. They simply click on the button (or perform another equally simple action), and Microsoft’s tools will prepare the virtual machines, deploy and install the application on them.

    IaaS: infrastructure as a service

    The cloud service provider IaaS monitors and maintains server farms that run virtualization software. In these systems, customers create virtual machines that run in the infrastructure of the supplier. The client creates a virtual machine running Windows or Linux (the available options depend on the service provider) and installs everything necessary on it. Azure allows you to configure virtual networks, load balancers, and storage as well as many other services that run in this environment. The client cannot control virtualization devices or software systems, but almost everything else is at its
    disposal. With this approach (unlike PaaS), the software is controlled by the customer.

    Azure Virtual Machines (Azure IaaS Offer) is a very popular tool for migrating services to Azure, because it basically allows you to easily migrate the right solutions. You can create a virtual machine similar to the infrastructure of your data center in which the services are currently running and transfer your applications to it. In some cases, additional actions may be required (for example, changing URLs so that they point to new services or storages), but this approach allows you to move a great many applications.

    Azure Virtual Machine Scalesets (VMSS) based on Azure virtual machines enable you to quickly create a cluster of identical virtual machines. In addition, VMSS supports automatic scaling (automatic deployment of new virtual machines as needed). Thanks to this, VMSS is an ideal platform for hosting higher level microservice computing clusters: for example, for Azure Service Fabric and Azure Container Services.

    Azure Services

    The Azure cloud platform includes many services. Consider some of them.

    • Computing Services. This category includes Azure (running Linux and Windows), cloud services, application services (web apps, mobile apps, Logic Apps, API apps and feature apps), batch service (for large parallel and batch computing tasks). ), RemoteApp, Service Fabric and Azure Container Service.
    • Data services This includes Microsoft Azure storage (which includes blob, queue, table, and Azure file services), SQL Azure database, DocumentDB, StorSimple, and Redis cache.
    • Application Services. This category includes services used to create and run applications, including Azure Active Directory (Azure AD), a service bus for connecting distributed systems, HDInsight for big data processing, an Azure scheduler, and Azure Media Services.
    • Network services. This group includes Azure services such as virtual networks, ExpressRoute, Azure DNS, Azure Traffic Manager, and Azure Content Delivery Network.

    When migrating an application, it is important to understand which services are available as part of Azure, since this knowledge will help simplify the migration of the application and increase its flexibility. It is impossible to tell in detail about all the available services within this book, so we chose some of the most interesting ones. Chapter 9 ("Azure Additional Services") provides a list of these services and a brief explanation of their capabilities.

    New World: Azure Resource Manager

    Azure Resource Manager is a new approach to deploying resources.

    What it is?

    The deployment model using Azure Service Management (Azure Service Management, ASM) has been used to deploy services since the launch of the public evaluation version. Services that are managed by ASM are called classic on the Azure portal. In 2015, Microsoft introduced the deployment model using Azure Resource Manager (a modern and more functional ASM replacement), which is recommended for managing new workloads.

    These deployment modes are often called the “control plane” because they are used not only to deploy services, but also to manage them. Do not confuse them with “data planes” (data plane) - data management tools that are used by the service.

    The infrastructure running in Azure typically contains many resources, some of which are related: for example, running a web application requires component services. Suppose you need two virtual machines on which the web application will run. For data storage will be used a database located in the same virtual network. Resource Manager allows you to deploy all this within a single group of resources, which can be managed as one unit. Deploying, updating, and deleting all resources that belong to the same group is done in a single step.

    In this example, the resource group will contain the following:

    • Virtual Machine 1
    • Virtual Machine 2
    • Virtual network
    • Storage account
    • Azure SQL Database

    In addition, you can create a template with an accurate description of all Resource Manager resources that are related to deployment. After that, it is enough to perform one operation in the control plane (control plane) to deploy this Resource Manager template as a group of resources. In doing so, Azure Resource Manager will ensure that all resources are deployed correctly. In addition, Resource Manager supports various options for working with deployed resources: security, auditing, and tagging.

    What are the benefits of a Resource Manager?

    Using the Resource Manager provides several advantages. It allows you to deploy resources faster, since it performs operations not sequentially (like ASM), but in parallel. The deployment model using Azure Resource Manager allows each service to work with its service provider and, if necessary, update it independently of other services. Azure storage has one service provider, virtual machines another, and so on. When using the ASM model, all services had to be updated at the same time, so if one service finished updating before the others, it would still need to wait for the others before release. Here are some more important advantages of the deployment model using the Azure Resource Manager:

    Ability to deploy using templates

    • You can create a JSON template and reuse it to deploy all the resources for a solution in one go. You no longer need to start creating one virtual machine through the portal, wait for the process to complete, start creating the next one, and so on.
    • You can redeploy the same resource bundle using a template. Suppose you configured resources in a test environment and realized that they did not match your needs. You can delete this resource group (all resources that belong to it will be automatically deleted), change the template and try again. To modify a set of deployed resources, just change the template and re-launch its deployment: Resource Manager will change the resources to match the new template.
    • Using the template, you can quickly create multiple versions of the infrastructure: for example, an intermediate and production environment. Different fields (for example, virtual machine name, network name, storage account, etc.) can be parameterized, and then load the template several times with different parameter values.

    Resource Manager is able to detect dependencies in templates and allows you to specify additional dependencies. For example, deploying a virtual machine before creating a storage account for VHD files that store disks with the operating system and data is a bad idea.


    • To control access to group resources, you can use a new mechanism called Role-Based Access Control (RBAC). For example, you can assign the user the role of "owner", and then he will have full administrator rights with respect to the resources of this group - but not other subscription resources. There are other roles, for example, “reader” (allows you to read everything except secret data) and “participant” (allows you to perform almost any operation, except adding and removing access).


    • To organize all the resources of a group for convenient billing, you can assign tags to each resource and then get data on payments for using resources with a specific tag.

      If, for example, a single department is involved in a web application and several related resources, you can assign one tag to all these resources. After that, you can receive information on payments related to this department by the specified tag.

    Note. Resources in the group do not inherit the tag set for the group as a whole. Tags will need to be assigned to each individual resource.

    Use Resource Manager as efficiently as possible.

    Microsoft has prepared several tips for working effectively with applications and components using the Resource Manager.

    • Instead of PowerShell scripts or the command-line interface (CLI), it is recommended to use templates. Script commands are executed sequentially, and the resources specified in the template can be deployed in parallel, which is much faster.
    • Automate as many operations as possible using templates. You can specify configurations for various extensions, for example, PowerShell DSC and web deployment. Then, when creating and configuring resources, no actions need to be performed manually.
    • Use PowerShell or Azure CLI to manage resources (for example, to start or stop a virtual machine or application).
    • Place resources with the same life cycle into one resource group. Let's go back to the example above. What if the database is used for multiple applications or is it required to continue working even after the application has been disabled or deleted? It is not very convenient to create a database every time you redeploy an application and its components. In this case, you can put the database in a separate group of resources.

    Resource Group Tips

    When dividing resources into groups, be guided by considerations of expediency in a particular situation. A resource group is a logical container that contains related resources for an application or group of applications. When making decisions regarding a group of resources, the following should be considered:

    • As already mentioned, resources with a common life cycle should be placed in one group.
    • A resource cannot be added simultaneously to multiple groups.
    • A resource can be added to a resource group or removed from it at any time. Note: each resource must belong to a group, so when you delete a resource from one group, you must add it to another.
    • Almost any type of resource can be moved to another resource group at any time.
    • Resources that belong to the same group can be located in different regions.
    • The resource group allows you to control access to the resources that belong to it.

    Resource Manager Templates Tips

    Resource Manager templates are essentially instructions for deploying and configuring an application. They are used to redeploy an application and all the resources it requires.

    You can split the deployment into several templates and create a master template that contains links to all other required templates.

    Templates can be changed. Modified templates can be deployed again. For example, you can add a new resource to the template or update the resource configuration data. When you redeploy the Resource Manager template, it creates all the necessary new resources and applies the updated settings. An example of using this feature is discussed in Chapter 5 (“Azure Virtual Networks”) when deploying a two-subnet Vnet template. After that, the third subnet is added and the pattern re-expands, after which the subnet appears on the Azure portal.

    Templates can be parameterized to more flexibly manage the deployment process. Parameterization allows you to reuse the template, but at the same time assigning other values ​​to the parameters, such as virtual machine name, virtual network name, storage account name, region, etc.

    Data on the current state of resources in the resource group can be exported as a template. It can then be used as a layout for other deployments, or modified and redeployed to modify the properties of the current resources in the group.

    Below is an example of a JSON template. When you deploy this template, an account is created with the name “mystorage” in the “West US” region. The template is parameterized; You can create a file with parameters and specify in it the values ​​of the parameters newStorageAccountName (the name of the new storage account) and location (location). If there is no such file, the standard parameters are used.

    "$schema": "", 
    "contentVersion": "", 
    "parameters": { 
    "newStorageAccountName": { 
    "type": "string", 
    "defaultValue": "mystorage", 
    "metadata": { 
    "description": "Уникальное DNS-имя учетной записи хранения, в которой будут размещаться диски виртуальной машины." 
    "location": { 
    "type": "string", "defaultValue": "West US", "allowedValues": [ "West US", "East US" ], 
    "metadata": { 
    "description": "Ограничивает варианты выбора регионами США, в которых доступно хранилище класса Premium." 
    "resources": [ 
    "type": "Microsoft.Storage/storageAccounts", "name": "[parameters('newStorageAccountName')]", "apiVersion": "2015-06-15", "location": "[parameters('location')]", "properties": { "accountType": "Standard_LRS" 

    Classic deployment model

    Let's talk a little about what happened before the appearance of the Resource Manager. Now these resources are called classic. For example, a client may have storage accounts, virtual machines, and virtual networks that are managed using a classic deployment model. The classic model and deployment model using the Azure Resource Manager are incompatible - the Resource Manager resources cannot interact with the classic resources and vice versa. For example, the PaaS Azure Cloud Services component is classic, so you can work with it only through classic storage accounts. There is one exception to this rule: you can place Resource Manager's virtual machines in classic storage accounts.

    Note that during such a migration, you may need to log in to the classic Azure portal, which displays classic resources, but does not have the resources of the Resource Manager, and vice versa.
    Note. There are two versions of the portal. The relevant is the Azure portal, available at . Most of the capabilities have been moved to the Azure portal, but there are a few exceptions, for example, Azure Active Directory (Azure AD). The previous version of the portal is called “Azure Classic Portal” ( You can now use it to manage Azure AD services, as well as to configure and scale classic resources (for example, cloud services).
    You can migrate your resources from the classic deployment model to the deployment model using the Azure Resource Manager.

    • Files, tables and blobs can be transferred from the classic storage account to the new storage account of the Resource Manager using AzCopy. Please note: the tables must be exported from a classic account and then imported into the Resource Manager account.
    • Virtual machines can be transferred as follows: disconnect them, copy the VHD file to the new Resource Manager storage account, and then re-create the virtual machine using the VHD file.
    • Virtual networks can be created as Vnet objects in the Resource Manager.
    • In addition, the migration service is running (it is currently in the public trial version). Currently it is not recommended to use it for production loads. More detailed information is given in the article .

    Considering the deployment model in PowerShell scripts

    Chapter 8 (Management Tools) discusses some of the tools for working with Azure, including the Azure PowerShell and Azure CLI cmdlets.

    When developing a deployment model using the Resource Manager, Azure specialists sought to create PowerShell cmdlets that would work only for the deployment model using the Resource Manager. In the name of such cmdlets, instead of the word Azure, the word AzureRm is indicated. For example, to create a classic storage account, you can use the New-AzureStorageAccount cmdlet. To create a storage account in the Resource Manager, you need to run the New-AzureRmStorageAccount cmdlet.

    This is done so that the user can immediately understand what type of resource he creates. In addition, this ensures the possibility of correct execution of previously created scripts. Each time you deploy a Resource Manager resource, you must specify the resource group in which you want to place it. In addition, some Resource Manager cmdlets (for example, a cmdlet for creating a virtual machine) support more detailed parameters than the classical model cmdlets.

    One final note: the changes affect only those PowerShell cmdlets associated with storage accounts that belong to the management plane (for example, cmdlets to create, delete, and list storage accounts). For PowerShell cmdlets that serve to access the contents of the repositories (blobs, tables, queues, and files), nothing has changed. Just send them the link to the storage account you need and they are ready to use.

    Download the full version of the book for free and study it at the link below.


    Also popular now: