Azure Arc was announced at Microsoft Ignite in November 2019. It’s the service that many have been waiting for or at least not knowingly wishing for. Azure Arc extends Azure Resource Manager capabilities to on-premise and multi-cloud.

Figure 1: Overview of Azure Arc capabilities

So, what does Azure Arc exactly do?

There are several features that Azure Arc supports, and it may not be that easy to understand everything at first look. Long story short, you can manage your on-premise Windows and Linux workloads with ARM, as well as deploy and run Kubernetes Clusters at on-premise or multi-cloud but manage them centrally from Azure. Also, you can now run Azure Data Services at infrastructure of your choice. [1] [3]

Azure Arc for Servers

Most importantly, Azure Arc lets you manage your on-premise server workloads as if they would be Azure resources (that is if your server is Windows Server 2012 R2 or newer or Ubuntu 16.04 or 18.04). I don’t think Microsoft has any plans to add support for older versions of Windows Server, but I would bet there will be more Linux variants supported as the service evolves. This feature is important, because it quite literally brings your on-premise and cloud workloads closer together for that single pane of glass management experience. You may still have to wait for a while for the experience to be complete, but it is a huge step forward.

Before getting into the details let’s take care of the prerequisites. To use Azure Arc for Servers the following resource providers need to be registered:

· Microsoft.HybridCompute

· Microsoft.GuestConfiguration

Now, let’s scratch some details.

In the portal, these servers show up as ‘Non-Azure Machines’. Apart from that, they have their own resource ID, they belong to a resource group like all other workloads. For these non-Azure machines, you can leverage the same features as with the native Azure workloads like tagging, policy assignments and Log Analytics for logging. In order to get going you need to install an agent to your on-premise servers. The agent then connects to Azure Arc service endpoints, all traffic being outbound and secure.

For onboarding your machines there are two options for you to choose from: interactive or at scale. If you just want to try it out or you don’t have that many servers you want to connect, use interactive option. You’ll be generating a script in the portal and then deploying that script on to your local machine. Before deploying, make sure your machine can access the following URLs or the script cannot access the download page.

· aka.ms

· download.microsoft.com (for Windows)

· packages.microsoft.com (for Linux)

If you don’t want to do the download separately from each machine, download the agent package somewhere it can be accessed from, and then modify the onboarding script to fetch the installation package from that specific location.

For heavy users with many machines there is a PowerShell version where you create a Service Principal with ‘Azure connected machine onboarding’ role to be used for onboarding. For running an installation at the local machines, you don’t need any roles for your Azure subscription just Local Admin or Root rights. [2]

As for the other features Azure Arc offers and supports familiar security features such as role-based access control (RBAC), security policies, secure delegation of management with Azure Lighthouse, activity logging for auditing [3] and I bet there’s more to come when the service reaches General Availability.

Kubernetes Clusters are in it too

You can also manage Kubernetes Clusters with Azure Arc too. There’s not much detailed information available online about it, but it is mentioned in the Microsoft blogs and on Azure portal [1][3][4]. The idea seems to be, that you can deploy Kubernetes Clusters from Azure to run in on-premise environment and leverage GitHub and Azure Policy to manage its configuration. If you search Azure Arc service from Azure Portal, you’ll notice that in order to use this feature you’ll have to sign up for preview.

Personally, what was even far more interesting was the feature called Data Services Anywhere. Let’s take a look.

Azure Data Services Anywhere

From now on you can probably deploy Azure SQL Database to Kubernetes Cluster running on VMware on AWS, if you’re into that sort of thing. But seriously speaking, if you deploy Kubernetes on any cloud or on-premise environment Azure Data Service Anywhere will be able to run on it.

The ramifications of this especially for on-premise environments are that you’ll have fully managed database service that you no longer need to patch or upgrade yourself. Also, you’ll never be end-of-support again. Updates are delivered from Microsoft Container Registry, but you still have the control over the policies and deployment cadences. If your infrastructure is up for it, you can enable elastic scale which lets you scale-up, scale-down and even scale-out with additional read replicas.

Below is a diagram from Microsoft elaborating how this all works.

Figure 2: How Azure data services works [7]

Azure Arc data controller is the bridging component between Azure Cloud and the on-premise (or cloud) Kubernetes environment. Azure Arc data controller supports Azure Policy, Azure Backup, Azure Monitor, scale-out to cloud, logging, patching, upgrading, Azure ATP, vulnerability assessments and so on. Microsoft will unveil their plans and details about the cloud billing model for data services anywhere at later point in time, but it seems that the data controller is used for gathering telemetry and consumption data also.

During the public preview of Azure Arc this subset of features is only available if you sign up for preview. Other limitations include that only Azure SQL Database and Azure Database for PostgreSQL Hyperscale are available, with more data services added over time. [5][6]

Final thoughts

Azure Arc is not finished product yet but it’s showing promises of what we could achieve and how we could be running hybrid environments in near future. There is no GA date released yet, but I’m excited about the opportunities that Azure Arc brings and looking forward having our first customer implementation to be built by Cloud2.

Discalmer: At the time of writing this blog, the service is in public preview state. For many, it simply means that it’s available for testing purposes, but don’t start building your critical production on it just yet! If you’re not familiar with preview features of Azure, just know that there is no SLA by Microsoft and in the worst-case Microsoft could roll back the whole service. I don’t believe in this scenario, but it’s still a possibility.

In-case-you-missed-it

Azure has opened two new regions in Norway (West and East) in November 19th.

[1] https://azure.microsoft.com/en-us/blog/azure-services-now-run-anywhere-with-new-hybrid-capabilities-announcing-azure-arc/

[2] https://docs.microsoft.com/en-us/azure/azure-arc/

[3] https://azure.microsoft.com/en-us/blog/azure-arc-extending-azure-management-to-any-infrastructure/

[4] https://azure.microsoft.com/en-us/services/azure-arc/#contact-us

[5] https://azure.microsoft.com/en-us/blog/bring-azure-data-services-to-your-infrastructure-with-azure-arc/

[6] https://azure.microsoft.com/en-us/services/azure-arc/hybrid-data-services/

[7] https://azure.microsoft.com/mediahandler/files/resourcefiles/how-to-guide-on-azure-data-services-anywhere/How-to%20guide%20on%20Azure%20data%20services%20anywhere.pdf