We live in a hybrid world, and most medium-to-large businesses will have IT applications and infrastructure on-premises and in various clouds for a long time to come.
Microsoft has always been aware of this fact and has architected its cloud solutions with this in mind. For identity, Active Directory (AD) works seamlessly with Azure Active Directory (AAD). For email and collaboration, Exchange and SharePoint Server talks to Exchange/SharePoint Online in Office 365. Azure Files gives you SMB shares in the cloud while Azure File Sync hooks up your file servers to “bottomless” storage and backup in the cloud.
If you need cloud computing on premises Microsoft was first to market with Azure Stack Hub, a set of integrated servers running the same software as Azure (slightly behind the public Azure but updated monthly) in a turnkey solution that lets you run VMs and Platform-as-a-Service (PaaS) services such as Kubernetes or Service Fabric. You can purchase Azure Stack Hub from Lenovo, Cisco, HPE and a few others and deploy it wherever you need it. Alternatively you can purchase it as a service from a worldwide network of service providers. If imitation is the highest form of flattery it certainly makes sense that AWS followed in Microsoft’s footsteps and released Outposts.
And the reverse is also true: Many Azure services can reach out to your on-premises or multicloud infrastructure and extend automation through Azure Automation, for instance, or monitor it through Azure Monitor. The next logical step is making your infrastructure and data outside of Azure (on-premises or in other clouds) be part of the Azure Resource Manager (ARM) control plane. Linux and Windows VMs appear alongside your cloud VMs and you can control access with Role Based Access Control (RBAC) and configuration through Azure Policy on all of them, no matter where they’re running. If you’re running Kubernetes anywhere you can manage all of your clusters from a single pane of glass. And if you have databases outside of Azure they can also be managed together with the ones in Azure. This is the premise of Azure Arc, which first debuted at Ignite last year.
This article will look at the current capabilities of the public preview of Azure Arc and why you should care. Google’s Anthos is a similar offering but it’s exclusively focused on Kubernetes workloads whereas Azure Arc casts a much wider net.
Azure Arc-Enabled Servers
This was the first cab off the rank and the public preview has now been available for nearly a year (if I was a betting man I’d say this will be released to General Availability at Ignite 2020). The concept is simple: Take a Linux or Windows VM wherever it’s running, install the Azure Connected Machine agent and it’ll receive an Azure ID, be part of an ARM Resource Group and appear in your Azure portal.
You can then use RBAC to assign different users (or groups) access to it and assign it tags just like any other resource. And you can also use Azure Policy to audit settings in the VMs and its workloads. Furthermore, you can deploy (some of) the same extensions that are available for Azure Infrastructure-as-a-Service (IaaS) VMs to bring additional capabilities. This includes the Custom Script Extension so you can run scripts inside the VMs from the Azure portal, Desired State Configuration (DSC) and the Log Analytics agent for OS and workload monitoring. All of these are available for both Windows and Linux. Guest configuration is also available, sort of like Group Policy for any VM (domain joined or not), letting you audit settings inside any server.
Tags aren’t just for organizing resources or for tracking costs across resource usage; you can also use tags to enforce policy, i.e. VMs that are tagged as High Business Impact (HBI) must have Azure Backup configured. You can also use Azure Update Management to ensure that both Linux and Windows VMs are up to date with OS updates.
If you have a handful of VMs the easiest deployment option is the script that the portal generates, but if you have lots of VMs it’s better to create a Service Principal in Azure AD to be able to script the entire workflow. Windows Admin Center can also onboard managed servers to Arc, and Azure Automation offers preconfigured jobs to do it, with System Center support to come.
The public preview of Azure Arc-enabled servers is available in the East US, West US2, WestEurope and SoutheastAsia regions.
Azure Arc-Enabled Kubernetes
Similar to servers, you can attach Kubernetes clusters to Azure, in this case through an agent in the azure-arc namespace. The configuration data in the Azure end is stored encrypted in an Azure Cosmos DB. The following distributions have been tested in this preview:
- RedHat OpenShift 4.3
- Rancher RKE 1.0.8
- Canonical Charmed Kubernetes 1.18
- AKS Engine
- AKS Engine on Azure Stack Hub
- Cluster API Provider Azure
To access the cluster, you need the cluster-admin role, Helm 3 needs to be installed for onboarding the cluster, and Azure CLI version 2.3 or later is required for the Arc-enabled CLI extensions. Step-by-step instructions here. Note that Arc is not a cluster management solution; it assumes that the cluster is already configured. Arc uses the open source project Flux to pull configurations and applications from Git.
Once connected you can use Azure tags and apply Azure Policy for Kubernetes as well as use Azure Monitor to view/monitor your clusters. Furthermore, you can deploy applications and apply configuration using GitOps-based management. There are quite a few different policies you can enforce.
The Arc-enabled Kubernetes preview is only supported in the East US and West Europe regions.
Azure Arc-Enabled Data Services
This third leg of Arc is not yet in public preview, but it will enable you to run Azure SQL Managed Instance and Azure Database for PostgreSQL Hyperscale on Kubernetes on-premises and in any cloud. Here’s a short video covering the highlights.
In Azure, SQL is protected by security vulnerability assessments, and this same protection will extend to your databases connected through Arc. Another powerful security feature in Azure is Advanced Threat Protection (ATP); when a database is managed by Arc it can receive ATP security recommendations.
Conclusion
These are powerful features and I think Microsoft is on to a winner here: the ability to connect to all your VMs, no matter where they’re running, and see them in a single pane is useful. To then be able to apply RBAC across those resources, tag them, apply policy for configuration and auditing, deploy applications and configuration to K8s clusters and manage it as a single cohesive whole is very powerful.
I can see how large retail chains, for instance, might run small servers in each store, with LOB applications in containers on top of Kubernetes and perhaps a local SQL database where Arc would manage the VMs, the Kubernetes clusters and the database from a single pane in Azure.
Managed service providers aren’t left out either. Arc plays nice with Azure Lighthouse, which lets your IT provider connect to (parts of) your IT infrastructure and manage it on your behalf. I can’t wait to see what will be revealed about Arc at Ignite 2020.
Source: https://virtualizationreview.com/articles/2020/08/31/azure-arc.aspx
