Operating in different platforms can make managing your environment tricky, which is why Microsoft created Azure Arc. Get tips on how to leverage Azure Arc from Thomas Maurer (@thomasmaurer), Senior Cloud Advocate at Microsoft.
There are several advantages to moving your organization’s workload to the cloud: it’s usually more agile, more flexible, and less expensive since you’re only paying for the resources you use. But many organizations still find that just one type of environment doesn’t meet all their needs.
Some businesses use both on-prem servers and a cloud service, others make use of hybrid cloud environments, and the majority have some combination. According to RightScale’s 2020 State of the Cloud Report, 93% of enterprises use more than one public or private cloud.
Within those different cloud environments, IT operations have to manage hundreds, if not thousands, of apps—some of which need to be run on VMs or servers while other newer apps are serverless or containerized. So there are a lot of different types of apps that need to be accounted for.
The need for a management tool that works across different cloud and on-prem infrastructures has increased as more and more organizations have diversified their environments, so Microsoft created Azure Arc.
Azure Arc, which was announced at the 2019 Microsoft Ignite conference, allows you to view workloads from non-Azure environments in your Azure portal. It also enables you to use the Azure governance tools you know and love across all of your platforms—helping ensure that your strategy and policies are being complied with, regardless of which cloud provider your resources are running on.
ShareGate has been helping IT professionals succeed in the cloud for over a decade. We hope this blog helps you better understand hybrid server governance—but if you’re looking for a tool to make managing Azure even easier, check out how ShareGate Overcast can give you better visibility and control in Azure.
During Deploy, ShareGate’s expert-led event on Azure governance, Thomas Maurer gave a full overview of Azure Arc along with demos showing how you can onboard servers to Azure Arc. You can watch Thomas’s 1-hour presentation, or keep reading for a recap of the highlights.
What is Azure Arc?
As the workloads we run get larger and more complex, and the types of tools and apps we use evolve, the more organizations are using multiple types of servers.
Today, most businesses run their workloads on a combination of multi-cloud environments, on-prem servers, and the edge. This can be challenging when you want to maintain visibility and control over all of your servers.
Azure has several management and governance tools to help keep your Azure environment organized and your data secure. Azure Arc is made up of a range of technologies that allow Azure management services and principals to extend to any infrastructure.
When you look at other servers through Azure Arc, the tools and apps from other servers will look almost like Azure resources. You can see similar information about them, such as what version is installed and how it’s connected.
In addition to servers, Azure Arc also connects to Kubernetes and Azure data services in private preview.
Through Azure Arc, you can view your Kubernetes Clusters in a unified way at scale and assign policies to them. So, if you want to deploy apps to certain systems, you can onboard these clusters in the Azure portal and then control them from Azure—regardless of which virtual or on-prem server they’re hosted on.
For Azure data services it’s even better. You can use Azure data services on the infrastructure of your choice and you can actually deploy Azure SQL Managed Instance or Azure Database for PostgresSQL Hyperscale on any infrastructure wherever you need them. By using Azure Arc and Kubernetes Cluster you can run these powerful data services on any workload.
While the visibility Azure Arc offers is substantial—being able to see all of your workspaces in one place is hugely helpful—it also enables you to use Azure tools in non-Azure environments.
How can you use cloud-native tools in a hybrid environment?
In order to maintain order and security, some organizations require that anything their developers deploy must to go through an IT custodian team first. But this can cause bottle necks and frustrations.
Instead, Thomas suggests—and ShareGate agrees—that you leverage the governance tools available in Azure. That way, you give the cloud custodian team the control they need to configure the cloud in a specific way, and developers get the speed and agility they need to build at an efficient pace.
Azure already offers several management tools that we know and love, including:
Azure Arc allows us to use these tools to manage all the servers we have on any infrastructure, whether or not they run in your datacenter.
After you’ve connected your other servers through Azure Arc, you’ll see VMs, network adapters, app services, databases, etc. when you log into your Azure portal and navigate to the All Resources list—whether they’re running inside Azure or not.
Similarly, you can tag those resources and use Azure Policy to push policies to them. With Azure guest configuration, you can configure the operating systems running inside VMs to audit them and see if they’re configured the right way. And, if they’re not, you can create mitigation tasks to fix that.
But just because Azure Arc gives you the power to see workloads from other servers in your Azure portal doesn’t mean that everyone on your team has to see every workload. Similar to how RBAC in Azure can allow you to set permissions about who on your team has access to what apps and services, you can set the same kind of permissions across infrastructures.
For a while now, we’ve been able to onboard Azure Log Analytics from on-prem or other cloud providers. But there were issues around it when it came to RBAC. Thomas explains that while server admins of a particular log analytics workspace might need to look at the logs, they were also able to see all of that log's associated data—meaning they would be able to see other peoples’ servers and logs to that log analytics workspace.
With Azure Arc, that admin can be limited to a view for that specific server, instead. So you can run a query using Azure Log Analytics query language (formerly known with the codename Kusto), so you can get all the information about updates—which ones are needed, which are installed, which are available—even if the server isn’t connected.
So Azure Arc offers new capabilities when it comes to governing other servers and also improves on some of the Azure tools that previously existed around managing hybrid environments.
How does Azure Arc work?
You can easily see your other servers in the Azure Portal, but Azure Arc isn’t simply built into the portal; it’s also built into Azure API and Azure Resource Manager (ARM).
When you use Azure services, you interact with the platform in certain ways. When you use the portal, Azure CLI, Azure API, etc. you interact with ARM. Thomas refers to ARM as “the magic behind our management tools and how Azure actually deploys things.”
ARM takes care of subscriptions, logs, RBAC, policies, tagging, grouping, and all of the other services we use to manage Azure resources. With Azure Arc, Microsoft extended ARM for non-Azure resources.
Regardless of what your non-Azure servers are running, you can essentially install an agent on that machine that connects to Azure Arc, and then that will connect to ARM. ARM is what will make everything Azure Arc is capable of possible.
Onboarding non-Azure servers
So how do you onboard your on-prem or other cloud servers? You go to the Azure portal and navigate to Azure Arc. From there, you can go through a wizard that generates a script you can run on a non-Azure machine.
From there you have two options:
- Add machines using interactive script
- Add machines at scale
If you select the first option, you run the wizard-generated script and then login to connect your server to Azure. This option is best if you have a limited number of servers you want to onboard.
If you have hundreds or thousands of servers to onboard, you probably don’t want to take the time to connect to each server, run that script, then login to connect them individually. To automate that task, you can create a script with a service principal name, which allows you to onboard servers at scale.
In Thomas’s presentation, he demonstrates how to onboard servers using option one. First, you have to connect non-Azure servers to a subscription, resource group, and Azure region. (Because Azure Arc is in public preview, there are only four Azure regions available for connection right now.)
While you can add tags to non-Azure servers and resources in Azure Arc after they’ve been connected, you also have the option to add tags during the onboarding process right in the script. This helps keep your environment clean and organized right from the start.
Next, you review that generated script and then download and run it on your machine. The script is essentially three lines of code, so it’s pretty easy to modify according to you needs.
Once you download the script, it downloads and installs the agent, and then the script connects to Azure. After a few minutes the server will show up in your Azure environment. Easy as that!
Azure Arc supports Windows and Linux servers, physical and virtual machines, and on-prem as well as private and public cloud servers. Not only can you see all of these workloads in one portal, but you can control access through RBAC and push policies and audit your systems to discover non-compliance, which is essential for security.
Microsoft has other tools that help you work in a hybrid environment. But the simplicity and ease-of-use of Azure Arc’s new features make it very exciting.
For more details on how to use Azure Arc, you can watch Thomas’s presentation.