Boss: Management has been asking for that viability report about Azure Stack.You: The release has been delayed a few times and it’s been taking longer than I thought. Boss: If they ask again what should I tell them? You: It's coming. Tell them, it's a think piece, about a high-level cloud organization struggling with their own limitations of being able to deliver hybrid cloud in the harsh face of an ever-evolving business demand.
The current deal I’m guessing you've been running your own private cloud for a few years now and you’ve heard Azure Stack is almost here and wondering if this is the solution to all your problems, well, you could be right. Previously you would start ordering hardware from your favorite hardware vendor along with your choice of networking gear or perhaps you're hoping you can save some money and reuse some existing switches from the last project you just finished, this is not the case. Over the last few years as Azure Stack has gone from a rumor to a product we have seen a lot of reactions to the announcements from Microsoft about what Azure Stack is and what it isn’t.
If you were thinking Azure Stack would be Windows 2016 running Hyper-V with some System Center components running with a flashy Azure skin on top with ARM bolted on deployed in 6 hours with PDT V2, you’d be completely wrong, mostly. It's true Hyper-V is there under the covers and there is something called the ECE engine orchestrating and deploying this, however, you should not be thinking about Azure Stack as individual software components you have to install and configure. What you're buying is 'Azure' in your own data center and this requires a level of control and abstraction, it requires a change in the way we think about delivering service. Perhaps asked another way, is your organization ready to consume and deliver Azure-as-a-Service to itself?
Jumping over some hurdles As the Stack vision gained clarity and more information was released it became clearer that traditional IT private cloud administration has a limited place in the Azure Stack story. This gradual release of specifications and functionality to conference rooms of people received a mixed response. There was no cheering or applause, generally, it was met with confusion and mutterings throughout the room and an out lash of confrontational commentary in online forums.
Originally it seemed like you could bring your own hardware, then there was a certain hardware requirement and now there are certified vendors that you have to purchase an Azure Stack stamp from (which FYI doesn't include Microsoft). On top of that, (I'm sure to the dismay of every storage vendor) Storage Spaces Direct is currently the only storage option meaning you cannot reuse that expensive SAN sitting in your data center humming away with all its deduplication, replication, pointer and snapshot technology you have come to rely on.
Whether this was a lack of understanding, lack of maturity, bad communication of a greater Microsoft vision the reasons are up to you. You may feel this was unfair or not what you think you wanted or the journey you had signed up for. Instead of complaining I'd suggest you 'pray they don't alter the deal any further'. All that said, if you feel like you had been given the run-around, take a breath and a step back from what you expected and realize this the new agile Microsoft we demanded. Accept this is the new face of a vendor attempting to adapt and drive a fundamental change and evolve IT for the better. Have a look at the now almost fully formed Azure Stack offer and be prepared to jump over some of the hurdles to trust Azure Stack and call it your own cloud.
The black box The first hurdle to jump over is understanding Azure Stack is designed to be a black box appliance. As an organization considering purchasing Stack, you should consider looking at all the Azure Stack vendors and SKUs and offerings provided and possibly look to build a new alliance. You are not buying hardware, you’re buying an appliance and the service to support that appliance. The idea you will be able to setup Azure Stack and log in and start moving some sliders to change the cloud profile is something you will have to let go of. You cannot choose your oversubscription level, you cannot create your own custom VM sizes, VM sizes will be a limited subset based on existing Azure SKUs, you cannot log into the console of an Azure Stack Node and browse around just to see how it works.
You can't walk into an Azure data center and login into a console of an Azure Node to check on the disk usage of your VMs, this solution is no different. This entire system is secured and even your Azure Stack vendor doesn’t have the keys, save your breath and don’t ask. The service you are buying is Azure in your data center. What you should be asking is what services they can provide, what else will I get when I purchase a shiny new Azure Stack stamp from you?
Cloud consistency The true consistency hurdle and understanding what ‘Azure Consistency’ really means. While many vendors have hybrid cloud stories, there is a big difference between modern hybrid cloud and a traditional virtualized environment running in more than one place. Azure obviously has a massive amount of iron behind it as well as multiple teams of developers creating resource providers and adding features to existing services. A substantial amount of time has been put into creating as-a-service services. It seems almost every day something else pops up in the alerts informing you of new features and services.
For some reason, the Azure codebase couldn’t simply be scaled down and offered to clients as an on-premise solution. However, the key piece of this hybrid puzzle is ARM. We are told Stack is using the same code base for ARM as Azure, meanwhile many of the underlying services are seemingly having to be recreated in a way they can be consumed through ARM on Stack. Because you have Azure Stack, it does not mean you have every service available on-premise, nor should you expect it in time. For instance, Service Bus on Stack, there are questions about this topic on forums that are left unanswered and there is currently no official announcement about Service Bus on Stack. It also does not mean as you see a new feature released in Azure you will be able to go to Stack and deploy the same thing immediately.
Azure Stack will lag behind Azure and currently, the story for true feature parity is to apply policies that will limit your Azure subscription to the level of Azure Stack. While you don’t have to do this you need to be aware of what is and isn’t available and what is consistent between the Azure and Azure Stack. However, just like Office 365, once you're onboard, without extra work you will receive access to new features as they are provided. Microsoft's current goal is for Azure Stack to be around 3 months behind regarding feature parity with services provided on Azure Stack (currently its lagging around a year). Through Stack's PUP mechanism (patch and update) you (or your stack vendor) will be able to execute an update and you will receive new Stack services.
Expectations The expectation hurdle, what are you expecting from Azure Stack? What is the problem or use case you are trying to solve for? Perhaps it's a pitch for app modernization, except generally this is a massive task with limited ROI. The app is running, leave it where it is. Maybe you think this is a chance to migrate your existing VMs into Azure Stack in a classic lift and shift. Consolidating old systems onto new you may want to re-think this if this is the primary reason. How about the cloudburst pitch or use for Stack as a DR or HA site? While many of these use cases make for a great presentation you need to really walk through your specific use case and understand the gap you are trying to fill.
Microsoft’s early guidance was leaning to Azure Stack being used by service providers and in extreme edge cases where customers could not completely use Azure public. However, the idea that everything would move to the public cloud may work for a few consumers, unfortunately, this seems like it is not the story for most consumers. There are some scenarios where your current private cloud is probably going to do the job better than Azure Stack can today.
Gartner and other big think groups seem to be now mirroring these opinions and predicting most enterprise clients will have some on-premise cloud. Re-enter the hybrid cloud story. More and more organizations have reasons for running workloads on-premise the public cloud may never solve from data sovereignty, latency issues, disconnected and highly secure environments, manned space flight to Mars, connectivity to locally positioned IoT devices this list goes on. Every organization will need to evaluate the use case for stack and check that it is fit for purpose.
A crisis of self The existential hurdle, where everyone thinks their scenario is special. In this brave new world of cattle not pets, you are not a special unique snowflake. Don’t be offended, this doesn’t mean they don’t care about you, in fact quite the opposite. Any public cloud has shown us that the economy of scale is real. They care enough to put a large amount of effort into ensuring Azure Stack will run your workloads as they run in Azure and ensure these workloads can survive a variety of hardware failures. Azure Stack has a surprisingly large amount of redundancy built in and the list of systemic failures it can sustain is impressive. The more nodes (and eventually regions and scale units) you have supporting Stack, the resiliency of your on-premise Azure service will increase, this comes at a price, literally, why have one when you can have two at twice the cost. As architects, we have spent days and weeks designing, implementing and months testing and maintaining redundant infrastructure. Realize you are buying a service, a redundant cloud platform. Where would you prefer to spend your time? Trust the platform and you can focus on something else.
These choices of how stack will be offered have been introduced (in my opinion) to save us from ourselves and try to truly bring the as-a-service story and consumption-based IT to the business. We had freedom with system center 2012 and Windows Azure Pack and these layers of complexity, if you could master would provide great rewards, unfortunately, there is a flip side to that coin, with many clouds while very functional have fallen short of their original dream.
The things you consider great about consuming Azure are now going to be available to you but at a cost. The pitch is that the wizard will remain behind the curtain and if you trust him he will keep your system running so you can focus on other things, moving up the layers of the maturity models, building out new modern highly resilient micro service applications. Perhaps venturing into the new frontier of DevOps is something you want to explore, utilizing continuous integration and continuous delivery allowing you to be able to release code 3 or 4 times every day on Stack. There is still plenty of work to be done it's just going to require a different set of skills to execute.
The ‘Easy’ button As someone that worked with early releases from TP1, I can say it has been a long journey to get here and simultaneously Stack has come a long way. With the initial announcement of three vendors offering solutions and now and with follow up announcements more vendors are stepping into this space striving to supply you a little piece of Azure you can call your own.
Azure Stack’s goal is to be a turn-key appliance, but that does not mean it’s an easy button. If your organization is truly a dynamic business on the maturity model, you may not even know you’re consuming Stack. However, for most of us deploying and integrating Stack into your organization I’m sure will come along with a new set of problems which you will need to work through with your staff, Stack vendor, end users and Microsoft.
It is a Journey With the shift in Microsoft’s direction and releasing code and features more often, getting feedback from customers, utilizing the votes captured through 'user voice' yammers surveys and other avenues, these direction changes have seen more testing pushed back onto the community and customers. Microsoft teams are working directly with interested parties to develop technology to solve real business problems.
We are all now on a cloud journey of some sort and Azure Stack will be no different. You can be as involved as you want to be. Either on the bleeding edge cutting your teeth on private releases, logging bugs explaining what you actually need or sitting back and waiting a few months for a well-tested GA release. As we have moved to the cloud our thinking has had to change, we do things differently, this is another big step in that journey. If you are preparing to take the leap to Azure Stack I believe the best advice can be summed up in a single quote “Free your mind”.
