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.
The installation of the Azure Stack host code led us to challenges of driver compatibility and a couple install errors, but things we eventually worked through. Tough part with anything new, a quick Google search didn’t provide us with a lot of help, but with 5 environments in the works, we pooled our knowledge and worked through figuring things out, mostly common sense stuff that through trial and error, we figured out (although now there’s actually really good documentation Microsoft has available online for installation/configuration/debugging). When one of our long time VMware guys said the thing was difficult to get going, we had to remind him that if he were thrown in front of an ESX host for the first time with limited instructions, how far would he get in setting up the host and doing all of the redundancy and high availability stuff on the host for the first time.
Now that we’ve built and rebuilt the hosts several times, we can now get an entire Azure Stack host built in under a couple hours, so like with anything, once you know how it works, it’s easy…
Once the core Azure Stacks were operational, the real testing was in putting workloads on the systems. Our initial fiddling was building Windows VMs and importing Windows VMs was uneventful and quite frankly not the least bit exciting, but that was expected. This was a Microsoft product, we’ve been using VMware and Hyper-V for years to host basic Windows VM, there’s nothing all too exciting of running a basic VM. But at least we know it runs the VMs just fine as we would expect.
What really impressed us during our testing process was when we started to fiddle with the PaaS services. We took our Intranet (built on Microsoft IIS Web and SQL Server), made a handful of code modifications to support the PaaS environment, and got it all up and running on our Azure Stack within about a day end to end (code mods, code uploads, scalability testing, everything). The EXCITING part was when we put a load generator on the thing and then SCALED our Intranet to increase capacity with more cores and more storage, we just clicked to add resources and the resources were dynamically ADDED!!!
We didn’t have to build more VMs, we didn’t have to insert VMs into a cluster, we didn’t have to setup external load balancers, we didn’t have to create more SQL server nodes and bring our clusters up and down to change capacity. THIS is where the power of Azure Stack is at! The code changes we made to our app were nominal, and here forward, we now have a PaaS enabled app that is built for the true scalability and “agility” that the cloud has been sold to us over the years, and is now readily available in our datacenter.
We installed the SQL (PaaS) provider on our Azure Stack to scale out a couple of our SQL server instances in the same way we did our Web app scalability. We threw load at the SQL instances, scaled them up and added more load. Any time we made changes to our requests for more capacity, Azure Stack added the resources we needed on the backend. As far as the app (and the users) were concerned, they saw nothing, just sustained performance and uptime.
We developed test processes of patching and updating the underlying components of Azure Stack, which there are base templates that serve up the capacity, however instead of patching and updating dozens (hundreds) of individual VMs, we’ve setup a process of updating the base templates that are to be deployed, and then as we deploy the templates, everything is already up to date and fully operational.
It’s a completely different model for operations, but one that we have been rewriting operational manuals internally in our organization to manage an Azure Stack instead of a bunch of individual VMs. Going back to my moving van analogy, if I’m going to be moving a lot of stuff, instead of doing maintenance on 100 individual cars, I’m doing maintenance on 5 moving vans, of which 3 are doing the bulk of the work, and 2 are redundant spares.
For the current Azure Stack TP1 Preview, it’s just a single host server model, so we’re not able to do multi-site replication and redundancy just yet, but now that we are running full test workloads on the hosts we have setup in our datacenters, we can’t wait for updated generations of Azure Stack that’ll provide us multi-host / multi-site capabilities.
Summary I’ve had an opportunity to fiddle with a lot of technologies long before their public release, and have written blog posts and 1500-page books on things including some of the first publicly available texts on Microsoft Exchange, SharePoint, Active Directory, Apple Mac Integration, Unified Messaging, Office 365, and the like. Fiddling with and building out case scenarios on Azure Stack put a huge smile on my face.
Azure Stack completely changes how datacenters will manage large scale applications, and even address dev/test and highly secured and scalable apps.
I don’t see basic virtual machines going away any time soon though. A small org wouldn’t go through the effort of buying an Azure Stack to host a few VMs, just as it doesn’t make sense for the home owner to buy a semi-truck to move a few boxes or even a whole household. In those scenarios, “renting” a van (or buying Azure (public) capacity) makes more sense.
But for organizations that are currently scaling applications to “dozens” of individual VMs that are load balanced and scaled across a lot of VMs, or for organizations that have cloud-scale applications they want to maintain on-prem, Azure Stack is built for cloud capability but for on-premise operations.
As I look at the marketplace, organizations can’t put Amazon AWS or Google on-premise, and again, not everyone and everything is ready to go to the public cloud. Microsoft has that unique position in the marketplace of providing highly scalable and globally distributed public cloud services (in Azure public), while also providing organizations the ability to run the exact same applications, capabilities, and cloud scalable and redundant services on-premise.
As we see organizations making the decision today of going to Amazon AWS or Microsoft Azure, if all you’re doing and expect to (ever) do is basic VMs in the cloud, then it really is a toss up between AWS vs Azure. But if you are like pretty much every enterprise in the world that wants the flexibility of doing some stuff in the cloud, and some stuff on-prem; be able to do some stuff as VMs in an IaaS environment and some stuff in a scalable PaaS environment, banking on Microsoft provides more flexibility of choosing a provider that can fulfill on ALL of your business needs today and in the future.
I’ll post more hands-on tips, tricks, and guidance in upcoming blog posts to provide the inside tips on how to optimize stuff in Azure Stack, and how to test out core business scenarios ongoing. Stay tuned!
