How do you get the benefits of the cloud in your own data centre? Microsoft has been pondering this question for some time, coming up with a range of different solutions. At one end of the scale is the ‘Azure-consistent’ hardware portfolio, which starts with the rack-based Azure Stack Hub and scales down to IoT and edge compute-focused Azure Stack Edge hardware. But they all need you to invest in new, specialised hardware. What do you do when you want to use your own existing infrastructure?

SEE: Special report: The cloud v. data center decision (free PDF) (TechRepublic Premium)

That’s where its recent announcement of Azure Arc comes in, the launch of an application-level control plane for your modern cloud applications. Managed from the Azure Portal, Arc uses familiar Azure concepts and tools to deliver applications and management policies to virtual machines and Kubernetes running on your servers or on other public clouds.

What Azure Arc is, and what it isn’t

It’s a little hard to understand what Azure Arc is — the initial blog posts and the holding page on Microsoft’s website are more much more marketing material than technical information. However, we were able to talk to some of the team behind it at Microsoft’s recent Ignite event, and now have a good picture of what it is — and, perhaps more importantly, what it isn’t.

Azure Arc isn’t another way of delivering a cloud-like operating platform to your data centre. It doesn’t install Kubernetes and it doesn’t manage your virtual infrastructure for you. Above all, you certainly shouldn’t expect Microsoft to use Azure Arc to deliver an Azure Stack Hub without the hardware.

Instead, it’s part of a shift in Microsoft’s thinking about distributed application management. Best shown in its Open Application Model, it treats distributed computing as three layers: a mix of physical and virtual infrastructures, a set of application services, and an application. In this model you manage each layer separately. The infrastructure layer hosts the application services, which include container orchestration services like Kubernetes. Applications are deployed onto that layer, either as discrete virtual machines or as a set of containers along with cluster definitions.

Azure Arc is part of managing the middle layer, using familiar Azure tools to deliver and manage applications running on existing private cloud installations. If you’re using a tool like VMware’s vSphere to run a virtual infrastructure, Azure Arc connects to those VMs, attaching them to Azure’s management tools. Once connected, you’re able to manage them using the Azure Portal, and targeting them for application deployments.

You’re not limited to working with virtual machines, you’re also able to use Azure Arc to manage Kubernetes, deploying containers with your code and with containerised versions of Azure SQL Database and Azure’s hyperscale PostgreSQL. If you’re using AKS, your code can add additional Azure-hosted resources as required, spinning up new nodes and hosting the same containers.

Introducing Connected Machines

At the heart of Azure Arc is a management agent that runs on what Arc calls Connected Machines. These are managed servers, each with an Azure Resource ID and managed as part of an Azure Resource Group. Once a server is connected, you can see it in your Azure Portal and can apply management policies from an Azure Resource Manager template. Connected Machines must be running a recent release of either Windows Server or Ubuntu, with a direct connection to Azure Arc’s service endpoints. These use SSL, so if you’re using a proxy make sure it supports HTTPS.

SEE: Top cloud providers 2019: A leader’s guide to the major players (TechRepublic Premium)

Those Connected Machines are managed using your current enterprise infrastructure tools, so you can continue to use VMware or System Center tools and skills to manage your virtual infrastructure. What Azure Arc does is use ARM policy definitions to ensure that you’re running that VM infrastructure securely, applying role-based access controls and managing the server identities.

Managed VMs don’t need to be run on your own infrastructure — if you’re using AWS or GCP you can still add VMs to your Azure Portal. All you need to do is bundle the Azure Arc agent into your VMs and connect them as soon as they boot.

A control plane for modern application infrastructures

Keeping the infrastructure and application control planes separate is a logical way to manage hybrid cloud platforms. By using ARM templates to declaratively apply the same policies to on-premises and in-cloud instances of the same applications, you can be sure that they have the same settings. Arc’s agent doesn’t only set policies, it also monitors for compliance, and where necessary can remediate changed settings. Everything is visible through the Azure Portal so you can quickly see which servers are non-compliant.

Administrators have access to a command-line tool that can be used to configure and debug Azure connections. You use it with PowerShell to connect servers, as well as collecting and viewing status information. Much of Azure Arc’s management is handled using PowerShell rather than group policies, with PowerShell’s Desired State Configuration management tooling applying policies and ensuring that managed servers and VMs don’t drift out of compliance.

Not only VMs, also Kubernetes

While the public preview doesn’t yet support Kubernetes, Microsoft has said that Azure Arc’s Kubernetes support is based on the same agent model, deployed via Helm. Once you’re managing a cluster you can deploy data services with Azure SQL and Azure PostgreSQL,via the pay-as-you-go model as used in the rest of Azure. That way you get to run a managed database service, with the same benefits as running in Azure, but on your own network, ensuring regulatory compliance. Arc policies can then monitor your Git repositories for changes, downloading new code and containers as they’re built.

Microsoft is clear that Azure Arc is part of its Azure Management platform, bringing Azure Resource Manager to your choice of clouds. It ties into your existing Azure billing, but if you’re managing resources on AWS or another public cloud you won’t get any insights into its billing and will still need to use existing management tools for this. Clusters don’t need to be always-connected, so Azure Arc will be able to manage clouds running on ships or in remote areas, downloading updates and new policies when they connect.

What Arc ensures is that the same policies are running for the same code wherever it’s installed. Your ARM templates are policies that ensure that the right ports are open, that servers are connected to the right domains, or that you’re not in danger of security certificates expiring. If you need to keep the lights on in a cloud-native infrastructure, and you’ve already got a dependency on Azure, it’s what you need to ensure your hybrid cloud all runs the same way — no matter where it’s installed. Just don’t forget to keep the lights on by managing that underlying infrastructure the way you always have.

Cloud Insights Newsletter

Your go-to knowledge base for the latest about AWS, Microsoft Azure, Google Cloud Platform, Docker, SaaS, IaaS, cloud security, containers, the public cloud, the hybrid cloud, the industry cloud, and much more. Delivered Mondays

Sign up today

Also see