Managing and deploying resources

So far the focus was on what exists in Azure. Now it is about how you create and manage it. You have several ways to do that: click in the browser, type commands, or describe the desired environment in a file. All paths lead to the same service, Azure Resource Manager, and that is the common thread of this lesson.

The example is the made-up carpentry shop Tischlerei Sommer, which needs a small environment for its order management for each customer.

The tools: portal, Cloud Shell, CLI and PowerShell

Microsoft names three tools for working with Azure:

• The Azure portal is a web-based, unified interface. There you can create, manage and monitor resources and build your own dashboards for an overview. The portal is designed for resilience: it is present in every Azure datacenter and is updated without downtime. It is suited for getting started, for looking things over and for one-off tasks.
• Azure PowerShell is a shell in which you run commands, so-called cmdlets. In the background they call Azure's REST API.
• The Azure CLI (command-line interface) can functionally do the same as Azure PowerShell. The difference lies in the syntax: PowerShell uses PowerShell commands, the CLI uses Bash commands. Which one you take depends mainly on which language you know better. Both can be installed on Windows, Linux and macOS.

Commands can be saved as a script, which makes them repeatable and automatable. The same task, creating a resource group with the tag Environment, looks like this:

az group create --name rg-sommer-test --location westeurope --tags Environment=Test

New-AzResourceGroup -Name rg-sommer-test -Location westeurope `
    -Tag @{ Environment = "Test" }

Azure Cloud Shell is a shell in the browser. You start it in the portal by clicking its icon, and there is nothing to install or set up. You are already signed in with your Azure credentials, so the shell knows your permissions. And you have a choice: Cloud Shell supports both Azure PowerShell and the Azure CLI.

Azure Arc: Azure beyond Azure

Not everything runs in Azure. Some servers sit in your own datacenter, others with another cloud provider. Azure Arc works together with Azure Resource Manager and extends Azure's management and monitoring to such hybrid and multicloud environments. The idea: your existing non-Azure resources appear in Azure, and you manage them with the same tools and rules as if they ran there.

Among other things, Arc can manage servers, Kubernetes clusters, Azure data services and SQL Server outside of Azure. That way, for example, policies and inventory overview can be handled the same in all environments, instead of looking after each environment with its own tools.

Azure Resource Manager

Azure Resource Manager (ARM) is the deployment and management service of Azure. Whenever you do something in Azure, it is involved. A request from the portal, from the CLI, from PowerShell or from a program arrives at it. It checks sign-in and permission and forwards the request to the responsible service. Because all paths run through the same interface, you see the same results in all tools. What Resource Manager also offers:

• management of infrastructure through declarative templates instead of scripts,
• deploying, managing and monitoring all resources of a solution as a group,
• redeploying with a reliably identical state,
• dependencies between resources, so that the order is right,
• access control through RBAC and the setting of tags.

Infrastructure as code

Infrastructure as code (IaC) means: you manage infrastructure through code and templates instead of manual work. The starting point can be scripts with the Azure CLI or PowerShell. It continues with ARM templates and Bicep.

An ARM template describes in a JSON file which resources you want to have. You say what should be there in the end, not in which steps it happens. This is called declarative. Azure checks the template beforehand and creates the resources in the right order, in parallel where possible. Advantages: repeatable results, because the same template serves development, test and production, and reuse by splitting into modules.

Bicep is a declarative language for Azure deployments that also runs through ARM. It is usually simpler and more concise than JSON templates and easier to read and write.

The example of Tischlerei Sommer

For the first customer, the carpentry shop clicks the environment together in the portal. By the fifth customer, it writes the same environment as a Bicep file. Now each new customer environment is created with one deployment and looks the same every time. It connects the old server in its own basement with Azure Arc, so that it appears in Azure and gets the same rules.