Azure Stack Integrated Systems from Lenovo, HPE and DellEMC at Ignite 2016
Many people were disappointed when Microsoft made the announcement that Azure Stack is being delivered as part of an integrated hardware system at GA from Dell, Hardware and Lenovo. For good reason. It was indirectly advertised and understood by many as the new ‘Windows Azure Pack’ (WAP). Allowing you to deploy it on own hardware and customize every aspect. We understand now that WAP is a different product as you can see on the business orientated comparison cheat sheet we made here. It is more flexible and customizable when you use it with existing traditional infrastructure components compared to Azure Stack and solves other scenarios in a different cloud and licensing model.
One interconnected system
Azure Stack’s unexpected six-month delay indicated that there is a large amount of work to be done before Microsoft can deliver it as a complete, stable and trustworthy product. That also means that if they want to deliver it on time as a stable system, a system which is essentially Azure worthy, they have to cut-down resource intensive processes. No way that they have the time and resources to validate different hardware components, the interoperability with each other and guarantee it is stable enough without disrupting the whole stack. They have to keep the validated hardware subset as small as possible if they want to reach a faster time to market. This way of servicing, certifying and supporting the physical layer is a far less complex and time intensive task. These physical hardware components are more intertwined than ever with the software-defined layers running on them. In particular, when you use the hyper-converged model, a software-defined storage solution as ‘storage spaces direct’ shares software-defined networking and compute resources. The types of disks you are using in the system and the IOPS performance generated by them directly impact the network card and processor performance. For example, an all NVME disk setup generating millions of IOPS requires you to size your environment using the correct hardware components to deal with such violence travelling through your stack.
One Microsoft hard way road
Not only a faster time to market pushed Microsoft into the integrated hardware direction. If you ever deployed or did some ‘Windows Azure Pack’ (WAP) troubleshooting then you know that it can be a quite long and daunting task, it requires outstanding expertise. And even if you went through all that you still don’t know if future hardware and software components you add to your WAP will work with each other. You have to do the mixing and matching yourself, which results in a bigger chance of customer impact compared to an integrated and validated system.
That is just seen from a customer perspective; we can determine Microsoft’s perspective, which is much more complicated and resource intensive. They had so much trouble supporting various customer environments to a point that they had to talk with hardware vendors about specific firmware running on certain kind of hard drives to solve their customer issues. With new software-defined networking and storage technologies where resilience and redundancy is handled by Azure Stack things get more complex, hardware components such as a raid controller providing traditional disk redundancy must be configured differently. They learnt from all that and concluded that if you want to deliver a turnkey stable solution, then every piece of code including firmware and hardware functionality has to be compatible with the software-defined layers on top. Any mismatch compromises the whole solution. Bill Gates with his famous ‘blue screen of death’ can attest to that, but back in those days it was just a single computer. In this day of age with hardware and software layers interconnected, it’s your software-defined data center hosting a state of the art cloud platform with all your customers. Fine if you’re freewheeling with a couple of nodes, I guess … However, it’s a whole different world when you’re dealing with a couple of racks or operate a sub-hyperscale cloud service provider environment.
One ecosystem, one brand
Azure Stack represents Azure and is just Azure! In other words, Microsoft provides you a part of Azure in your own data center. They have to ensure the same experience and reliability customers already have in public Azure, by upholding the same reputation and reliability customers are accustomed to. Azure Stack clouds therefore must align with Azure’s ecosystem, innovation, servicing and brand wise.
The same public cloud experience has to be ensured in other clouds or it indirectly affects the ecosystem. Azure Stack environments lagging to far behind of Azure’s update policy will not be supported anymore because consistency and compatibility across cloud services and tools has to be maintained. This way Microsoft can provide customers a true consistent Hybrid experience with Azure services, no matter which cloud they are using. The underlying hardware is an important integrated piece of the solution and tightly coupled with the software-defined layers on top. Any misalignment causes impact on the entire solution, compromises the reliability of Azure’s ecosystem and more importantly, damages the business of your customer.
