What is Azure Stack?

Thursday , 23, June 2016 Leave a comment

I suffer from what is probably a common affliction in our field – I assume that everyone reads the same articles, attends the same webinars, and goes to the same conferences as me. Over the past few weeks though I’ve had to answer the titular question quite a number of times, I’ve also been asked a few times when we’re upgrading our Hyper-V/WAP platform to Azure Stack, so figured it worth writing a short blog on the subject.

To understand Azure Stack, you first need to understand a few fundamentals about it:

  • Azure Stack is not an upgrade to Hyper-V – it’s a whole separate product, however…
  • Azure Stack does make use of Hyper-V 2016, and…
  • It runs on top of Storage Spaces Direct…
  • … but it cannot run on an existing Hyper-V environment. It’s a greenfield installation.
  • Critically, Azure Stack is Azure. Not Azure-lite, not Azure-like, not an imitation, it’s Azure.

Not virtualisation plus, not an abstraction of System Center, Azure Stack is the Azure codebase slightly tweaked to run in smaller environments. Azure Stack is Cloud.

More than that, Azure Stack is the fulfilment of a multi-year old promise from Microsoft – true hybrid cloud. Whether you consume Azure from your own datacentre, from a service provider, or from Microsoft, the experience is the same, your applications will work the same

This is utterly unique and compelling capability. It draws back the veil on Azure, increases knowledge and confidence in that platform, and democratises cloud in a way not just that no one else is doing, but in a way that no one else is capable of doing.

Finally in Azure Stack the term ‘Cloud OS’ makes sense. If you think about the Windows operating system, you can buy a laptop, or a desktop, or components to build your own PC as you please. Your hardware can be super-powerful and enable extra functionality in Windows, or it can be lightweight and cheap and use a core of base functionality. Whatever hardware you run it on though, Windows is consistent, and applications written for it (assuming the hardware is capable) will work.

Azure is the Operating System for Cloud.

You can deploy your own Azure Stack on-prem, you can consume it from a service provider, or you can take it direct from Microsoft’s hyperscale cloud, and the experience is the same. Your choice now that drives the decision of where your applications run comes down to cost model, scale requirement, regional or global needs, latency, support, vertical integration of applications, and so on.

Critically, in just the same way as you have choice in your hardware vendor for your computer – moving between Dell, Microsoft, HP, Lenovo et al at will with Windows being the point of consistency, Azure enables simple movement between providers depending on your wants and needs at the time, with the knowledge that your applications will continue to work, and won’t require conversion or re-architecture.

This is a weird concept, but I think it’s an important one – architecting for Azure, using your DevOps tools of choice, removes the risk of vendor lock in. The vendor here isn’t Microsoft, it isn’t Azure – Azure is the cloud operating system, the vendor delivers Azure.

Azure Stack doesn’t replace Hyper-V

Let’s get this straight – to me, Hyper-V 2016 is often a better platform for running traditional VM workloads than Azure Stack. We have the same software defined networking stack in Azure Stack and Hyper-V 2016 now, and all the same cost/performance benefits inherent in Storage Spaces. Importantly, because Azure Stack is Azure Consistent, there are capabilities inherent to Hyper-V 2016 that it cannot make use of. If a feature doesn’t exist in Azure, it doesn’t exist in Azure Stack – consistency is king, and needed to ensure guaranteed portability of applications. That means that IaaS in Azure Stack misses out on…

Generation 2 VMs

VHDX and Shared VHDX

Shielded VMs

Encryption Supported VMs


Secure Boot

SCSI Support

Faster boot times

… and probably more that I’m forgetting. Additionally, because Azure Stack is Azure, VM sizes can only be consistent with those in Azure. Hyper-V 2016 remains a much more suitable platform for pure virtualisation and running existing 1/2/3 tier monolithic workloads. 

Even once those features come to Azure, if they do, a cloud platform may not be the right place for some workloads – much in the same way as some workloads still benefit from running on physical servers vs virtualised, some workloads are best suited to running on a traditional virtualisation platform.

Virtualisation is not cloud. Cloud is a leap step beyond Virtualisation, and requires a new mindset in order to take full advantage of it.

Finally, in some ways Azure Stack actually improves upon Azure. We have choice in our storage – we can put whatever (supported) combination of NVME, SSD, and HDD we want in our Azure Stack servers, delivering consistent storage performance in a way which public clouds just don’t. Azure (and other public clouds) have no concept of live migration – if a host goes down, the VMs on it go down. This is not true in Azure Stack, as it can make use of Hyper-V live migration, so we get better individual VM SLAs by default.

This is actually a key concept in Cloud – architecting for application resiliency so individual VM availability doesn’t matter, so it’s interesting that it’s not as important in Azure Stack. One of many thoughts to ponder.

So then – what is Azure Stack?

Azure Stack is Azure.

Azure Stack is the fulfilment of the hybrid cloud promise.

Azure Stack significantly mitigates the risk of cloud-vendor lock in.

Azure Stack makes Azure the ultimate developer-first cloud platform.

In my opinion, Azure Stack is the most revolutionary advancement in the cloud industry since the formation of the cloud industry.

We are so used to caveats and limitations in on-prem and service provider hosted platforms vs the hyperscale clouds that it’s almost a shock that we now have the same capabilities available to us. Now we can use hyperscale where hyperscale makes sense, use regional when regional makes sense, and use local when local makes sense.

Leave a Reply

%d bloggers like this: