Over the last year, I’ve been involved in a journey that is changing my core competency in the technology industry.  My employer, a managed service provider, has been working with Microsoft in the Early Adopter Initiative in their hybrid cloud space.  Azure Stack is the name that it goes by and what I want to try to do to educate on what exactly this solution is trying to provide and what it means to those that are still in virtualization centric shops.  The goal of this isn’t to go into major technical detail and incite any sort of great tit for tat Twitter war between any factions that are perceived competitors to this product.  The goal is only to offer up the basics to those that are curious about Azure Stack.  Without further ado, let’s get into our first point about Azure Stack.

A Virtualization Replacement Product?

One of the common fallacies you hear about Azure Stack is that the primary use case for it in an enterprise or service provider environment is that of a replacement for a currently running virtualization platform.  I mention fallacy here because Azure Stack, while powered by a virtualization technology (Microsoft Hyper-V) is so much more than just a virtualization platform.

In the Microsoft messaging, they want everyone to understand that Azure Stack is more about enabling cloud consumption models than it is about just virtualization.  In that sense, Azure Stack is being positioned as having the same look and feel of public Azure in your own datacenter.  The platform has inclusions for many traditional IaaS capabilities, but also has many PaaS capabilities to push towards the application layer as the primary delivery within the platform.

In fact, some of the early Microsoft messaging in the Early Adopter Initiative was focused around the concept of data sovereignty.  There exist many industries in which data that is generated is subject to laws and regulations as to where that data can exist.  This was a heavy barrier to overcome towards adoption of public clouds.  Also, very few platforms exist to be able to provide more robust cloud consumption models in a private fashion.  Microsoft felt it was a good location to focus Azure Stack, so that many of these industries could now try to take advantage of public cloud consumption models within the walls of their own datacenters (or within service providers within data jurisdictions).

I Thought You Said This Was Hybrid Cloud?

Honestly, it’s a mix of both public and private cloud.  While Azure Stack is the private cloud implementation side, there are many integration points between Azure Stack and public Azure.  Technically, there are two implementation types of Azure Stack that exist out there.  What distinguishes between the two implementation types comes down to identity source (Azure Active Directory [AAD] and Active Directory Federation Services [ADFS]) and the licensing model in which you need to operate.

Focusing on the identity source, if you are using AAD for authentication, you are not running in a disconnected state and will refer back to public Azure for authentication purposes.  ADFS allows for you to use localized authentication and will not refer to public cloud identity sources for authentication.

Outside of the technical definition for hybrid cloud, Azure Stack and Azure share the same toolsets for management.  Consistency is the name of the game when Microsoft discusses how each is managed.  Both Azure Stack and Azure use the same subset of tools for management.  This includes their respective portal pages, PowerShell integrations, and integration into coding tools (for example, Visual Studio or Visual Studio Code).  Both implementations can be configured use Azure Resource Manager (ARM) templates.  Within an ARM template, all the information (in JSON format) that defines the infrastructure use and configuration of the solution you wish to deploy is contained.  This concept is used in both public Azure, as well as Azure Stack.  One caveat, however, is that when dealing with Azure Stack, the API versions will likely lag behind that of the public versions.  However, there are tools to help drive policies that ensure that whatever ARM template that is created in public Azure is also using versions that are compatible with Azure Stack.

I Can Roll My Own Hardware?

Short answer?  No.  This is likely going to be a major point of contention for many of you.  However, Microsoft has many perfectly valid reasons for needing to control the hardware information in their stack.  First, the sheer amount of validation needing to be done across the multitude of drivers within Windows for the various parts of Azure Stack would ensure a HCL that would take way too long to certify.  Secondly, there are security concerns within the computing environment that many vendors may not have in some of their server lines yet.  For instance, I found out that TPM 2.0 is a requirement of Azure Stack certified equipment.  During a Microsoft Ignite presentation, it was revealed that not many vendors have TPM 2.0 standard on most of their server lines.  As of right now, only four vendors have equipment that can be purchased.  This list includes:  HPE, DellEMC, Lenovo, and Cisco.  Many other vendors are going to be forth coming.

Also, major certification of networking components is an absolute need of the platform.  The storage system with Azure Stack is powered by Storage Spaces Direct (S2D), which requires offloads, not on only on the NIC layer in the servers, but also on the switching layers for RDMA (Remote Direct Memory Access).  Also, optimizations for VXLAN on both the NIC and switching layers for usage with the Azure SDN layer for network management were an absolute must.

Final Thoughts

In the scheme of things, I know there are some points of contention with this product versus what many infrastructure folks have ran in the past.  Not being able to choose your own hardware is one that I have seen many blog posts and opinion pieces on.  However, Microsoft has the marketing message that the point of this solution isn’t to operate hardware and worry about low level nerd knobbery within top-of-rack networking equipment.  The point is to hit the ground running and focus on the cloud consumption capabilities of the solution.  Personally, I love the fact that I’m going to actually be able to run a more robust cloud solution within my data center and begin to craft more cloud-oriented solutions for customers moving forward.

Now, if you’d like to give Azure Stack a try and have some hardware laying around to pull it off (or, if you really adventurous and want to create an Azure Stack Development Kit instance in a nested sense in public Azure), head on over to the Azure Stack Development Kit website (https://azure.microsoft.com/en-us/overview/azure-stack/development-kit/) and check the requirements for the hardware and signup for downloading the kit.

Hopefully, I can write more to come on things outside of initial concepts of Azure Stack moving forward!  Stay tuned!