Truly Understanding Microsoft’s Azure Stack

1 2 Page 2
Page 2 of 2

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.

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!

Copyright © 2016 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
The 10 most powerful companies in enterprise networking 2022