Out in the field with customers and partners, we hear an awful lot about what people think Azure Stack is and isn’t, what its capabilities are, and where it should or shouldn’t be used when needs arise for an on-premises solution.
“There’s no point in just moving existing VMs into Azure Stack, there are already established virtualization platforms with rich ecosystems which will run them just the same and for a lower cost'”
“Sure Azure Stack can run VMs, but it’s really designed as a PaaS first platform, not for IaaS.”
“Azure Stack is a platform for modern applications, there’s no point in just using it for VM workloads.”
“I already have an IaaS platform that I’m depreciating over the next four years, I don’t need another more expensive one to do the same thing.”
Each of the above is a commonly held belief about Azure Stack, and each of them is definitely built around a grain of truth, while at the same time missing or not embracing much of the larger picture around Azure Stack, and indeed Azure and other public cloud platforms.
To be fair this isn’t anyone’s fault in particular; Azure Stack is a nascent product, and as such messaging around it has pivoted multiple times since it was first announced over three years ago. It wouldn’t have been seemly to have been seen to be competing with Hyper-V in any way, and so it was announced and positioned as a PaaS-first play, bringing the rich goodness of Azure platform services back to the edge! While that’s still true, at the same time it really does do Azure Stack a massive disservice.
So firstly, let’s be clear – Azure Stack doesn’t replace Hyper-V, or VMware for that matter.
Secondly, Azure Stack is a brilliant IaaS platform for running VM workloads.
Ok, in retrospect, that wasn’t so clear – let’s break it down.
Virtualization, Advanced Virtualization, and IaaS are three distinct capabilities which are often conflated.
Infrastructure as a Service isn’t simply the ability to run virtual machines, it’s a set of management constructs on top of a hypervisor on top of a fully automated infrastructure which support and deliver the essential characteristics of a Cloud computing platform.
This isn’t a new message from Dell EMC, in fact it’s been consistent for quite some time now. Rather than rehash previously trodden ground, I’ll instead just recap with a link to Greg’s excellent blog below.
A lot has changed in Azure Stack in the last year and a half though, and that in and of itself isn’t surprising, nor should it be. Azure Stack updates are released on a regular basis, bringing with them new capabilities and improvements, including of course in the IaaS space.
Over and above the monthly updates, and far more importantly though, customers have now had their hands on Azure Stack for over a year since official GA launch, and we have a much better idea of the interesting, innovative, and sometimes downright cool scenarios they’re using Azure Stack for in the real world.
Of course the available Azure PaaS Services are used with gusto, that goes without saying – people prefer to use native PaaS features wherever they can! The Azure App Service and Azure Functions are my personal favourites. Below is a quick Twitter poll I ran, just to gauge if indeed this was general sentiment, and while decidedly unscientific, the results were interesting.
But while Azure Stack is indeed a great PaaS platform, it is definitely not a PaaS only platform, and nor for that matter is Azure by any stretch of the imagination.
Indeed one of the fastest growing parts of Public Azure today is through the migration of existing (appropriate) workloads into Azure as VMs, and don’t worry we’ll cover off what appropriate means a bit later on. This doesn’t involve any day one workload transformation or changes to how applications are running, it does typically bring some immediate benefits though, and those benefits are largely the same, or dare I say… consistent, in Azure Stack.
Firstly, and probably most importantly, you don’t need to design, deploy, or manage any of the underlying hypervisor or software defined constructs. All of the extremely complex virtual infrastructure which goes into running a platform like Azure Stack is delivered as an appliance, consistent every time.
In most businesses, large portions (if not the majority) of an ops team’s time and energy goes into the ongoing management of the infrastructure which supports their workloads. Azure Stack is designed to give pretty much all of that time back. In Azure Stack, all of the hypervisor components, the host OS, the software defined networking, the software defined storage, and everything that goes around and supports them is delivered as a turnkey solution, and then patched and updated automatedly as part of regular Azure Stack updates, albeit scheduled by you, the admin.
Each of the dozens of Virtual Machines running on top of the platform to support and deliver Azure Stack itself are locked down and delivered to you as a service. Azure Stack updates are delivered on a mostly-monthly cadence, and while they take some time to run, they are fully automated end to end. This includes not just the hypervisor and software defined constructs, but also the ongoing patch and update all of the virtual infrastructure required to deliver Azure Stack itself.
Through Dell EMC, OEM updates are also automated through our Azure Stack patch and update tool, a unique capability in the Azure Stack OEM market. One of the greatest benefits a true cloud platform delivers is automating you away from the hum drum to where you can spend your time most valuably. Where any part of that solution from bare metal to cloud isn’t automated, not only is there potential for human error and configuration drift, your valuable time is also being wasted. Today, uniquely, Dell EMC provides you both that consistency and that time back.
The second benefit to Azure Stack comes through its consistency with Public Azure. Any time and skills investment into learning Public Azure automatically translates to Azure Stack, and vice versa. Any infrastructure as code templates developed through the likes of ARM or Terraform can, with some caveats, work across each platform. Potentially most importantly though, Azure is a mature platform which has been around for many years now, and as such has a robust and well established community.
Many of the challenges you’ll encounter, solutions you’ll want to deploy, or knowledge you want to gain have already been round the houses in Public Azure. There are many, many public repositories of infrastructure templates out there in the community just waiting to be deployed, and many knowledgebases and courses ready to be scoured for knowledge.
Take the Azure Stack Quickstart Template Gallery for example. There are dozens of pre-built templates there covering a plethora of IaaS application use cases, everything from a single Windows or Linux VM to an Ethereum consortium blockchain infrastructure, and a huge amount in between. Each of these templates can be used as a starting point, or in some cases a finishing point, for deploying your own IaaS infrastructure in Azure Stack.
When you enter into the Azure Stack community, you also enter the wider Azure community, and having a community that well established and open is of incredibly value.
The Azure Marketplace is an IaaS-centric ‘app store’ for the cloud, where software vendors certify through Microsoft and then make available golden images of their software to anyone who wants to deploy it into Azure. Sometimes the resultant VMs are managed by you, sometimes they’re delivered as more of an appliance-based offering. Sometimes they’re a single VM, sometimes a whole infrastructure will be deployed to deliver the service requested.
The marketplace is one of the most well used parts of Azure, and again note that its focus is not in other Azure PaaS services. It’s in delivering as much value from IaaS as possible, giving you images you know you can trust, which have been battle-tested at hyperscale, and which are typically kept up to date by the very people who create the software running on them.
This same marketplace experience exists in Azure Stack, and through it you have the ability to choose which marketplace images you want to syndicate to your own Azure Stack. Every image isn’t downloaded by default, as they take up some space, so you choose what ones make sense to you, and then make use of them knowing that they’re the exact same images as you would deploy in Public Azure.
Benefit #4… to #n
There are many more benefits to ‘just’ running virtual machines in Azure Stack, from the automated patching of SQL workloads, to the continued three year support of Windows and SQL Server 2008/R2 workloads, to being able to access cloud constructs like object, table, and queue storage, to leveraging VM Scale Sets for horizontal scalability of traditional workloads, to pre-validation for compliance standards like PCI DSS, to service measurement for chargeback, to built-in load balancers, to built-in site to site VPN capabilities, to managed disks and the removal of VM disk and storage management, to extensions providing features to VMs like anti-virus and VM patch and update, to integration of those IaaS workloads with higher tier PaaS capabilities… and so it goes on. The benefits are myriad, and in retrospect should be unsurprising given the popularity of Public Azure for IaaS workloads.
An Azure Stack Operator does still have administrative tasks to carry out it’s true, but they are not the same as a virtualization admin, or even an advanced virtualization admin. As we’ve said, all of the underlying infrastructure that delivers the Azure services is delivered ‘as a service’, so as ever in cloud your attention is pushed higher, focusing on more rapid update cadence, capacity management, offering services, chargeback, and other more cloud-centric operating tasks.
Azure Stack doesn’t replace Virtualization
There are two core routes to IaaS workloads entering an Azure Stack:
If you’re deploying a fresh infrastructure, you may be doing it to create a new application, or to deploy your own in-house application, or to install a third party vendor’s application. For the first two of these, Azure Stack can provide a great platform assuming you follow cloud application development patterns for resiliency. For the third, you’re largely in the hands of the vendor. If they require specific hypervisor features, or shared storage between VMs, or specific CPU:RAM:Storage ratios, or high performance OS disks, or… well, all the same reasons an application can’t be deployed into Azure apply to Azure Stack.
There’s an enormous mass of software out there which will never be rewritten for a cloud-native environment, and yet more which is suited best to environments with more customizability than Azure or Azure Stack provides. For those workloads, existing virtualization platforms with their rich and well established ecosystems remain the best place to run them, even if deploying fresh.
If you are deploying a fresh infrastructure over which you have application control, there’s a whole host of cloud-native tooling available to transform how you design, manage, and maintain that application. Infrastructure as Code, VM Scale Sets, Service Fabric and Kubernetes templates, and more all exist to allow you to apply the same DevOps principals to your VMs in Azure Stack as you can in Azure.
Migrating VMs to Azure Stack is largely the same in principle as migrating VMs to Azure, and just like in Azure, serious consideration needs to be given to the workload and how (and indeed if) it will run well within the cloud environment. Typically some resizing will need to be done to fit an Azure Stack VM ‘t-shirt’ size, and testing will need to happen to ensure the workload performs as required in the bounds of Azure Stack IOPs limits. For these reasons and more, when evaluating Azure Stack as a platform it’s critical that you evaluate it against the workloads you’ll be running, not just the aggregate CPU/RAM/Storage you think you’ll need. .
Probably the most important consideration for any deployment or migration into Azure or Azure Stack is that these are platforms designed for cloud workloads. The most fundamental difference between a cloud workload and a traditional workload is that workload availability should be delivered and accounted for by the application, not by the infrastructure. That’s not to say that Azure Stack isn’t a highly available and resilient platform within a rack, it is, however if a workload needs to be but cannot be resilient (and in particular resilient across site or rack if needed) without traditional hypervisor or storage technologies, then it may not be best suited to run in a cloud platform.
Never Forget: Azure Stack is Azure
Azure Stack is undoubtedly an incredibly powerful IaaS platform, boasting features like the Azure Marketplace that don’t even exist in other on-premises platforms. If your workload can be deployed or migrated into Azure Stack, and it does perform well, then all of the above benefits will apply to it. You’ll find yourself with an up to date, patched and secure environment, which gives you the time back to start working on higher tier PaaS services without being additive to existing tasks.
Ultimately though the core of the matter is that when you deploy or migrate virtual machines into an Azure Stack environment, you’re not just making use of a hypervisor, you’re gaining the power, the ecosystem, and the community of the Azure Cloud, and that’s a glorious place to be.