Azure: fully stacked – the differences in HCI, Hub, Edge and Arc

(originally published in November 2019)

It was probably one of the biggest announcements at Ignite: Azure Arc. With that we now have a variety of options for so-called on premise solutions connecting to or integrated with Azure public cloud. During the week after Ignite I noticed that it left a lot of people a bit confused. We now have Azure Stack Hub, Azure Stack HCI and Azure Stack Edge. When we go into the Azure portal, we will find a new service available to bring on premise workloads under control of Azure: Azure Arc. Though the four (!) solutions seem to overlap, they certainly have different use cases.

Azure Stack HCI

Let’s look at Azure HCI first, since this solution probably has a lot of advantages for enterprises. The most important feature of HCI is that it can run ‘disconnected’ from Azure. To put it very simple: HCI works like the commonly known branch office-server. Basically, HCI – hyperconverged infrastructure – is a box that contains compute power, storage and network connections (little bit of commercial talk here: Fujitsu has its PRIMEFLEX hardware certified for Azure Stack). The box holds Hyper-V based virtualized workloads that you can manage with Windows Admin Center. So, why would you want to run this as Azure Stack then? Well, Azure Stack HCI also has the option to connect to Azure services, such as Azure Site Recovery, Azure Backup and Azure Monitoring. Azure Security Center? Nah. Not yet, although Microsoft has announced this.

As said, the Stack HCI solution works wonderfully as a branch office server. I’m currently designing a hybrid infrastructure for a prospect that is based on maximum use of the Azure public cloud. This customer also has warehouses and some small office locations that run some proprietary software that has to run on premise, partly for latency and partly for compliance reasons. On these locations HCI is planned. Next to the special software it will also host a domain controller, SCCM distribution point, and file- and print server.

It’s a very simple solution that only requires Microsoft validated hardware, the installation of Windows Server 2019 Datacenter Edition plus Windows Admin Center and optionally an Azure account to connect to specific Azure cloud services.

Read more on HCI following this link:

No alt text provided for this image

Azure Stack Hub

Now the confusion kicks in: Azure Stack HCI is the foundation underneath Azure Stack Hub (side note: all Azure products are based on Windows Server 2019). Yet, Hub is a different solution. Whereas you can run Stack HCI ‘stand alone’, Hub is an integrated solution with Azure public cloud – and that’s really a different ballgame. It’s the reason why you can’t upgrade HCI to Hub.

To put it very simple: Azure Stack Hub is really the on premise extension of Azure public cloud. Almost everything you can do in the public cloud, you could also deploy on Hub: from VM’s to apps, all managed through the Azure portal or even Powershell. It all really works like… eh… Azure, including things like configuring fault and update domains. Personally, I like this feature on Hub the best: Hub supports having an availability set with a maximum of three fault domains to be consistent with Azure. This way you can create high availability on Hub, just like in Azure.

The perfect use case for the use of Hub and Azure public cloud would be to do development in public cloud and production on Hub, if apps or vm’s need to be hosted on premise for e.g. compliance reasons. The good news is that you can configure your pipeline in such a manner that development and testing can be executed on public and run deployment of the validated production systems including desired state configuration to Hub. This will work fine since both ‘entities’ of the Azure platform use the Azure resource providers in a consistent way. There are a few things to be aware of, though. The compute resource provider will create its own vm’s on Hub. In other words: it does not ‘copy’ the vm from public to Hub. The same applies for network resources. Hub will create its own network features like load balancers, vNets and NSG’s. As for storage, Hub does allow you to deploy all storage forms that you would have available in Azure public, such as blob, queue and tables.

Read more on Hub following this link:

Azure Stack Edge

Bringing your data to the cloud, or the cloud to your data? That’s the question and if it’s cloud-to-data then Azure Stack Edge is the solution. Previously, Microsoft ‘sold’ Azure Stack Edge as ‘Data Box’: it’s still part of the Data Box-family. Edge makes it easy to send data to Azure. As Microsoft puts it on their websites: Azure Stack Edge acts as a network storage gateway and performs high-speed transfers to Azure. The best part? You can manage Edge from the Azure portal.

Sounds easy, right?

Hold on. There’s more to it. It’s called Kubernetes. Edge runs containers to enable data analyses, perform queries and filter data at ‘edge’ locations. Therefor Edge supports Azure VM’s and Azure Kubernetes Services (AKS)-clusters where you can run containers on. Edge, for that matter, is quite a sophisticated solution since it also integrates with Azure Machine Learning. You can build and train the models in Azure, run them in Azure Stack Edge and send the datasets back to Azure. For this the Edge-solution is equipped with FPGA  (Field Programmable Gate Array) and GPU (Graphics Processing Unit), required to speed up building and (re)training the models.

Having said this, the obvious use case  comes with the implementation of data analytics and machine learning where you don’t want raw data to be uploaded to public cloud straight away.

Want to explore Azure Stack Edge? Then this is the best place to start:

Azure Arc

Now, last but not least… let’s look at Azure Arc. To be honest: I was surprised by the announcement and reading reactions on Twitter and in blog posts, apparently I was not the only one. However, it sounds awesome: connecting non-Azure machines to Azure and be able to manage these servers through Azure. It’s a great new feature, but… it requires quite some effort to get it to work properly. It’s not as easy as it sounds. That will improve over time, when the product becomes more mature (it’s in preview at this time).

The new service is available from the Azure portal.

No alt text provided for this image

So far, so good. Before you can actually do something with Arc, you need to ‘appoint’ a machine that you want to bring under control of Arc. Right now, Arc only supports a limited number of machines: Windows Server 2012 R2 or newer and Linux Ubuntu 16.04 and 18.04.  If you want to connect a machine to Arc, you need to install an agent on that machine. It will then get a resource ID and become part of a resource group in your Azure tenant. However, not after you configured some settings on the network side of things and registering the appropriate resource providers (Microsoft.HybridCompute and Microsoft.GuestConfiguration). Yes, this does require proficient Powershell-skills.

If you perform the actions successfully, then you can have non-Azure machines managed through Azure. In practice this means that you can add tagging and policies to these workloads. That sort of defines the use case: managing the non-Azure machines against the same policies as the Azure machines. These do not necessarily have to be on premise. That’s likely the best part of Arc: it also works on vm’s that are deployed in AWS. Still, there’s a lot of configuration to do getting Arc to work.

Again, Arc is in preview, so the expectation is that the service will improve over time when it becomes GA.

The key take-away: Azure Stack is now providing a range of solutions that can be right-fitted to different use cases. And although Arc is not part of the Azure Stack portfolio, it should be perceived as one of the possible solutions to extend Azure to other platforms.

Ready to do some experimenting? Here’s the link to the quick start:

Good luck!