This past month, Microsoft released a public preview of Azure Stack, which I downloaded, fiddled with, and put together this blog post to share what this thing is all about. As with all my blog posts, this is not merely a regurgitation of Microsoft’s announcement or a simple opinion of what I conceptually “think” about the thing, but this is an actual commentary after a few weeks of hardcore fiddling with Azure Stack to truly understand the power and capability of the solution.
What is Azure Stack?
To start with, “what is Azure Stack?” Azure Stack is effectively Microsoft’s Azure cloud brought into an organization’s own datacenter. True, under the hood Azure Stack is running Microsoft’s Hyper-V, Windows, and Microsoft networking and storage, but you don't see any of that. When you stop and think about it, you are “running Microsoft’s Azure in your datacenter!”
It’s like saying I’m running an instance of Box.com, or Salesforce.com, or Amazon AWS, or Twitter in my own datacenter. And not just “something that is functionally similar to these cloud offerings,” but running Azure Stack is running Microsoft’s public Azure cloud in your datacenter!
Why Would You Run Azure Stack On-Prem?
So a question one might ask is why would you run a cloud service offering in your own datacenter? Isn’t the whole idea of “cloud” to offload workloads to a third party to minimize I.T.’s management footprint? Yes, offloading datacenter workloads to the public cloud is ONE reason organizations move things to the cloud, but it’s not the only reason.
In my internal test scenarios on Azure Stack, I spun up a couple instances of my company’s Accounting and our Human Resources apps up in Azure Stack. Relatively simple Dynamics Great Plains and Microsoft SQL Server applications, BUT things my CFO refuses to put up in the public cloud (right now). Citing security, compliance, and assured reliability (excuses), our core business apps are not (currently) allowed outside of our datacenter. Fair enough, not something I want to argue or fight my CFO over right now, I have plenty of other workloads that are easily moving to the cloud right now to keep us busy (email, fie sharing, www, collaboration, etc).
What we are able to do with Azure Stack is stage the implementation of our apps on-premise, and those apps that we can shift into the public Azure cloud, we can move them from Azure Stack (on-prem) to Azure (public). Being the same environment on-prem as in the public cloud, again, I’m not doing something “similar” on-premise, it’s Microsoft’s Azure public cloud, but in my own on-premise dev/test and on-premise internal datacenter environment.
How is Azure Stack (or Azure public) Better than an Existing VM Environment?
THIS is the simple question that completely differentiates Azure (public) / Azure Stack from a traditional VM-based environment. When you understand this, you understand how this whole thing is so transformational in our world of I.T.
For the past couple decades, we’ve thought of application scalability as “adding more servers.” If you need more capacity, you add more servers. A decade ago, that meant buying another physical server and putting it in a rack. With virtualization (VMware, HyperV, OpenStack), it has greatly simplified scalability because we could simply “spin-up” another virtual machine without having to immediately buy more hardware.
BUT, when you stop and think about it, each and every time you spin up a new virtual machine, you have the underlying overhead of an operating system (Windows/Linux), likely an underlying core application (Microsoft SQL, MySQL, Oracle, Apache), and yet another “system” to patch, maintain, and manage. You also have the challenge of inserting a “node” into a clustered VM environment, and removing the node while keeping the application running continuously. How much overhead do you have today to simply run a Web application, or a Data storage application when you are running dozens of “virtual machines” to host the application.
What Azure Stack (and Azure public) does is aggregate CPUs, Storage, Networking, Database Tier, Web Tier and simply allows you to allocate the amount of capacity you want/need, and your application is given the RESOURCES you want it to have. You can add resources, or remove resources, you’re not “adding VMs” and “removing VMs”.
Azure Stack (and Azure public) still allows me to import virtual machines (Windows, Linux, etc) up into the environment and run VMs the way we’ve been doing for years with VM management, but you have the option of running Infrastructure as a Service (IaaS) with VMs as well as Platform as a Service (PaaS).
I frequently use the analogy that if you are moving things, you’d initially just toss stuff in the backseat or trunk of your car. And if you are moving a few more things, you’d grab a couple friends and you’d toss the stuff in the backs of a couple cars. But if you have a LOT of stuff you need to move, you wouldn’t hire 20, 50, 100 cars and move stuff bit by bit in a lot of cars, you’d rent a large moving truck (privately managed) or even hire a semi-tractor trailer company (externally managed) to put your stuff in a bigger vehicle.
Running an application is exactly the same thing. It made sense running 1, 2, even 4 instances in separate VMs. But if you really want to scale, building 20, 50, 100 VMs with all of the associated overhead is just burdening your organization to handle a big application with a lot of little (heavy overhead laden) instances. Put your applications into a large moving van concept, where you have a LOT of capacity that you can host in a public cloud that someone else handles the operations (ie: Azure public), or something you want the scalability and capacity that you manage the operations internally (ie: Azure Stack).
IaaS vs Paas?
So this brings up the decade old question of Infrastructure as a Service (IaaS) or Platform as a Service (PaaS). The answer is BOTH for now, but when you start to scale your I.T. operations, you'll find a PaaS model makes more sense. But it’s hard for old school I.T. folks to completely wrap their heads around PaaS just yet. Mostly it is because when PaaS first came out almost a decade ago, applications had to be completely rewritten to support the PaaS providers at the time. At the time of early PaaS introduction, even basic virtualization (VMware) was in its infancy, so the idea of lifting and shifting workloads wasn’t quite ready for the marketplace. Those who tried PaaS in the early days still think PaaS is bad, difficult, complicated, but that's no longer an accurate assessment.
In the past decade, we have made our applications more scalable and portable, whether we know it or not. We had to update our apps to be able to spread them around across cluster nodes and multiple VMs to create basic scalability. We’re able to put multiple instances of IIS Web or Apache Web on a load balanced Web farm of servers. We’ve created SQL clusters to distribute database loads across SQL servers for scale-up and scale-out data scenarios. So we’ve updated our apps to scale and distribute app workloads over the past few years, little by little.
The next logical step is to get rid of the dozens of tiny VMs and move into the moving van concept, which is the shift to a PaaS platform. Continuing with the moving van analogy, yes, instead of putting the stereo on the back seat of the car with maybe a blanket on top, you’d have to box the thing up a little more neatly and securely to put it in the moving van. Moving from IaaS to PaaS will likely require some changes of (inefficient) code running on the overhead laden redundant systems, to a more broadly scalable PaaS model, but once you make the changes, you can now scale and distribute your application (up and down) based on your needs.
Again, Azure (and Azure Stack) do NOT require you to solely run your apps in a PaaS model, you can easily upload or create Windows and Linux VMs and run your apps like you’ve been doing on VMware and Hyper-V in an IaaS model. And quite frankly, most orgs that are moving to the cloud (Amazon AWS, Azure) have been doing it using IaaS by uploading entire VMs. It’s an easy concept to understand, it’s lifting and shifting an entire workload including the underlying operating system. But to truly benefit from the agility of the cloud, you HAVE to consider rewriting apps to support a truly scalable (and greatly lower overhead) of a PaaS platform. But again, Azure (and Azure Stack) provide you the option of IaaS and PaaS.
Azure Stack for Dev/Test Scenarios
Back to the earlier question, then Why Azure Stack? It’s harder to understand if you have already invested in a robust IaaS VM based environment if all you plan to do is build a bunch of VMs and run them in Azure Stack. One real world scenario we’re building out Azure Stack for basic VMs in an IaaS model is for Dev/Test scenarios.
We have an early adopter Azure Stack organization that runs their public facing application up in Azure (public). Azure is providing the organization a geographically redundant global datacenter environment that is externally hosted and scales to the need of their customer base in all of the distributed geographies they are serving. Azure (public) makes perfect sense for their production app.
However as much as they like the idea of an infinitely scalable dev/test environment that Azure (public) provides them, they want better control during the development process of their app. They want development capacity in isolated locations with the ability to put as much power as they want to code compilation and processing.
Azure Stack is being built to provide this organization the ability to completely control the physical location and allocated capacity of their backend environment. AND as they develop in Azure Stack on-premise, they can then easily shift the application from Dev/Test into the Azure (public) environment because they are effectively the same underlying environments.
Azure Stack for Extremely Secure Environments
Another early adopter scenario that we’re building out with Azure Stack is for an organization that wants and needs the scalability that Azure (public) provides, but in a private highly secured environment. Not “everyone” is moving to the public cloud, or at least right now, and for those organizations that have applications they want to scale and manage in a public cloud manner, but within the constraints of their own datacenters, Azure Stack provides them that capability.
Back to my moving van analogy, when the U.S. government needs to move top secret stuff, they don’t flip through the Yellow Pages and select a moving van company to move their stuff, they contract or use internal moving van resources. However, once the materials are packaged up, there’s nothing to prevent the government from shifting from a private to a public model, and similarly, Azure Stack brings the model of efficient and effective operations into a model that gives an organization a pathway to a public model if and when they choose at any point in the future.
Azure Stack for Hosters
Hosters and Manage Service Providers have a unique opportunity in differentiating their services leveraging Azure Stack. The world of third party hosted virtual machines has quickly become a commodity as organizations have spun up datacenters, calling themselves “cloud providers,” and effectively just hosting virtual machines (Windows and Linux) on traditional hypervisors (ESX, Hyper-V, or OpenStack).
But Azure Stack is not a commodity solution that has been “done before,” rather as enterprises begin to realize that scalability and agility really is dependent on having a Platform as a Service model in addition to an Infrastructure as a Service model offering, Azure Stack will help hosters differentiate themselves from their competitors.
Hands-on with Azure Stack
So my hands-on with Azure Stack the past few weeks has confirmed the scenarios that we had originally mapped out for the environment. I had several teams at Convergent Computing (where I work) build out Azure Stack environments, to be specific, 5 environments in 3 separate datacenters. We wanted to prove that Azure Stack could do the IaaS, PaaS, Dev/Test, and secured computing scenarios we had envisioned. In a nutshell, we were completely successful in all of our test, not without a few bumps and bruises along the way, but all of our teams were thoroughly impressed with what Azure Stack was able to do.
The first challenge we faced with Azure Stack was allocating the hardware needed to run the base platform (Microsoft suggests a system with 2 sockets, 128gb RAM, and 5 hard drives). Couldn’t say we had that type of hardware idly lying around in our labs, and while we “borrowed” a couple test servers we had, we supplemented by buying ASUS dual socket motherboards and built a handful of systems. All in all, we ended up with 5 systems allocated for testing.