What challenge is Azure Arc trying to solve?

I spoke previously about the fact that the majority of organisations today are adopting a hybrid approach to their cloud strategy and discussed some of the reasons for this.  The result is that many organizations will run workloads in different environments and their IT estate will continue to grow in complexity as new technology becomes available and they invest in to different platforms.  This may look like applications running across different infrastructure and hosting environments as well as multiple public cloud environments.  With this comes the added complexity and overhead of different development tools and languages and ultimately team and skill silos prompting questions like:

With Azure Arc the aim is to help address these questions and bring consistency where possible across different operating environments.

What is the overarching goal of Azure Arc?

If you have workloads running outside of Azure the goal is to project these in to the Azure Portal to provide a centralized management plane, notice I didn’t say single pane of glass, whilst that may be the north star it’s not the reality and I think we’ve all been burned by the promises of that phrase over the years.  It can go in to the bucket of cloud terminology which frustrates me!

Once visible in the portal it becomes easier to govern, manage and secure workloads in a more consistent manner across different environments. Organisations can make use of role based access control to manage and delegate access to teams across the business.  This area of Azure Arc capabilities, focused on infrastructure inventory and management, is definitely the area which has seen the most development and interest over the last few years since Azure Arc launched.  I think this is for two reasons, this is where customers see the most value and everything else hinges off of infrastructure. 

Azure Arc aims to empower developers by enabling them to use modern development practices and tools regardless of where their workloads and data need to run.  With the ability to run certain Azure Services like SQL Managed Instance anywhere it means that both IT Ops and DevOps teams have options to satisfy each of their quire often differing requirements.  It enables organisations to take advantage of cloud practices, services and automation in their datacentre or at the edge.

What exactly is Azure Arc?

I have heard so many crazy assumptions about what Azure Arc is, I feel like I am on a mission to help bring clarity to the area and help people understand the components and potential of Azure Arc.

It is important to understand that Azure Arc is not single service, it is not something you deploy and boom you have all of the capabilities of Azure Arc and are charged for a single service.

Rather it is a set of technologies and capabilities from which you can pick and choose features to reach your desired outcome based on your requirements, you might say it’s adaptive.

You can largely divide Azure Arc capabilities in to two main buckets and of course in each of these buckets there are sub buckets but lets start with the two main ones and go from there.

First up you have Azure Arc enabled infrastructure, this category of features and capabilities is all about projecting workloads which live outside of Azure in to the Azure portal.  For instance, once a virtual machine (VM) is projected in to Azure it looks and feels very much like an Azure VM, you can then view it along side all of your other Azure VMs.  As mentioned previously, this is the category which has seen the most development from Microsoft since the launch of Azure Arc and it the area which most of my customers are interested in.  If you haven’t looked at this category since the early days, take a look again, because it has come on leaps and bounds. 

The second category of Azure Arc is focused on enabling Azure Services to run outside of Azure on any infrastructure.  At present there are only a couple of Azure services that are generally available (GA) with many still in preview.  This category is about bringing Azure Services to wherever your workloads need to run, ensuring that these environments can also take advantage of cloud native innovation.

Azure Arc-enabled Infrastructure

In this category we are going to look at:

Azure Arc-enabled Servers

Servers, virtual or physical are connected to Azure using the Azure Connected Machine Agent.  Once connected, the server becomes what is known as a connected machine and treated as a resource in Azure.  It is assigned a Resource ID which enables it to be tagged and placed in a resource group.

As a result, Azure management services can now be extended to this non-Azure machine.  Alongside using Azure management constructs like Tags and Resource Groups, Azure Policies can also be used to govern the server as you do your Azure Servers.  These connected machines can be enhanced from a security perspective by using Azure Defender or Microsoft Sentinal.  You can also monitor these servers with Azure Monitor and use Azure Update Manager in Azure Automation to manage operating system updates for your server just like you do in Azure.

The Multicloud connector enabled by Azure Arc went in to public preview in June 2024, this allows organizations to connect non-Azure Public Cloud resources to Azure. Currently AWS environments are supported in this preview.  This provides an inventory of all of your cloud resources and again allows you to apply Tags and Azure policies to these resources.  It also auto discovers all EC2 instances in AWS and onboards them to Azure Arc by installing the Azure Connected Machine Agent.

It’s also worth mentioning Azure Arc enabled Extended Security Updates (ESU) in this section.  You can now purchase ESUs on a monthly subscription basis via Azure Arc.  This avoids having to pay for ESUs on an annual basis. This is useful if you plan to upgrade within the year and allows you to pay for ESUs for the duration you need them as you move through the process of upgrading. 

This category is about gaining central visibility of all of your servers wherever they live and then as appropriate applying consistent Azure governance, management and security practices across all of those servers.

Azure Arc-enabled VMware vSphere

Azure Arc-enabled VMware vSphere went GA in November 2023.

This is a capability which I have been discussing with many customers recently.  With VMware customers who have an Azure strategy, some of which are looking at alternatives to VMware and some who are looking to bring those two environments closer together.

This is a great way to begin to gain experience and think about what a true hybrid connected environment might look like even there is a plan to swap out the infrastructure underneath.  Whilst Azure Arc-enabled VMware vSphere is not the same as Azure Stack HCI they do share similar experiences and capabilities and so it’s a great place to start if looking to bring on-premises and Azure environments closer together using Azure Arc.

