Azure Resource Manager : What I learned!

What’s the big deal with DevOps and ARM templates for infrastructure? And why should business care about the latest version of something. What really counts is business value?

Now, Business value is what organisations expect from technology today, and they expect that value to be delivered quickly, efficiently, constantly, these constant builds of incremental value. And with Infrastructure as a Code (IaaC) is the first step to leverage the value.

What is Azure Resource Manager?

All of modern Azure functionality is built on the Azure Resource Manager management and deployment service that define all those resources that use JSON to declaratively.

Now there are very deep resource relationships. Often resources will reference and depend on other resources. Example : a virtual machine, It’s an entire object, it’s an instance of the virtual machine resource that’s defined in the Microsoft.Compute resource provider. Thus a VM depends upon Managed Disk, Storage Account, Network Interface Card, and Subnet and VNet and public IP or LoadBalancers.

Here are Azure Resourcing Provisioning Options:

Anatomy of an ARM Template

The ARM template uses JSON to document the desired end state. There are 3 key elements of ARM templates:

• Parameters: These are values that are going to provide when we actually execute the template as parameter.json file
• Variables: Variables define values that can actually have expressions of logic and constructs. We can create a variable based off some of the parameters that we use within template.
• Resources: These are the resource types that come from the resource providers.

How to get started with ARM Templates?

GitHub has a huge selection of templates that make a great starting point, and this is my recommendation. I recommend actually going to GitHub, finding a template that does most of what we want, and then tweaking to match exact requirements.

The link for github : https://github.com/Azure/azure-quickstart-templates

Nested Templates:

So for those more complicated scenarios, we like the idea of a main template. That main template enables management of the parameters for the entire deployment. It enables the overall structure, but then calls other templates. Now there are different options for those other templates. We can use linked and nested templates. Linked uses separate template files that reference while nested embeds the template in the main template.

Blueprints:

Blueprints are typically used to stamp an environment with a complete configuration. Blueprints bring together a number of artifacts. One of them is templates, but also things like role-based access control, and Azure Policy. We could also have a blueprint that is comprised of multiple, smaller, simpler templates to complete my overall deployment.