This year I embarked upon a journey into the world of the cloud, specifically Microsoft’s IaaS offering in their Azure public cloud. I’ve learned a lot, and I have oh so much more to learn. Over the next few posts I wanted to share the highlights and pain points that may help the next person.
Last time we met Azure IaaS, but it was a rather superficial introduction. We didn’t dive right into IaaS, because we discovered we had to answer a few key questions before deploying an infrastructure in Azure. When I began to stand up the new environment using Azure IaaS I was hit with an unexpected question. Which deployment model should I use?
Biggest question: Classic or Resource Manager
This question was unexpected because I didn’t even know there was more than one option, nor which one was the “right” choice for me. What I realized was that there are two different Azures, two different portals, two different architectures, resulting in twice the confusion, and twice the learning curve. I was at a crossroad. Do I stand up our environment in the classic environment or the new resource manager environment? I needed to research and compare each offering to determine which one was the best fit for us.
Azure Service Manager (known as ASM) is Microsoft’s first generation of cloud architecture. In the service manager model everything revolves around the cloud service. This is suitable for running your apps on IaaS VM’s, but not conducive to running real infrastructure roles. The networking in the ASM model provides only basic features, and the administrative model is a flat all our nothing approach. You’re an administrator or nothing, with no delegation of administration possible.
Microsoft’s second generation cloud architecture is known as Azure Resource Manager or ARM. Built from the ground up with role-based access control (RBAC) and a common deployment model, all your cloud assets are collected into resource groups. Azure Resource Manager has completely revamped networking which allows flexible virtual networks to be created. All current development efforts of Microsoft are being poured into the ARM architecture thus leaving ASM a legacy platform.
We deployed our first pilot in Azure Service Manager (“classic”) because at the time we found more documentation, blogs, and training online for ASM. However we quickly found some limitations that would eventually back us into a corner. When we began deploying a pilot in the Azure Resource Manager we discovered a lack of feature and functionality parity between the two portals. There were actions that existed in classic portal which didn’t yet exist in the new portal. Many of the actions and management changes required us to break out PowerShell. While I’m no stranger to PowerShell managing Azure through PowerShell was yet another learning curve. On top of that there are separate Azure PowerShell modules for each portal.
Despite the initial barriers to getting started with the new Azure Portal (ARM), the advice given to me from our consultant (and the general consensus of the Azure blogs and Twitter) was to push forward with the Azure Resource Manager architecture. We took this advice and began our deployment in Azure Resource Manager.
The Nugget of Wisdom
The rapid pace of development of Azure necessitates an always learning attitude from the whole team including development and operations. The evergreen model of change also means that not all features are fully baked when they are made available. Finally a strong knowledge of PowerShell is absolutely necessary when working with Azure as many features and settings are not available through the portal and can only be done through PowerShell.
Next time we’ll look at building out a virtual network.