First class support for bicep in blueprint deployment

[artisticcheese]

Per latest meeting blueprints are left in cold as far as supporting bicep as deployment artifact. Per Microsoft owns statement though (https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/frequently-asked-questions#template-specs). Blueprints will remain a user-experience to compose a governed environment in Azure. So one have to choose to use bicep based desired state or blueprint based one. That's tough choice to make because you are forced to author ARM in blueprint which nobody would want to do once bicep reaches GA.

[alex-frankel]

I'm assuming this means supporting bicep files in the portal UX? Or is this at the API level for managing blueprints-as-code?

For the former, as you note, the current answer to this question is no :(

For the latter, given the migration of blueprint definition -> template specs, the story should be pretty clean to go from bicep -> template specs, as we will update the cli tools to support .bicep files. For example, this will work:

az ts create -f main.bicep ...

So bicep will be able to be used for all blueprint scenarios since template specs are going to support those scenarios, we just have plans to first-classed supporting bicep files in the Blueprint portal UX. Does that help at all?

Either way, happy to leave this issue open and see if there are others that see this as something that needs to be prioritized.

[artisticcheese]

Right now I'm authoring blueprints in VSCode (which does not have good support for ARM inside ARM and hence authoring is horrible) and then publish it as code via Az.BluePrint module (which is another questionable practice since it's not integrated into Az cmdlets). So suboptimal setup at best. What is Microsoft vision how it's supposed to work once bicep/templatespec etc GAs

[alex-frankel]

Basically, whenever you create a blueprint definition today, you will create a template spec tomorrow. We are going to provide a migration tool to convert your definition code into template code. The TS cmdlets/CLI commands are already available in the latest releases if you'd like to try it out today.

If you wanted to try elements of this workflow today, your workflow will be:

1. Author bicep code
2. Compile bicep code into ARM Template JSON with bicep build command
3. Publish template spec to azure (New-AzTemplateSpec -TemplateFile ...)
4. Deploy template spec either via CLI or Portal. Depending on what you need to do with blueprints, this could work for you today since both experiences for deploying template specs are now available. But if you need features like locks, you are stuck since regular template deployments can't create blueprint locks. This is something we are also planning to migrate to a core deployment primitive with deployment stacks

Once all of our templateSpec/deploymentStacks work is done, the workflow will be:

1. Author bicep code
2. Publish template spec to azure with bicep file (New-AzTemplateSpec -BicepFile ...)
3. Deploy template spec via CLI or Portal with all the benefits of a blueprint assignment (locking, version tracking, etc.)

Does that help clarify?

[alex-frankel]

@artisticcheese - I see you added a thumbs-up to the comment. Does this plan look ok to you? If so, I will plan to close this.

[artisticcheese]

@alex-frankel Did you just subtly said that there is no future for blueprints?

Once all of our templateSpec/deploymentStacks work is done, the workflow will be:

Author bicep code
Publish template spec to azure with bicep file (New-AzTemplateSpec -BicepFile ...)
Deploy template spec via CLI or Portal with all the benefits of a blueprint assignment (locking, version tracking, etc.)

[alex-frankel]

The Blueprint brand and UX in the portal is going to stick around, as are all the scenarios you can perform with blueprints, but the blueprint UX is going to take a dependency on Template Specs and Deployment Stacks and the Blueprints Resource Provider will eventually be deprecated.

That being said, we treat Blueprints as a GA service (despite the Preview label), which means we are going to continue to maintain the blueprint APIs for 1-3 years. So all of your existing investments in blueprints will continue to work and be supported, but at some point you will be asked to migrate to the new technologies. We feel strongly that this will be a net-positive as the ARM Template tooling and ecosystem is much more mature than blueprints, so the end to end experience should be better.

Hope that helps clarify, but happy to answer any other questions.

[JustinGrote]

@alex-frankel I know this is closed but can you reconcile with how this works with these (recent March 2021) statements by @pierreroman? https://techcommunity.microsoft.com/t5/itops-talk-blog/azure-blueprints-vs-azure-resource-manager-template-specs/ba-p/2176909

"Conclusion Now that we’ve covered what both Blueprints and Templates Specs are, we understand that:

Yes, 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. Azure Resource Manager Template Specs will NOT displace the need for Blueprints since they server a completely separate purpose."

[alex-frankel]

My comment above is more precise :)

We're working on getting edits made to that post now to clarify -- thanks for flagging.

[JustinGrote]

@alex-frankel thanks, I would probably reword it to be: "If you are using Azure Blueprints today, you can continue to leverage them as a GA supported product. However, if you have no policies defined in your environment, consider starting with Template Specs and watch out for Deployment Stacks, coming soon" https://www.youtube.com/watch?v=-4E5DsC-RcU&t=1657s

This answer said April timeframe for deployment stacks, is there a new planned date? https://docs.microsoft.com/en-us/answers/questions/177308/blueprints-roadmap.html

[alex-frankel]

Fingers crossed early July :)