Introduction
In the first few months after Azure Stack was announced, there was quite a bit of buzz around what it promised.
A true hybrid cloud experience, allowing workloads to move seamlessly between public Azure and your private Azure Stack data centre.
If anybody could deliver this, you’d think Microsoft could.
Later than expected, it has now been released under General Availability. This post takes a look at a couple of factors that I believe are key to the success of Azure Stack.
Scalability
Azure Stack is a fixed size hyper-converged platform. That is, the compute, storage and networking are tightly integrated with an overlaid software architecture. The fixed aspect refers to the fact that when you buy a Stack, you are buying a fixed number of nodes e.g. 4, 8 or 12.
I’m not a massive fan of hyper-converged infrastructure unless it’s dedicated to a well known workload that you can scale the nodes to. As soon as you put inconsistent or unpredictable workloads on there, you run the risk of, as an example, having to buy a new node (with all that compute, RAM and storage) just for the additional storage, even though your CPU and RAM utilisation might only be at 30% and 60% respectively. You can’t just buy more storage.
For me, one of the key definitions of cloud is scalability and flexibility. If you have an 8 node cluster, you don’t want to have those nodes sitting at 40% utilisation. You want them at near capacity, taking N+1 in to account.
I feel that the ‘pod’ approach that Azure Stack takes amplifies this problem even more. You can’t currently buy a 4 node pod and add another node when the cluster fills up. You need to buy another pod. That doesn’t come cheap.
I wonder, once the platform matures further, if Microsoft will allow single nodes to be added. It would mitigate the concern, but you are still limited to specific workloads if you aren’t going to be wasteful with your resources.
Feature parity
The big promise of hybrid cloud is running workloads in either your private data centre or the public cloud (Azure Stack and public Azure for the purpose of this post), migrate freely between the two, with a consistent experience regardless of where your workloads were.
That sounds like hybrid nirvana, but the current reality is less enticing. Stack was always going to deliver a subset of public Azure, but the feature gap today break’s the hybrid promise in their current state as far as I’m concerned.
The biggest difference is with the PaaS services. There are a number of hoops required to jump through to enable any level of PaaS services and requires licensing of additional VMs on the Stack to run some of those services, the latter point not really coming as a surprise though. For me however, PaaS is where the real benefits of migrating to cloud are reaped so this feels like a big bump in the road as it stands. A number of resource providers appear to be missing too. Again, I’m hopeful that as the platform matures, the capabilities gap will narrow considerably.
A great example of using a hybrid cloud setup is being able to DR your workloads from your private data center to the public cloud. You can currently do this with Azure Stack, but to fail the workloads back to your private Stack, you need to lift and shift them manually. This feels very much like a lock in to my sceptical mind. I can almost hear Admiral Ackbar shouting his warning out.
Microsoft are not offering any SLA on Azure Stack at the current time too.
Some of these shortcomings are likely to change over time but the key theme here for me is, what is the use case for purchasing Azure Stack? With no SLA, would you run your production on there? Would you use it for development on what is essentially a hobbled platform?
Summary
The idea of having a common interface to manage all your workloads, regardless of where they are hosted, is very appealing for obvious reasons. However, in its current incarnation, I can’t see a compelling reason to dive in to Azure Stack, although I have no doubt that over the next 1-3 years, it will mature to something that will genuinely be a game changer.
Have you deployed Azure Stack? If so and assuming you aren’t just talking about ASDK (the development kit that allows you to install Azure Stack on any tin), I’d love to hear what types of workloads you are running. How have you dealt with the shortcomings listed above? I’d love for you to reach out either on here or at my Twitter account to have a discussion.
Till the next time.