Minify ARM JSON for deployments

[jftl6y]

During a recent deployment we got an error that the deployment template exceeded the 4MB size limit. When transpiling the Bicep to ARM, the file did in fact exceed 4 MB in size (likely from all of the module references).

I minified the JSON as such
$inp = get-content .\deploy.json | convertfrom-json |convertTo-json -Depth 100 -Compress | out-file compressed.json

which removed the human readable formatting and the file shrunk about 33% and was able to be deployed.

Describe the solution you'd like
Minify bicep when deploying, offer a switch when transpiling the Bicep to ARM to compress the output.

[alex-frankel]

It would be great if we can do this, but the only issue I would foresee is line & position info in error messages being incorrect. TBH, our line & position info is not as accurate as it should be, but this change would mean that all errors with position info would be on Line 1, Column X.

Though maybe we can make it an opt-in option (i.e. bicep build ... --minify)

[kilasuit]

During a recent deployment we got an error that the deployment template exceeded the 4MB size limit.

This is one of the reasons why to me ARM linked templates as opposed to nested templates always made more sense as it stopped you from being able to hit that limit completely, and whilst I never hit this limit I foresaw it being a possibility using nested templates (which bicep essentially spits out a single massive nested template), but this was something that I found was also mitigated further when using template specs too.

Now I can also see why they'd prefer things being nested as it's a single front facing API call vs 10's/100's/1000's or more when using linked templates, so it limits the load and can be better managed internally to Azure Resource Manager with fewer servers. Without knowing fully the architecture of Azure Resource Manager and how it then actually deploys those resources, I can only guess that there certainly could be further optimisations after you've hit that deployment API that could be investigated. However that's something that you'd need access on the Microsoft side to be able to dig in and look into properly.

IMO, if you truly have a deployment that is that complex, you should really be splitting it into stages and sequencing multiple stages (again all automated and not manual) as opposed to expecting that you can do it all from one gigantic deployment. But that's just based on my experience of troubleshooting many failed gigantic deployments that when I then split them into stages they worked so much more consistently, with much fewer errors. This may have changed and also depends on what is being deployed too, so YMMV.

I also agree with @alex-frankel in that it would make troubleshooting a failed deployment, which can already be tough, be significantly much tougher than you really need to make it, potentially wasting more and more time, that is unnecessary, and therefore more costly than needed. But that could be improved too on the ARM side.

So whilst I can see where there may be benefit in this, I can only see more downsides that don't really help overall other than reducing the amount of data being transmitted on the wire at any given time.

As noted in the linked issues, you can do this additionally with using PSBicep too like so in the meantime if you really feel it is important

Hope that helps @jftl6y

Build-Bicep -Path '.\main.bicep' -Compress