The last few years have been interesting, especially for a Microsoft infrastructure-oriented guy like me. We’ve seen the change from just providing virtual machines and storage to the DevOps world and providing platforms in real-time instead of delivering when asked. The cloud was of course the biggest competition for the IT professional, as developers and other departments within the company could consume cloud services very easily, without the IT professional, and create the needed infrastructure themselves. Hopefully using API’s and application templates such as ARM templates.
In this development orientated world there is no time for waiting on an IT professional to create a resource for you. We need to provide endpoints so that developers can use infrastructure-as-code solutions, talk to API’s to provision infrastructure and so on.
Although Microsoft first attempt at enabling cloud on-premises was Azure Pack, the solution to this has been Azure Stack [Hub] the past years. Azure Stack [Hub] delivers that consistent experience with Microsoft Azure, providing Azure PowerShell, Azure CLI, Azure REST APIs, and client SDKs to your on-premises environment, where the local instance of Azure Resource Manager (ARM) makes the awesomeness sauce.
Azure Stack [Hub] is delivered as turn-key appliance, meaning you cannot, and should not, manage the hardware or hosts like you normally would in a Hyper-V environment. The key advantage of Azure Stack [Hub] over your on-premises Hyper-V environment from a workload perspective is that it comes with PaaS providers, enabling consumers of Azure Stack [Hub] to benefit from services like Azure App Services, Database-as-a-Service, IoT Hub and EventHub. The security and governance layer that ARM introduces is unmatched by any other on-premises solution.
Well, the best we have with a traditional Hyper-V environment is System Center Virtual Machine Manager (SCVMM) where you can deploy virtual machine workloads. We could use the ‘Service Provider Foundation‘ which is a role installed as webservice that is hooked into your environment and provides an API layer for SCVMM. Nothing compared to the capabilities of ARM, in terms of workload and the consistent experience from a developer perspective with Microsoft Azure.
In the meanwhile, VMware is bringing an “Azure Resource Manager like” solution called ‘Project Pacific‘ to on-premises based on Kubernetes using Kubernetes Custom Resource Definitions (CRDs). They clearly see the opportunity of enabling developers to make use of VMware environments, either running on-premises or hosted by AWS and Azure.
Azure Stack rebranding
At Microsoft Ignite 2019 there were a lot of announcements in terms of Azure Stack, especially the rebranding stood out. Azure Stack is not a product name anymore but a family name where ‘Azure Stack’ the product is renamed to ‘Azure Stack Hub’. Also Azure Data Box is being renamed to match the Azure Stack family and is now known as ‘Azure Stack Edge’
Last year, the Windows Server Software Defined (WSSD) program was already renamed to Azure Stack HCI in conjunction with Windows Server 2019.
Family of three now, many more to come? Who knows.
Introducing Azure Arc
Azure Arc is a brand new way to make use of all management capabilities that Azure has to offer in terms of governance, policies, security. Azure Arc is paving the way for environments other than Azure Stack Hub and Azure itself to make use of Azure Resource Manager. It connects to infrastructure in your own data center or another cloud, whether that’s bare metal, VMs or Kubernetes back to the Azure management infrastructure.
This way you can, for example, configure Role-based Access Control (RBAC) through Azure for VMs that are running on your Hyper-V environment in your basement and tag it as ‘Test server’ using Azure Tags.
And still you can have your local tools to manage that infrastructure yourself if you’d like.
When taking a closer look at Azure Arc and the inner workings we can see that Azure Resource Manager (ARM) has specific Resource Providers (RPs) for Arc included and they talk to the Arc agents running wherever. Azure Arc is the name of the ‘shell’ that combines the management experiences, ARM and the specific Resource Providers made for Hybrid environments.
Azure, Azure Stack Hub & ARM
Azure Stack Hub brings Azure Resource Manager and Resource Providers to your datacenter. It is running its own instance of ARM per Azure Stack Hub deployment. It also comes with its own Resource Providers. These Resource Providers talk to the controllers which will execute the operation on the infrastructure, for example to provision a database. If we look further into how the Database-as-a-Service in Azure Stack Hub works, we first have to download the Resource Provider software and install it on a virtual machine, after that register the RP in ARM so that ARM and thus the Azure Stack Hub environment is aware of it. Then when have to setup a ‘Database Hosting Server’, which is just SQL or MySQL Server running inside a virtual machine, and add it through ARM using the SQL endpoint. In other words, ARM is talking through different layers with SQL and can provision stuff such as databases and accounts.
Microsoft Azure is using the same concepts, probably not the exact same software for the RP, but the concept is very similar.
In the introduction I stated that the key-benefits of Azure Stack Hub from workload perspective are the PaaS services like App Services, Database-as-a-Service, IoT Hub and EventHub, but also IaaS is quickly overlooked but still important. If we keep using Database-as-a-Service as example and zoom in what Azure Stack Hub manages, it’s only the ARM layer. You still set up the Resource Provider yourself, setup your SQL infrastructure yourself, manage the Active Directory domain they are a member of yourself and all the maintenance as well such as Windows Updates, product updates etc. They are just VMs that you deploy using ARM templates and then point ARM to the endpoint provided. The same goes for Azure App Services.
You can actually download the software and run it anywhere, but you don’t have a management control pane such as ARM to manage it unless you have Azure Stack Hub running.
The word got out last September about Project Saturn, to quote ZDNet:
“Microsoft’s ‘Project Saturn’ is an effort to rearchitect its Azure Stack hybrid computing platform and, possibly one day, to allow key Azure services and APIs to run anywhere.”
Also the release notes of the 1905 update of Azure Stack show the following:
I think a lot of effort is going into the rearchitecting of services to containers, as not much new functionality has been released the past months and also the IoT Hub and Event Hub services have been in preview for some time but have still not been released.
Azure Stack HCI
Now that we know how Azure Stack Hub manages the PaaS infrastructure and also know that Arc is leveraging the ARM layer and extends the functionality of ARM to any location, we can connect it to Azure Stack HCI.
There are some coincidences happening:
- Azure Stack Hub Services are ‘potentially’ being containerized
- Azure IoT Hub already can run on any Kubernetes cluster
- Azure Cognitive Services can run already on any Kubernetes cluster
- Azure Kubernetes Service (AKS) is GA on Azure Stack Hub
- Azure ARC has been announced
- Managed Azure SQL Instance and Azure Database for PostgreSQL Hyperscale can run on any Kubernetes cluster using Azure Arc
- Kubernetes support for Azure Stack Edge has been announced
- Kubernetes support for Azure Stack HCI has been announced
My Future predictions:
- Azure App Services will run on any Kubernetes cluster
- Azure Event Hub will run on any Kubernetes cluster
This is where it gets interesting from an Azure Stack HCI perspective.
I have introduced Azure Stack HCI in the diagram above, in conjunction with the Azure Arc Agent. As stated in the introduction, Microsoft on-premises infrastructure never had a real management service that provided REST APIs and this is where Azure Arc steps in. It’s like a blanket over the on-premises infrastructure enabling everything Azure Resource Manager has to offer.. a much needed blanket for sure.
Not only are we getting REST APIs but also all the security and governance features that Azure Resource Manager includes.
Let it sink in for a second.. You can set Azure Tags, Azure Policies, RBAC policies on VMs that run on Azure Stack HCI. On top of that Azure Stack HCI can run any ‘Azure Services’ that has Kubernetes support.
The one thing that is missing in the announcements is the ability to manage core infrastructure roles such as compute, network, storage using Azure Arc. Right now Azure Arc focusses on the top layer services which run on any infrastructure (because of Kubernetes).
Are we only going to be able to deploy and manage Azure Services from Azure to a Kubernetes cluster running on Azure Stack HCI?
We already can manage VMs through Azure Arc, You really thinking we are not going to be able to deploy VMs from Azure to Azure Stack HCI? Really Really?
Last week the System Center team released a survey on self-service needs, this was one of their questions:
Still not convinced? 😀
I touched a lot of topics this blog, the main direction I’m pointing at is that Microsoft is making infrastructure irrelevant from a cloud consumer perspective. I always keep repeating “Cloud is not a place, it is a model”. Azure Arc brings the cloud model to any place. No matter where your infrastructure runs.
Is the role of Azure Stack Hub changing because of this? possibly.
Azure Arc is bringing a key benefit of Azure Stack Hub to any location, Azure Resource Manager. But you’ll need internet accessibility for it so it does not work in disconnected scenario’s.
The messaging on Azure Stack Hub seems to be more focused on disconnected scenario’s lately:
Any infrastructure that can run ‘Azure Services’ in conjunction with Azure Arc can have the same standards as Azure Stack Hub on governance, data sovereignty, application modernization capabilities and so on.
Azure Stack Hub is the only solution that can run ‘Azure Services’ completely disconnected.
Azure Stack Edge gets the ability to run services on Kubernetes, virtual machines and high availability support. If they are going to support high availability that must mean that they are going to support multiple nodes running the same service, maybe even in a cluster.
*Plot twist* Microsoft could position Azure Stack Edge next to Azure Stack HCI eventually, they can do the same: Run infrastructure. Azure Arc can manage that infrastructure.
Azure Stack HCI isn’t just a virtualization platform anymore, it’s becoming a true hybrid cloud solution with the use of ARM through Azure Arc and all the cloud native management and security capabilities. Also features such as Azure Extended Network and all the hybrid services Azure is already offering is helping to pave the way. I think we can safely state that the Azure Stack family supports a true hybrid cloud solution.But, with Azure Stack HCI you still manage the infrastructure yourself. If this is something you or your company doesn’t want to do, Azure Stack HCI is not for you and you should take a look at Azure Stack Hub or a Service Provider that hosts the infrastructure for you.
According to ZDNet, the Azure Arc introduction is what Mark Russinovich is considering “a huge part of what we’re calling Hybrid 2.0.,” while ZDNet states that Azure Stack Hub was Microsoft’s Hybrid 1.0 play.
It seems like all things happening the last year and the announcements on Ignite 2019 are part of a bigger story. If you take the pieces of the puzzle and put them together you can see the picture of Hybrid Cloud in a Microsoft world forming, but not all pieces are there yet..
If you made it all the way here, thank you!
Are you thinking I am going nuts? Would love to hear your opinion.
– Darryl van der Peijl