There were comments like “are blueprint still even a thing?” and “I’m not bothering with Blueprints since templates specs are almost here.”
Maybe I’m missing the meaning of these interactions. Or there is a disconnect. I’m not 100% sure, however, if there is a chance that someone in the community is confused, I decided to cover the difference and when you would them. We’re not going to take you through the creation of each of these since there are many tutorials and resources available online already.
The same can be said for ARM Templates Specs
So, let’s start.
In any enterprise you always have teams that are responsible for defining what and how resources are deployed in your environment. (on-prem, in the cloud or in both). Your networking team defines the network design, the IP addressing, the routing… Your security team defines what services are allowed, who has access… Your legal department may have requirements for compliance such as where you can deploy your resources… You get the picture.
Without any tools to allow you to tie all these requirements together you end up with a deployment process that can take a long time because every teams wants and needs to sign-off on your deployment. And it makes it difficult to replicate since in most cases its tied together with custom scripting.
Azure Blueprint allows you to create a way to package all these components together and makes it super easy to “stamp” your blueprint on any environment dev, test, prod or other.
There are samples available here
One of the greatest problems when managing your infrastructure as code (IaC) with Azure templates is marrying the need for manageable, secure, versions-controlled way while sharing templates. You can use GitHub, or any other “repo”, however if you’re deploying linked templates for example the link requires either a publicly accessible point or a shared access signature to a blob therefore making them secure is more problematic.
Template Specs is a new resource type for storing ARM templates in a resource group. The purpose of doing that is to allow more efficient sharing, deployment, and control of the Templates shared within an organization. In effect your templates become a first party resource type stored in your subscription. They can be standalone or modular, thus providing you with a very flexible way to deploy them.
And yes, Templates Specs also includes an RBAC (Role based access control) but it’s to control who has access to the template itself and what I can do with it (Read access, vs contributor access for example). Not RBAC in terms of controlling what is the access of the resource deployed by said template.
Now that we’ve covered what both Blueprints and Templates Specs are, we understand that Azure Blueprints are still a thing and you should be investigating them in your own environment if you’re not already, to ensure all your deployments conform to all the requirements of your organization
I can even see in the future, Azure Blueprint pointing at Templates Specs as artifacts within a blueprint.
There you have it folks. Let me know in the comments below if you’d like us to cover specific subjects.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.