As you all know by now (I hope), Microsoft’s Azure Stack, the “run some of the Azure Portal on-prem and use it to manage in-cloud and on-prem resources” solution, is only available as, essentially, an appliance. You have to buy it from OEMs like Dell or HP, and it comes preinstalled on select hardware. It’s a sealed OS – you can’t install your own drivers, your own management agents, and so on. You can’t even really mess with it’s patch application schedule.
This is a new approach for Microsoft. It isn’t going to be the last time they do it.
First, ask yourself why Microsoft is taking this approach. Second, read the actual answers:
- This is a hugely complicated mess of software. The number of moving pieces is significant, and creating a foolproof installer would take as much time as making Azure Stack probably took.
- You’d install it once and then never mess with it, once you got it working. You’d live in mortal fear of changing anything in something that complex. Yet this is software that needs to iterate constantly.
- You’d install device drivers and management agents and God knows what else on it, and it’d all come crashing down. Microsoft would end up trying to support that, and they don’t want to.
Thus, it’s an appliance. Architect Jeffrey Snover was crystal-clear when he said that this approach won’t suit all customers. For those who don’t like it, you can’t have it, any more than you can host your own “private Office 365.”
However. Just as a thought experiment, why couldn’t Microsoft have done this all along, with more things? Like… Exchange Server, arguably their biggest seller behind Windows and Office?
Well, one reason is that Exchange needs to be domain-joined, which means you can’t have a fully “sealed” OS, right? Hmm. “Needs.” Needs. Needs?
Why does Exchange need to be domain-joined? No, seriously. Yes, Exchange as written needs to extend the AD schema, and as written it needs to have AD so it can mailbox-enable your users. But that’s not a need; it’s just how it was written. Exchange absolutely could have been written to simply federate with your AD, right? “Connecting” mailboxes to identities in much the same way it already does. If it did that, and if it was instrumented for external monitoring (no need for locally installed agents, in other words), Exchange could pretty much have been an appliance. Too late now, of course, but you get my meaning.
With the advances in, and robust deployments of, identity federation, there’s a rapidly dropping need for software to be designed with hard dependencies on an on-prem directory. As monitoring solutions move their command-and-control to the cloud, there’s less of a hard need for locally installed management agents. I could absolutely see an on-prem collection server that gather management stats from your local “appliances,” and then forwarded those stats to your monitoring solution somewhere.
“But we can’t have some appliance, that we can’t even touch, storing our sensitive data!” Well. Maybe. More of it than you know is already in the cloud, assuming you do basic stuff like send emails. But there’s also nothing saying the appliance might store nothing. Your local SAN would serve as storage, just like it does now. The appliance just provides a means of accessing that storage through some particular mechanism, like a database server, messaging server, file server, or whatever. The info bits live on your hardware; it’s served up by an appliance you buy.
No more software installs. I mean, really, this is “private cloud” viewed from a different perspective. You’re essentially subscribing to a service, which is fulfilled on-prem by a box that the vendor provides. Cloud-ish, conceptually.
I think you’ll see Microsoft do this more. Not across the entire line, of course, but more. I think other vendors will try to follow suit, especially for point solutions that need to do a specific thing, and aren’t very customer-specific in their implementations.