An Intricate Look at ARM Templates – Part 1 – Background and History
So the cloud is now. Like right now. We’re at the dawn of a new age these days. We’re dealing less with racking and stacking infrastructure in the traditional sense, along with environments taking weeks or maybe months to build and maintain. It’s a complete paradigm shift that has sprung into our reality on the operations side of the house. Software-defined everything, where we hit APIs versus boot from an ISO. This increased agility has prompted a revamping of existing models to provide environments in a faster fashion. If you are just coming into the cloud, however, the terminology and concepts can seem overwhelming, plus maybe a little difficult to comprehend. With the cloud comes scale, agility, and automation and: Configuration Management and Infrastructure as Code.
Configuration Management
(abbreviated to CM) is an engineering process for maintaining consistency of workloads throughout their lifecycle. Typically, what helps CM is most (if not all) of what gets deployed is done so through code.
Ever heard of Infrastructure as Code (IaC)?
IaC is the management and provisioning of infrastructure via code versus performing manual tasks to configure devices or systems. With the cloud, using both methodologies to build infrastructure and related applications has been on the rise. Now, if you are like me, you might be asking “why?”
Configuration Management Background and History
CM originated in the Department of Defense during the 1950s as the practice of handling changes systematically so that environments maintain integrity over time.
CM implements the policies, procedures, techniques, and tools that manage, evaluate proposed changes, track the status of changes, and maintain an inventory of system.
CM evolved over time to become a series of technical tools to maintain consistency throughout the evolution of a system, workload, or specific application.
Infrastructure as Code Background and History
IaC stems from software development.
IaC grew as a response to utility computing and second-generation frameworks, which became evident by the advent of the cloud.
With the launch of public cloud computing providers, we (many times for the first time) witnessed widespread scaling problems. The thought of modelling infrastructure with code, and then having the ability to design, implement, and deploy applications infrastructure with known software best practices appealed to software developers and IT infrastructure administrators.
The ability to treat it like code and use the same tools as any other software project would allow developers to rapidly deploy applications and operations to fully support in an automated fashion.
IaC combined with CM have become the de facto standard for deploying applications and infrastructure for those consuming both public cloud and on-premises resources. For the purposes of this blog post, I will be focusing more on IaC as we dig into ARM Templates, however a quick dip into CM is relevant when you think about the high-level picture of how these two methodologies lean on one another.
Infrastructure as Code Benefits
The beauty of a coded deployment is everything can be versioned + live in source control. Let’s pause for a minute and think about a world where repeatability can match the speed of cloud adoption and consumption:
· IaC provides consistency, repeatability, and programmable infrastructure, which makes it a perfect candidate to handle build outs at scale.
· IaC significantly helps remove limitations or human error related to manual deployments.
· In addition, IaC plugs in nicely to the world of DevOps.
IaC Approaches
IaC can be declarative or imperative:
· Declarative syntax makes up more of a functional deployment. The final state is declared in a way to define “what” state the deployment should be in. As a result, the environment gets configured in a declared state as the result. A perfect example of declarative syntax can be found by using ARM Templates.
· Imperative syntax is a bit different. Imperative syntax is more procedural in comparison to declarative syntax. The code you write, runs through each configuration step-by-step. Imperative syntax is the process of “how” the system is to be configured + what steps need to be taken (in the exact order) to reach the final state. A perfect example of imperative syntax can be found by using PowerShell (of the non-desired state configuration flavor).
So, what are Azure Resource Manager (ARM) Templates?
Well, they are JSON files that enable IaC for Azure Resource Manager. Azure is managed using an API: Originally it was managed using the Azure Service Management API or ASM, which control deployments differently and the broader community termed it as “Classic”. That interface was eventually replaced by the Azure Resource Manager, backed by all the ARM APIs. The resources that the ARM API manages are objects in Azure such as network cards, virtual machines, hosted databases, etc. At the time of this writing, ARM is the current deployment and management service for Azure.
Before we travel too deep, let’s dig into some of the terminology next, especially if you’re new to Azure Resource Manager. As the posts evolve throughout this series, I will start assuming you know what these “things” are, so it’s best to cover them in brief detail.
1) Resource - A manageable item that is available through Azure. Virtual machines, storage accounts, web apps, databases, and virtual networks are examples of resources (plus there are MANY more).
2) Resource Group - A container that holds related resources for an Azure solution. The resource group includes those resources that you want to manage as a group. You decide how to allocate resources to resource groups based on what makes the most sense for your deployment.
3) Resource Provider - A service that supplies Azure resources. For example, a common resource provider is Microsoft.Compute, which supplies the virtual machine resource. Microsoft.Storage is another common resource provider.
4) Azure Resource Manager (ARM) Template - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group or subscription. The template can be used to deploy the resources consistently and repeatedly.
5) Declarative Syntax – We sort of covered this briefly above, but this is syntax that lets you state "Here is what I intend to create" without having to write the sequence of programming commands to create it. The ARM Template is an example of declarative syntax. In the file, you define the properties for the infrastructure to deploy in Azure.
ARM Template Benefits
The main benefit of the ARM APIs is they provide a consistent management framework in that you can deploy several resources together in a single unit.
ARM Templates allow you to deploy, manage, and monitor all the resources for any given solution as a group, rather than individually.
You can repeatedly deploy solutions throughout the development lifecycle and hold confidence resources are deployed in a consistent state.
These templates help you manage infrastructure through declarative files rather than scripts.
ARM Templates hold flexibility in that you can define dependencies between resources.
You can apply access control to all services in your resource group because Role-Based Access Control (RBAC) is natively integrated into the management platform.
You can also apply tags to resources to logically organize all the resources in your subscription.
You can clarify your organization's billing by viewing costs for a group of resources sharing the same tag.
The deployments are idempotent, the user declares the type of resource, what name to use and which properties it should have, etc. and the ARM API will then either create a new object that matches those details or change an existing object which has the same name and type to have the same properties.
The ARM APIs can be accessed via the Portal, PowerShell, the Azure CLI, REST APIs directly, or client SDKs.
ARM API Layers
The following diagram illustrates the different layers within the ARM API. The API passes requests to the Resource Manager service, which authenticates and authorizes the requests. Resource Manager then routes the requests to the appropriate service.
Why JSON?
JSON, or JavaScript Object Notation is a minimal, readable format for structuring data. It was used primarily to transmit data between a server and web application as an alternative to XML. The two primary parts that make up JSON are keys and values. Together they make a key/value pair. Note, data is stored in key/value pairs and separated by commas. Curly brackets hold objects and square brackets hold arrays. Example below
Let’s break this down a bit further:
Key: A key is always a string enclosed in quotation marks.
Value: A value can be a string, number, etc.
Key/Value Pair: A key value pair follows a specific syntax, with the key followed by a colon followed by the value. Key/value pairs are comma separated. Example below:
There are specific types of values. Please refer to the value name and description below:
Example of an Array
Array: An associative array of values
Boolean: True or false
Number: An integer
Object: An associative array of key/value pairs
String: Several plain text characters which usually form a word
So ARM Templates define infrastructure, define configuration, and the templates provide consistency. The JSON code used for deploying resources in Azure uses all the features of JSON to describe everything needed to create your deployment. It may seem daunting at first, but once you have reusable templates in place, you save lot of time.
Tune into the next installment of ARM Templates! Our hope is all these blogs get you up and more than functional with ARM Templates.
Click here for Part Two - Prep Work and ARM Template Structure Breakdown
For more information on ARM Templates, check out our AZ-900 and AZ-103 courses as well