Azure World Newsletter – Issue 3.18

September 21, 2022

Welcome to the eighteenth edition of the Azure World Newsletter in 2022.

Registration is now open for Microsoft Ignite, which takes place in Seattle from October 12-14. As with the past couple of years, you can watch the sessions online, although there is an in-person element this year. You can sign up here.

https://ignite.microsoft.com/en-US/

I’ve been invited to be part of a panel after Ignite to discuss the event, which is taking place on October 20. I’ll include a link to that here:

https://www.meetup.com/comecloudwithus/events/288402133/

Thanks so much for being a subscriber! The unsubscribe link is at the bottom if you want to stop receiving these emails.

ONE.

If you’re familiar with Azure administration or have taken the AZ-104 exam, you’ve likely heard the term “infrastructure-as-code (IAC).”

This is the concept of having your infrastructure (VMs, apps, containers, networks, storage, etc.) documented in ARM templates (or Bicep or Teraform) so that you can re-create the infrastructure at any time. In fact, if you follow this approach, you’re likely using the ARM templates to control your infrastructure and not making any changes to the infrastructure directly ever.

I recently heard the term “enterprise policy as code (EPAC).” Policy is Azure’s governance tool and has been growing more useful and powerful over time. Just recently, I saw an Azure Policy AKS extension that allows you to extend the reach of Policy into AKS pods. So you can enforce company governance policies on the contents of containers now.

The idea is to have a set of policies that must be universally deployed and enforced across your enterprise. You might have a dozen subscriptions and nested management groups, but you want to ensure the Policies are properly deployed and configured in each. Instead of manually checking each subscription for the right set of policies with the right settings (which could number in the dozens or hundreds), Policy as Code has you deploying policies to all subscriptions from a central Azure DevOps pipeline.

Adding a centralized management layer to your policy assignment reduces human error and configuration drift.

You might think Blueprint was supposed to be the tool to deploy policies to new subscriptions, and you’d be right. But this Policy as code approach is ongoing, whereas Blueprints is a one-time assignment.

Microsoft has a blog post talking about it:
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/azure-enterprise-policy-as-code-a-new-approach/ba-p/3607843

As well as a GitHub repository containing an example DevOps pipeline and other resources to get started:
https://github.com/Azure/enterprise-azure-policy-as-code

TWO.

So I posted a question to the Azure User Group on Facebook (https://www.facebook.com/groups/azureusergroupunofficial) if anyone had anything cool in Azure that I should write about.

CataLin Magher suggested “Azure Automanage Machine Configuration.” This is interesting because I wrote about “Policy as code” in the first section of this newsletter above. Azure Automanage Machine Configuration uses Policy to manage machine configuration for Azure VMs and virtual machines outside of Azure using Arc.

Azure Automanage is an umbrella service that can manage many virtual machine-related features such as boot diagnostics, backup, monitoring, update management, change tracking, inventory, log analytics, and security center.

But machine configuration keeps track of the installation settings of a VM. This is called “Desired State Configuration” in other contexts.

In my AZ-104 course, we talked about DSC in the context of using ARM templates (with Azure Automation) to keep infrastructure in the desired state. Azure Automanage seems to be a more advanced form of this, allowing you to onboard an existing virtual machine, and track its configuration to ensure nothing changes.

Microsoft describes it like this:

“Azure Automanage also automatically monitors for drift and corrects for it when detected. What this means is if your virtual machine or Arc-enabled server is onboarded to Azure Automanage, we’ll monitor your machine to ensure that it continues to comply with its configuration profile across its entire lifecycle. If your virtual machine does drift or deviate from the profile (for example, if a service is off-boarded), we will correct it and pull your machine back into the desired state.”

You can check out Azure Automanage Machine Configuration here:
https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview