The deployment of cloud infrastructures is no longer a point-and-click adventure in confusing GUIs. Instead, Microsoft has created tools for describing infrastructures as codes. Microsoft’s Blueprint service for the Azure Cloud is advantageous for the centralized deployment of environments.
The Azure Blueprint feature enables and facilitates to ensure that each environment will meet pertinent standards, requirements and compliance.
Blueprints allow cloud architects and information technology groups to expand and set up new environments with a set of components for speeding up delivery and deployment. This is similar to blueprints used in architecture to sketch a project’s design factor.
Blueprints can be used to deploy a number of resource templates and so-called “artifacts” such as:
- Role assignments
- Policy assignments
- Azure Resource Manager templates
- Resource groups
Governance made simple
Azure Blueprints provide integrated tooling to keep your resources under control and make sure everything is deployed as intended. The Blueprint mechanism supports typical lifecycle operations, ensuring no surprises will occur when deploying your environments.
The Azure Blueprint lifecycle proceeds as follows:
- Creation of blueprint (assigning all resources and artifacts to be deployed)
- Publishing the blueprint (assigning the blueprint to various environments)
- Creating a new blueprint or modifying an existing blueprint
- Publishing the new version of the blueprint
- Deleting older versions of the blueprint
- Deleting the entire blueprint altogether
One of the key factors in helping manage and govern your environments is to set newly created blueprints or edited existing blueprints to “draft” mode. A blueprint with draft status can be deployed only after publishing.
To publish a blueprint, a version number must be applied, along with any notes stating any changes made to the blueprint. This allows administrators and owners to identify any changes that have been made and establish guidelines to ensure consistency and validity of any edits.
In addition to the existing change controls, Azure Blueprint also includes resource locking functionality for protecting new resources against tampering – even for owner accounts.
Resources protected by resource locks have four states:
- Not locked
- Read only
- Cannot edit
- Cannot delete
Those properties can only be removed by updating the blueprint itself and changing it to a different locking mode. Unlike other resources in Azure, Azure Blueprints do not allow users with the appropriate role-based access control to override any locks. This security measure protects the consistency of the defined blueprint and the environment. It is designed to prevent inadvertent or programmatic deletion or alteration.
Additionally, Azure Blueprints can deploy a single compliant package to multiple subscriptions, streamlining environment creation. Environments can be ensured to match one another across production and development subscriptions, for example.
Azure Blueprints vs other Infrastructure as Code options
There are various options available deciding on Infrastructure as Code (IaC) tooling. At first glance, ARM templates and Azure Blueprints seem to overlap and perform the same tasks, adding yet another layer of confusion when two native solutions are available.
Either feature can be used to package an environment and deploy Azure artifacts and resources. So what’s the difference?
ARM templates are documents that don’t exist natively in Azure. They are normally stored locally or in a central code repository such as Github or Gitlab. Once deployed, the templates are no longer connected to the deployed resources. As a result, the templates may no longer be updated in a timely manner for any changes required for the given resource (and future resources), or the templates may be updated without proper documentation of any changes.
Azure Blueprints attempt to resolve these issues by maintaining the connection between blueprint definition and blueprint assignment. This relationship allows tracking and auditing of deployments as well as updating multiple subscriptions at the same time.
ARM templates and Azure Blueprints can also work hand in hand. There’s no need to abandon existing templates in exchange for blueprints, since Azure Blueprints embed existing templates. This also provides a central resource for your templates as well as the assurance that they can be utilized to their fullest extent.
Of course, some third-party systems have similar features for governance and compliance. While these tools offer a lot of the base Infrastructure as Code benefits, they lead to issues similar to those of ARM templates: your entire code base is stored outside of your environment.
As a result, an additional layer of management (Github, Gitlab, etc.) ensures that your templates are secure and accessible, while lacking some of the features of Azure Blueprints, such as resource protection using Resource Locks and native integrated controls for maintenance.
Summary
There’s no doubt that Azure Blueprints is a powerful product with a number of great benefits for users. Organizations implementing Azure Blueprints into their workflows will be able to deploy consistent environments in a streamlined fashion, speeding up the development and delivery of solutions hosted in Azure.
No additional costs arise by working with Azure Blueprints. The feature is free! As with other Azure Governance services on the platform, the only costs come from the resources deployed with the blueprints themselves.
Configuring everything can certainly be overwhelming and time consuming, but the Azure experts at Scheer GmbH can assist you on your journey to a better, streamlined and compliant cloud strategy.
Author: Hai Ha Tran, Expert for infrastructure consulting
