Here we are… mid 2017. Its June and we are getting close to the General Availability (GA) of Microsoft Azure Stack. The product team has done some amazing work last year with the development of Azure Stack. I was lucky to get a closer look at the progress of the development and have seen how hard it is to take a hyper scale cloud platform and size it to a scale that is reasonable to run on premises. As you might know, the smallest Azure Stack environment supported in production at GA will run on a minimum of 4 servers and a maximum of 12 servers. To support developer efforts, Azure Stack can also be installed on a single server (not supported for production purposes, obviously). Before I continue with Azure Stack, I’ll start with a small overview of how things run in public Azure to set the context for the rest of the blog. Public Azure currently consists of four environments:
- Public Azure
- Azure Government
- Azure China
- Azure Germany
Each Azure environment consists of multiple regions. You can consider Azure Stack as just another Azure environment. It just happens to be running in your own datacenter. To plan your design for Azure Stack you might consider looking at Azure. For example, a common scenario might be that you will build a single Azure Stack environment. In this Azure Stack environment, you might want to build multiple regions. In these regions, you want to add multiple scale units. Wait a minute… scale units? What is a scale unit? A scale unit in Azure Stack is a single cluster running homogenous hardware, meaning each server has the same hardware specifications (CPU / Memory / Disks). At GA, an Azure Stack environment supports a single region and a single scale unit. Additional scale units and additional regions are not supported until 6+ months after GA, so you will need buy your hardware considering growth up to 6+ months post GA. The scale unit requires a minimum of 4 servers and a maximum of 12 servers. I have spoken with customers and they said; We will build additional Azure Stack environments to address these initial limitations. Later I will explain why that might or might not be a good fit for your business.
So, to recap. At GA, we get Azure in our datacenter running a single region and a single scale unit containing 4 – 12 servers. Services that we can offer to our clients are the following:
- App Service (Preview)
- SQL (Preview)
- MySQL (Preview)
On top of the IaaS and PaaS offering that is available at GA, marketplace items will be made available as well for syndication to your Azure Stack marketplace. When you run Azure Stack in a connected scenario you will have the option to connect your Azure Stack marketplace with the Azure marketplace and download (a subset) of gallery items that are now available in the Azure marketplace.
Who are the hardware vendors that can deliver Azure Stack at GA? The following hardware vendors are ready to supply customers with integrated systems at GA:
- DELL EMC
Shortly after GA (expected end calendar year 2017) Cisco will have their integrated systems ready for customers. Recently Huawei announced to join the Azure Stack integrated systems party and Avanade will start delivering integrated systems as well. The last one is a surprise for me. I am curious what hardware they are going to use to deliver the integrated system for Azure Stack. If I have more information about it I will update or create a new post on that subject.
Let me take the next chapters to explain the use cases for Azure Stack in the context of functionality that is available at GA. This is gathered from the document Microsoft released in March, that you download here.
I said earlier that it might not be a good idea to install multiple Azure Stack environments at GA. Customers I spoke to give me the answer that they want to build multiple instances of Azure stack when I talk about the sizing and scaling constrains at GA. In what context might it be a bad idea to build multiple Azure Stack environments?
If you install two or more Azure Stack environments, they will be complete separated (portals / ARM endpoints). Why it is a bad idea? When you are a service provider and in the long term do want to have a single Azure Stack environment having multiple regions and scale units. First, where we have the power today in Azure to use a single ARM template to deploy resources in a single resource group to multiple regions you will have to explain to your customers to use a single template for a single region in Azure Stack. Not ideal. Second, if we take the time an average organization will need to ‘transform’ and adopt cloud principles we might already have multi region support. And when a customer is ready after 5-6 months and started to deploy their solutions to your 2 Azure Stack environments what you are going to do once you have multi region capabilities? Add another or a new scale unit in a new region? Or you will tell your customers that you are about to tear down the second environment because you want to reinstall it in the first Azure Stack environment as a new region? In my opinion, not a success story.
When it is desirable? When you host single tenant Azure Stack instances. Whether you’re a service provider hosting single tenants on single instances for each customer or in an enterprise scenario. Both might be valid reasons to actually have multiple instances of Azure Stack aka multiple Azure Stack environments. Customers will have their dedicated Azure Stack environment solely for them. You can then discuss scale limitations per customers and explain constrains when you do build a second Azure Stack environment for them.
Further I believe a careful approach is desired. With that I mean the following and I am quoting the scenario’s that are described for GA workload scenarios:
- Hybrid app modernization for enterprise and dedicated hosting
- People and process improvement (DevOps)
I didn’t read anywhere to put your 0-downtime required, mission critical workload on Azure Stack at day 1. So, Azure Stack is not a reliable system at GA? I have fully trust in the capabilities and working of Azure Stack as a Hybrid Cloud platform. But I also do believe that this hybrid cloud implementation is a journey for organizations. We are going to run a v1 hybrid cloud solution. Yes, we have learnings from Azure in Azure Stack, but not the scale from Azure. It’s new for all of us. Hardware vendors and Microsoft will have to support this. They need to ‘learn’ how they can optimize the support workflow in case something does happen in your environment. Backup and disaster recovery scenarios are in my opinion not ready and optimized. Is that a big deal? Not If you take in mind the scenarios Microsoft described in the document and I mentioned above. Same counts for scale out, multiple regions and other expansion capabilities. The last three I mentioned will be delivered to us after GA. Also, a note for service providers. Pricing show back in the portal is not working at GA. Implementing your own pricing system and plug it into Azure Stack is not available and means that prices will show in the portal as ‘Not Available’, as we see in the current Technical Preview (TP). This feature is to be expected after GA. Azure Stack is a journey and the journey will continue after GA. Microsoft is committed to bring us with each new update cadence the following:
- Azure version refresh – New bits ported from Azure into Azure Stack
- Add new Azure Services – Over time new features will be ported from Azure into Azure Stack and made available to your customers. (First new services will be Azure Service Fabric and Container Services)
- Fundamentals – Updates that needs to apply on the base infrastructure and management of Azure Stack as well updates on expansion and scale.
And this will be the roadmap forever and the system will grow over time and we will be able to add more and more workload scenarios into Azure Stack.
Now that we are close to GA I hope to get some excitement announcements at Inspire… After all we are at mid-2017. Join the discussion and the journey with Azure Stack!