Azure Arc Enabled Servers Part 1: Introduction to Azure Arc for Developers and DevOps

When cloud providers first started to appear, ease of management and overview were the most appealing advantages for developers. We could manage our resources just by using a specialized service portal and a dedicated command-line application. With the introduction and establishment of DevOps practices, these tools have become a requirement for any kind of infrastructure management.

There are many reasons these tools are required to get the job done. Think about any kind of automation demand: To stay flexible, we need to have automated support from our tools. Otherwise, it would be really difficult to scale or stay ahead of threats in the quickly evolving IT landscape. Plus, no one is paying for maintenance teams to manually connect to servers, click around, and slowly aggregate the information they need. Dashboards with real-time monitoring are often business-critical.

Luckily, these solutions exist even for on-premise servers, but they don’t provide some of the other benefits that modern cloud providers offer. Most importantly, they don’t simplify maintenance. Wouldn’t it be convenient if we could bring our custom on-premise servers to a cloud provider? We’d get some of their benefits while still being able to work on a custom solution, with runtime costs completely in our hands. This is where Azure Arc comes into play.

Operate Multiple Environments Via a Single Interface

Azure Arc makes it easy to manage cloud, multicloud, and hybrid cloud workloads behind a single interface. This means we can have all our resources — no matter where they’re hosted — available through the Azure Portal and the Azure CLI. We can host them on our own servers in a data center, or in another cloud provider’s facilities if we wish, so long as the underlying operating system is supported, any machine, real or virtual, can be integrated with Azure Arc.

Even better, Azure Arc also allows us to run popular Azure services within other environments. This includes managed databases, like Azure SQL Database or Azure Postgres Hyperscale, as well as web apps and Azure Functions. This includes some very interesting managed services, including Azure Logic Apps and Azure ML apps. This may be important for meeting data regulations or for performance reasons when physical proximity has a large impact on responsiveness.

Another factor that was traditionally important for choosing the cloud over on-premise solutions was the ability to scale applications easily. With the introduction of the Twelve-Factor App methodology and subsequent cloud-native apps, scalability is often straightforward to implement if hosted by a cloud provider. Now, though, we can obtain the same scalability for our on-premise resources by integrating through Azure Arc.

Scaling a Kubernetes cluster with nodes that are distributed among different regions, different data centers, and even different vendors — from different cloud providers to on-premise solutions — is now possible even with a managed control plane such as the Azure Kubernetes Service (AKS). Although AKS already offers some appealing scalability perks, like virtual nodes, Azure Arc integration makes it even more powerful.

But scalability isn’t the only reason to choose Azure Arc. Aggregating all kinds of resources in a single bucket and making them manageable through a common interface allows us to maintain resources. This maintenance covers security. With the help of automatic updates and patches and notifications via the Azure Portal, we get quite a boost for our infrastructure security.

Today, good security solutions aren’t merely helpful. They’re often mandatory for many big companies. And, in some cases, they’re industry requirements. This poses the difficult task of establishing an effective system for noting aggregation, reflection, and system events to reach actionable security insights.

Since Azure Arc allows us to access and utilize all the security options available in Azure, we benefit from security measurements from the cloud within our own environments — likely the most accurate and useful measurements we can get. Azure Arc conveniently lets us keep running resources on-premises to meet our compliance needs, but with the scalability and ease of maintenance, we benefit from using a cloud provider. We can choose from a wider pool of resources by mixing our on-premise servers with resources provided by Azure. This lets us deliver better service to a globally distributed user base, including handling all the associated spikes in traffic much more smoothly.

The key ingredient in Azure Arc is the Azure Connected Machine agent, which can run on both Linux distributions and Windows machines. We take a closer look at this agent in the next article, but to keep things simple for now, it’s most important to know the machine agent is a daemon or service that runs in the background and lets your on-premise server appear as if it’s an integrated Azure resource. The integration is not only about reading details, but also makes it possible to manage the server through Azure.

Overview

In this article series, we’ll take a deeper look at Azure Arc. In the following article, we’ll begin our journey by setting up Azure Arc-enabled servers from within our own infrastructure: one using a Linux distribution, and another running on Windows.

In the final article, we’ll examine some details on security and automation. We’ll use the machines we set up in the second article to explore how to set up the Azure Security Center and set up Azure Sentinel, and then finish the article with an in-depth discussion about applying further automation with a Python 3 Runbook.

Now, let’s begin by discussing what you need to enable Azure Arc, and how the pieces of this configuration fit together.

Prerequisites

To follow along with this series, and to experience the benefits of Azure Arc for yourself, you need to have two providers registered in your Azure subscription. You can configure this setup through the Azure CLI, so make sure you have the Azure CLI installed on your system.

If you are not already logged in, do that now:

az login
az account set --subscription "Your Subscription Name/GUID"

The first command associates the Azure CLI running on your terminal with your Microsoft Azure account. The second command chooses the subscription that should be used together with your account. You can find the GUID of your subscriptions on the Subscriptions blade in Azure Portal.

You can now register the two providers using the following commands:

az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'

You’re all set to use Azure Arc!

Conclusion

We’ve introduced the main concepts and rationale behind Azure Arc. We can use a single, common interface to manage our on-premise architectures together with cloud services from different providers. This results in a convenient way to manage resources, bringing together the scalable power we expect from the cloud with the highly-controllable security we achieve on-premises. The process is packaged in familiar Azure interfaces — within the Azure Portal and usable from the Azure CLI.

In the next article, we start adding machines from other environments to Azure Arc. One machine uses Ubuntu from another cloud provider, and the other is a Windows VM running in our own data center.

To learn more about Azure Arc enabled servers, check out Azure Arc-enabled servers Overview.