|
|
|
|
|
|
by satyavelMS
2371 days ago
|
|
|
Thanks for providing us your specific feedback. I am part of the ARM Deployments Team. We are looking to support export for resource groups(RG) with more than 200 resources. One of the top customer requests with regards to export was the ability to multi-select individual resources in a RG to be exported which we added a few month ago. We have renewed our focus on ARM Template deployments(our infra as code offering) and have a dedicated team working on addressing the pain points described in the thread as well as other deployment issues. We are not going to solve all the problems instantaneously but we are consciously working on it. Would love to get your input on other ARM Deployment related feedback and areas of improvement. If you haven't had a chance you can check out some of the deployment improvements we announced recently in this video: https://www.youtube.com/watch?v=3D-JIKShrws |
|
|
* Comments in JSON -- the standard explicitly bans this, making ARM templates no longer JSON, and hence not processable by standards-compliant tools. Including, hilariously, PowerShell. ConvertFrom-Json barfs, as it should. The correct approach is to have an explicitly non-JSON format like TOML or YAML that allows comments.
* "ARM has this whole time been secretly case insensitive" -- Someone clearly hasn't been notified about the harmful consequences of the Robustness Principle. [1]
* "People say that nobody authors ARM templates from scratch" -- Well, yes. This is because the template format is barely more than serialised RPC and wasn't developed like a proper programming language.
* The tab completion suggests strings that are too long for the dropdown UI and are cut off, making this feature unusable for a lot of ARM fields, such as the resource "type" values, which have long prefixes.
* "This shows as something different in the Portal" -- You have to memorise internal project names, aliases, or other difficult-to-discover names for things instead of simply using the display names. This is not user-friendly.
* A general issue I've seen with JSON-style configuration files is that things that should be side-by-side (e.g.: a bunch of related VM names) are scattered and separated by a lot of repeated "ceremony" text. Take a look at Altova XML Spy, which has a hierarchical grid view that moves such text fields into adjacent columns and rows, much like Excel does. This makes it far easier to spot mistakes or to make bulk changes.
* The "WhatIf" support is hilarious. I updated my Az module yesterday and I don't have that command. In the demo, it did something terrifying and the presenter had to close it. The output looks hideous, not something that looks useful to me.
This is what it boils down to: I don't want color-coded output that is almost-but-not-quite-JSON. I want tabular output. I want to see what happens if I pipe in 1K rows from a spreadsheet into a template. I want ConvertFrom-Json to work. I want to be able to validate things before deploying them. I want to see WhatIf support in the Azure Portal, with the final look. I want more than one tool to be able to process ARM templates. I want ARM templates to default to 2019, not 2015.
Tooling isn't going to fix this.
I want a language designed for humans.
This demo video to me felt like putting lipstick on a pig. Sure, it's better looking, but... still a pig.
[1] https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03....