Microsoft has been running Arm servers as part of Azure for some time now, initially with Altera Ampere hardware, but now with its own Cobalt 100 hardware. The Cobalt processors are based on Arm’s Neoverse architecture and were first announced nearly a year ago, with a limited preview.

The hardware is now generally available, with servers located in Azure regions around the world. Not every Azure region has them yet, but as the new racks are rolled out, the servers will be deployed at more data centers. As they use less power and operate at higher density than other Azure hardware, you should expect to see them everywhere, as their deployment will help Microsoft keep Azure costs down.

Microsoft’s long history of custom silicon

Developing its own server silicon isn’t a new move for Microsoft and Azure. It’s already developed its own network hardware, including over-the-wire compression chips and a controller that works with multiple flash memory cards. Much of its focus has been on reducing the costs of running massive data centers with many thousands of customers. Keeping both bandwidth and storage costs down is key to delivering the necessary efficiencies.

That’s why it’s moved to developing its own processors, part of what it calls an “end-to-end systems approach.” Microsoft is also optimizing the software it uses with a focus on improving performance over the previous range of third-party Arm servers.

Microsoft’s quoted performance figures seem promising. A two-times performance boost for .NET applications is a definite improvement, especially when that’s code running on a machine that’s nominally around 50% faster than its predecessors. Some of that improvement is down to new storage and networking options, which are part of any Azure hardware upgrade. Microsoft suggests that there’s a 50% price/performance improvement over its previous generation of Arm hardware.

Why Arm in Azure?

The obvious question, then, is what are Cobalt-based VMs for? If we’re to take a hint from AWS’s Graviton Arm hardware, the focus is going to be scale-out and front-end workloads where there’s a benefit in having a lot of low-power, low-cost servers with the performance we need for distributed applications. You can expect Microsoft to push Cobalt as a host for Azure Kubernetes Service (AKS). At the same time, Cobalt is likely to be a deployment target for Arm-based .NET applications and containers.

For now, the fully managed Azure Container Apps supports only x64 container images, but as Cobalt rolls out that’s likely to change, if only because of the density advantages of Arm-based servers. As Microsoft is already using its Ampere Altera Arm hardware for many of its own services without affecting operations, it’s more than likely that these will migrate to Cobalt to take advantage of its performance improvements.

One interesting use case for this new hardware is to support GitHub Actions. If you’re using Cobalt to build and test Arm applications, for example, for Windows on Arm PCs, you can self-host a GitHub Action runner on a cloud-hosted build system, allowing you to build, test, package, and deploy without leaving an Arm environment.

Choosing an Arm virtual machine

There are three classes of Cobalt-based virtual machines designed to support three different sets of use cases, with the key difference being the amount of memory available to your VMs.

The first, the Dpsv6 and Dpdsv6 VMs are intended for most general-purpose compute and most common cloud-native workloads. You can configure them with up to 96 virtual CPUs and 384GB of RAM.

If you don’t need as much RAM, you can take the second option, the Dplsv6 and Dpldsv6 VMs that offer the same number of vCPUs and up to 192GB of RAM. These work well for small workloads, for example, the various components of a microservice architecture.

At the other end of the scale, the third option, are the Epsv6 and Epdsv6 VMs. Here you can configure up to 672GB of RAM, alongside 96 vCPUs. This is suitable for applications that need a lot of in-memory data, allowing you to use Arm hardware for services like Redis. The three different memory models offered by Azure look likely to cover most of the scenarios you’d expect for a modern cloud-native application, allowing you to choose different VMs for different parts of your application.

There’s a wide choice of storage options, with support for all Azure’s remote storage options. If you choose a Dpdsv6, Dpldsv6, or Epdsv6, your VM will come with local NVMe storage (the “d” stands for disk), so you will need a NVMe-ready operating system. Storage amounts vary with the number of vCPUs, starting at 110GB for a 2-vCPU system.

One important point to note with Cobalt hardware is that you’re limited to either Windows client or Linux; there’s no support for Windows Server at this point. I understand that Microsoft has its own internal Arm builds of Windows Server, but they’ve never been publicly released. That may be because of differences between how Arm and x64 hardware handle virtualization and drivers, which can cause issues.

However, economics and customer demand are both powerful forces, and although the Arm transition is in its early days, it’s likely that Microsoft will eventually add a Windows Server build to its Arm platform—if only to support migrations of existing applications to new, lower-cost, infrastructure.

Getting started with Cobalt

Working with Cobalt hardware is no different than working with any other piece of Azure’s fleet of infrastructure elements. You can use an Azure Resource Manager tool to set up a VM. That includes third-party infrastructure-as-code tools such as Pulumi or Terraform.

So, for example, if you’re using Azure Kubernetes Service, all you need to do is add an Arm-based node pool to your AKS cluster by setting the VM size and name for the Cobalt VM you’re planning on using. You can find this in the VM documentation. For example, if you’re intending to use a 2 vCPU Dpsv6 node with 8GB of RAM, set the node size to Standard_D2ps_v6.

Using Cobalt should be as easy as choosing the right VM and compiling code for Arm64. Thanks to devices like the Raspberry Pi, there’s a mature Arm Linux platform ready for use that supports all the platforms, tools, and services we use, from .NET to Kubernetes. Devices like Microsoft’s new Arm-powered Surfaces run Arm Linux binaries in the Windows Subsystem for Linux, giving you a desktop Arm development environment to build and test Arm-based containers.

With plenty of development tools available, it’s simple to move your code to a platform that requires less power and less space for large-scale compute applications. Hardware like Cobalt shows that we’re well past the days of thinking of Arm as a technology for endpoint hardware on the edge of our networks. Azure’s adoption of Arm has shown that it’s more than ready for the enterprise and the data center.