What is Azure Arc-enabled vSphere?

Azure Arc-enabled vSphere allows the automatic discovery and onboarding of VMware machines to Azure Arc as well as enables self service.

This is achieved by deploying the Azure Arc Resource Bridge in a vSphere environment.  The Azure Arc Resource Bridge is a virtual appliance which hosts components to allow communication between your vCenter Server and Azure. When you’re connected an automatic discovery of inventory of vSphere resources takes place.  This then allows you to perform some VM operations from the Azure portal like start/stop/restart, as well as self-service access which you can control using Azure Role Based Access Control. Services such as Azure Policy and Azure Monitor can then be applied to these VMs.

Azure Arc-enabled Kubernetes

At this point you might start to recognise a theme.  Azure Arc-enabled Kubernetes is all about connecting your Kubernetes clusters wherever they might be running to Azure and again this is done via an agent. 

Azure Arc enabled Kubernetes works with any Cloud Native Computing Foundation (CNCF) certified Kubernetes clusters and this includes clusters running in other cloud native platforms such as AWS and GCP.  It could be a Tanzu environment running on VMware for example.  Once connected in to Azure you can view a centralised inventory of your Kubernetes clusters wherever they might be and tag, group and apply Kubernetes policies as well as monitor and secure using Defender for Kubernetes.  You can also configure clusters and deploy applications using GitOps based config management.

Now it gets interesting.  These Kubernetes clusters appear as Azure Resources, becoming a platform to deploy Azure Services to.  We’ll come on to Azure Services next but the first thing to know is that they require an Azure Arc enabled Kubernetes platform as a deployment target.

Azure Arc enabled Services

In this category we are going to look at:

Azure Arc-enabled Data Services

Currently within this category the only service which is GA is Azure SQL Managed Instance.  This allows organizations to take advantage of the built in management capabilities of this managed Azure Service but run it on-premises to maintain data sovereignty. 

There are options when it comes to the degree of connectivity from the on-premises environment to Azure.  You can choose between two different modes:

This provides options around how much data is sent to Azure, how users interact with the Arc Data Controller and the option you choose may impact the availability of data services.

Directly connected of course offers the most benefits and allows users to use Azure Resource manager (ARM) APIs, Azure CLI and the Azure portal and is a similar experience to using the service in Azure. 

Indirectly connected then the view from the Azure portal is read only, this allows you to see an inventory of your SQL managed instances but you can’t do anything with them from the portal and local tools must be used to make changes. 

Azure Arc-enabled Application Services

All of these services are currently still in public preview and have been since the launch of Azure Arc. 

After launch I think it became obvious quite quickly that the infrastructure side of things was where the value and focus was for the majority of customers and it also became apparent that everything else depended on that area being comprehensive and reliable.  So the focus has been on the Azure Arc-enabled infrastructure side of the house.  That said all of these PaaS services are currently in public preview and available to try out.

Ultimately a lot has changed since Azure Arc first launched and I suppose Microsoft need to see demand or a business case to justify the development of bringing these in to GA.

Azure Arc-enabled Machine Learning

There will be no surprise that the service which has made it to GA is of course machine learning. Azure Machine learning can be used by Machine Learning (ML) professionals, data scientists and engineers in their day to day workflows to train and deploy models as well as manage machine learning operations. 

These professionals have the options to create their own models or use models built from open-source platforms like PyTorch.

The IT operations team would be responsible for preparing a Kubernetes cluster, Arc enabling the cluster and then deploying Azure machine learning cluster extension and attaching the Kubernetes cluster to the Azure machine Learning workspace

The Data Science team will then be able to discover a list of available compute targets and instance types in the Machine learning workspace and these can be used for training or inference workloads.

This opens up the following possibilities:

Azure Arc Pricing

With all these categories and sub-categories of features and capabilities a question that of course comes up: How is Azure Arc charged?

The control plane functionality is provided at no additional cost.  You can go ahead and Azure Arc enable servers or use Azure Arc enabled VMware vSphere and get centralized visibility of your assets, tag them, place them in resource groups etc at no extra cost. 

If you want to take advantage of services such as Azure Monitor etc on your Arc connected servers then these will be charged just as if you were using these on your Azure VMs are they are an Azure Service.  There are services which are free for Azure VMs such as Azure Policy Guest Configuration and Azure Automation services like Update Management which are charged for per server for Azure Arc enabled Servers. 

In terms of Azure Arc enabled Services like SQL Managed Instance for example these have their own pricing which is similar to how they are priced in Azure but not quite the same as they are running on your own hardware. Keep in might you need an Arc-enabled Kubernetes platform to deploy these services too.

Of course this is an over-simplified view and I will not lie and say it is this simple because it isn’t, but this is a pretty good place to start.

Summary

That was a very high level overview of Azure Arc but I hope that it was helpful and I hope you can see why I always insist on making sure that anyone I am working with understands the foundations of Azure Arc before we delve deeper in to Azure Hybrid.

It is also something I insist is covered and understood before going down the Azure Stack HCI path.  Azure Arc is built in to Azure Stack HCI and so it is crucial to understand as part of that journey too.

Azure Arc is a fast paced and complex area but it is hugely valuable when understood and applied correctly.

Tune in to Microsoft Ignite on the 18th of November where we will see another exciting round of announcements and the next evolution of Azure Arc!