How to run Azure services on your own servers

At first look, the big hyperscale public clouds are much the same; they offer similar services and charge similar prices. But each has its own specialty as a result of its parent company’s history. For Microsoft, it’s a strong focus on hybrid cloud, understanding that there will always be reasons why workloads don’t leave on-premises data centers, due to either data sensitivity or government regulations.

It’s a commitment that goes both ways, providing tools for quick migration of data and services, using cloud resources for non-sensitive, unregulated data when what’s on-premises is insufficient, and bringing its Azure management tools to your data center, with either Microsoft’s own hardware in Azure Stack, approved third-party hardware with Azure Stack HCI, or its Azure Arc application management tool.

Building on Azure Arc and containers

The evolution of Azure Arc has been interesting to follow. Originally intended as a tool for managing on-premises application virtual infrastructures via the Azure Portal, it’s added support for data services and for Kubernetes container orchestration. It’s that last option that’s the most interesting, as building on a version of Azure’s own Kubernetes management tool is a quick and easy way to manage a Kubernetes environment that doesn’t require deep knowledge of Kubernetes deployment and configuration.

Azure Arc’s Kubernetes tool has another role to play beyond hosting your own cloud-native applications on your own hardware. Behind the scenes, Microsoft has been rearchitecting much of the Azure platform services. While they’ve always been microservice based to support rapid scale out, they have run using Microsoft’s own virtualization technologies. That’s slowly been changing, moving them from dedicated Windows Server instances to running in containers and using custom Kubernetes extensions and services to support containerized code.

A shift to containers, along with Kubernetes support for Windows and Linux containers, has allowed Microsoft to generalize its own internal Azure hosting, using Kubernetes and related technologies to improve scaling and to make those containers portable. We’ve already seen some of that portability in action in Azure IoT Hubs running on Azure Stack Edge hardware, putting compute capability where it’s needed rather than relying on questionable bandwidth.

The next logical step is bringing portable application containers to any Azure-managed platform, using Arc’s Azure Kubernetes as a host. This approach allows you to run Azure services where your code is, with Arc supporting not only on-premies systems but also infrastructures hosted on AWS or Google Cloud. If you’ve taken a dependency, say, on an Azure Function, but want to include it in an app that’s running in your data center and multicloud on Azure and AWS, now you’re not limited to translating your Function code to work as an AWS Lambda.

As always, this approach is a trade-off. You’re taking a dependency on Azure Arc and will need to manage it on all the platforms you’re using. However, you now only have to develop your app code once. There’s no lag between different versions and different platforms and no need to work to common APIs, reducing risk and giving you as much multicloud reach as you want without lowest common denominator compromises.

Setting up Azure Arc’s App Services support

Running application services through Azure Arc requires a registered Kubernetes cluster. You can work with any running cluster on any platform as long as it supports the Cluster API and you have installed the Azure CLI on your Kubernetes system. It’s important to remember that Azure Arc is a way to manage the applications running on a cluster, not the cluster itself. There’s a distinct dividing line between what Arc does and what you need to do to manage your platform. You can think of this as a distinction between infrastructure management and platform and application management. You need to manage your cluster as part of your infrastructure, while Arc handles platform services and applications running in Kubernetes.

To connect a cluster, use the connectk8s Azure CLI extension and make sure that your cluster can connect to the required Azure endpoints. You may have to configure your firewall for this before connecting to Arc. Once you’re able to connect, register the Arc provider and connect it to an Azure resource group in a local region. The Azure CLI tool downloads and runs a Helm chart that adds the certificates and IDs needed to make the connection, deploying a set of pods for its management agents.

Once a cluster is managed by Azure Arc, you can deploy the Azure application services extensions on your cluster. The service is still in preview, so you’re limited to working in either the Eastern United States or Western Europe regions. You’ll next need to install an App Service extension to your cluster, first setting local environment variables to hold the extension name, its namespace, and a name for the overall environment. You can then use the Azure CLI to install the extension to your cluster.

Microsoft provides a sample script to install and configure the App Service cluster and pods, adding a service account, namespaces, and other key configurations. Installation can take some time, so be prepared to wait before you configure the Arc side of the service. Here you’ll set up a custom location for Arc to use before creating the App Service environment. Once it’s up and running you can start to create and deploy your applications. Usefully, you can configure support for Kubernetes event-driven autoscaling (KEDA) as well as Kubernetes’ default resource-driven approach. You should find KEDA support useful if you’re running serverless Azure services such as Functions or Event Grid.

At this stage in its development, Azure App Service support for Azure Arc isn’t for beginners. It requires an existing Kubernetes environment and experience in managing both Kubernetes and Azure from the command line. There’s guidance from Microsoft, but you’re going to need to customize scripts to fit your environment, whether it’s on-premises or running on a public cloud.

Building and delivering code to Azure Arc App Services

Microsoft is rolling out a wizard-based approach to deploying services to a connected cluster from the Azure Arc portal. This creates the appropriate resources and installs the appropriate extensions. You can then use it as a target for deploying resources, treating them as custom locations alongside Azure’s own regions. This lets you use existing Azure development tools, such as Visual Studio Code, to work against your Arc resources.

Once Azure Arc support for Azure App Services moves out of preview, it will give you the same familiar development and operations experience as working with Azure directly, treating your resources as alternative sites for Azure services. That does mean ensuring they’re configured in advance, giving your Azure administrators new responsibilities and requiring new relationships within your devops teams.

The resulting multicloud capabilities take advantage of Kubernetes’ common APIs, which are supported by most distributions, from the edge to the public cloud. Code developed on-premises or in Azure can run on any supported platform, ready to be deployed where the data is. As more Azure services take advantage of Azure Arc’s Kubernetes support, multicloud support for platform services will become as common as working with cross-cloud virtual infrastructures, increasing the reliability and availability of platform-as-a-service-based applications by removing their single point of failure.