What are Azure Blueprints?

Blueprints, in the traditional sense, are used by architects and engineers to design and build new things. They are used to ensure that the final products are built to specifications and in compliance with certain standards and requirements. Azure Blueprints are used in much the same way as traditional blueprints are. In much the same manner that an engineer or architect uses a traditional blueprint to design and build to spec, IT engineers can use Azure Blueprints to design and deploy a repeatable collection of Azure resources that adhere to certain requirements and standards. By leveraging Azure Blueprints, engineers can quickly build and deploy new environments that are always compliant with organisational standards – and they can do so far more quickly than building new each time.

Azure Blueprints allow the IT professional to orchestrate the deployment of resource templates and other Azure artefacts, including role assignments, policy assignments, resource groups, and resource manager templates. The service is back-ended by Azure Cosmos DB, which is globally distributed. Objects are replicated to multiple Azure regions to provide both highly available and low-latency access to those objects, regardless of where the Azure Blueprints objects are deployed. Watch this short video to learn what CosmosDB can do.

Watch this short video to learn what CosmosDB can do.

The Lifecycle of an Azure Blueprint

Most resources in Azure have a natural lifecycle. Blueprints in Azure Blueprints are no different as they are created and then deployed. When they are no longer needed, they are deleted. As such, Azure Blueprints supports typical lifecycle operations and even builds upon them. Azure Blueprints provides support for typical continuous integration and continuous deployment pipelines for companies that manage infrastructure as code. The typical Azure Blueprint lifecycle consists of:

Creation of a blueprint
Publishing of the blueprint
Creating or editing a new version of the blueprint
Publishing a new version of the blueprint
Deletion of a specific version of the blueprint
Deleting the blueprint altogether

Azure Blueprints vs Resource Manager Templates

You may be asking yourself, “why not just use Resource Manager templates instead of blueprints?” It’s a fair question, given the fact that Azure Blueprints do indeed appear to overlap the functionality of Resource Manager templates. Understanding the differences between Azure Blueprints and Resource Manager templates is key to understanding which to use and when. Azure Blueprints is intended to assist with environment setup. Such environments often include Azure resource groups, role assignments, different policies, and Resource Manager template deployments. Blueprints are essentially packages that pull these types of resources and artefacts together. These packages can then be composed, versioned, and assigned to a subscription. Such blueprint packages can also be audited and tracked.

Now, with all of that being said, almost everything that you’d want to do with Blueprints can also be done with Resource Manager templates. So what’s the difference? Resource Manager templates are documents that don’t natively exist in Azure. Such templates are typically stored locally or in source control. Once a Resource Manager template has been used to deploy Azure resources, there are no longer any active connections or relationships between the template and the resources deployed from it. Azure Blueprints differ from templates because even after deployment of resources from a blueprint, the relationship between the blueprint definition and blueprint assignment (i.e., what was deployed from the blueprint) remains intact. Preserving this connection allows for tracking and auditing of deployments. Another benefit of blueprints is that a single blueprint can be used to upgrade multiple subscriptions at once. Because blueprints can consist of Resource Manager template artefacts, previously developed Resource Manager templates are reusable with Azure Blueprints.

Azure Blueprints vs Azure Policy

So, we’ve compared Azure Blueprints to Resource Manager templates. What about Azure Policy? What is the overlap, if any? An Azure policy is essentially an access system that provides default allow and explicit deny on new and existing resource properties to which the policy is applied. An Azure Blueprint is a package for creating specific sets of standards and requirements that govern the implementation of Azure services, security, and design. Such packages are reusable so that consistency and compliance among resources can be maintained. A policy included in a blueprint offers the ability to create the correct pattern or design when the blueprint is assigned. Additionally, a policy inclusion ensures that only approved changes can be made to the resources or environment to which the blueprint was assigned. This ensures ongoing compliance with the blueprint.

Blueprint Resources

As mentioned previously, Azure Blueprints are made up of artefacts. Resources supported as artefacts include resource groups, Resource Manager templates, policy assignments, and role assignments. Resource Groups allow an administrator to organise resources and to structure them as needed. They also serve as scope limiters for policy assignment artefacts, role assignment artefacts, and Azure Resource Manager templates. Azure Resource Group Templates are useful when designing complex environments, such as those managed with Azure Automation State Configuration. Leveraging templates makes standardisation of such environments far easier than building them individually. Policy Assignments provide a means for applying policy to a subscription to which a blueprint is assigned. That said, the policy must be within the scope of the blueprint containing the policy. Parameters defined with a policy are assigned during blueprint creation or during blueprint assignment. Role Assignments provide a means for adding existing users or groups to a built-in role. This is done to ensure the correct people have the proper access to Azure resources. Role assignments are often defined for an entire subscription, but they can also be scoped to a specific resource group that’s included in the blueprint.

Blueprint Parameters

Azure Blueprints can pass parameters to policies, initiatives, or Resource Manager templates. When the blueprint author adds an artefact to a blueprint, they must decide on a value to define for each blueprint assignment or they must allow the blueprint assignment to provide a value at assignment time. With this flexibility, the author has the option to either define a pre-set value for all uses of the blueprint or to allow that decision to occur at assignment time. Although a blueprint can have its own parameters, such parameters can only be created when the blueprint is generated from the REST API. They cannot be created when generating the blueprint via the Portal.

Publishing and Assigning an Azure Blueprint

A new blueprint, when created, is in “draft mode”. Before assigning the blueprint, it first needs to be published. The publishing process requires a version string to be defined, along with change notes that must be provided. The version, which consists of a maximum of 20 characters (letters, numbers, and hyphens), differentiates the blueprint from future changes to the blueprint – and allows each different version to be assigned separately. As changes are made to a blueprint, the published version, along with unpublished changes, continue to coexist. After all changes to the blueprint are completed, the updated blueprint is published with a new version. Each separate (published) version of a blueprint can then be assigned to a subscription. When assigning blueprints via the portal, the blueprint defaults to the version most recently published. If there are any parameters, those are defined during the assignment process.

Summary

Azure Blueprints are essentially no different from architectural blueprints that building architects use to design and build large buildings. They are actually used in much the same way. While architects use traditional blueprints to design and construct buildings to certain standards and specifications, Azure architects and admins use Azure Blueprints to design and architect Azure solutions to specific standards and specifications. The lifecycle of an Azure Blueprint begins with the creation of the blueprint and then the publishing of the blueprint. New versions of the blueprint are then created and published as needed. The lifecycle of an Azure Blueprint ends with deletion of specific versions of the blueprint, and then of the blueprint itself.

While Azure Blueprints are like Resource Manager Templates and Azure Policies, the blueprints differ because they are “living and breathing”, so to speak. As such, they retain their relationships to the resources they have been assigned to and can be tracked and audited. This is not possible with templates and policies. With its versioning capabilities, Azure Blueprints offers the ability to create newer “versions” of specific blueprints, and to leverage those versions independently from the original blueprint from which the new versions were created. This further streamlines the configuration and architecting process of Azure environments since it doesn’t require the reinvention of the wheel each time a new change is needed.

When all is said and done, Azure Blueprints is a service that affords cloud architects the ability to define an easily repeatable set of Azure resources that conforms to the organisation's standards and requirements. With blueprints, it is possible to quickly build and deploy new environments with a set of built-in components. As such, it is possible to not only deploy consistent environments, but it’s also possible to do so in a much more streamlined fashion, allowing organisations to speed up development and delivery of such solutions.

What are Azure Blueprints?