Closed steeling closed 3 years ago
I think it is too late for this. And as far as I understood most people have voted for language that is not tied to json or yml already thus the current approach.
Don't get me wrong, I was one of the few people to vote on improved json language rather the current one but once something is set you have to embrace it :)
We're all for having a ARM/Bicep jsonnet library -- having more options for generating templates is a good thing in our minds so customers can pick the language they like. However, we are not likely to reroute resourcing from bicep to a project like this. We'd be happy to support it however else we can.
Is it possible to quantify this reasoning a bit more? ie: it'll take X software engineering weeks to wrap up Bicep, and Y software engineering weeks to create jsonnet templates.
If Y is unknown can we spend ~10% of X on an experiment to scope Y?
I think if we count for the maintenance of Bicep X >> Y, and I know it sucks to throw away code (actually it's my favorite thing to do, but that's just me :) ), but I think it might be best to consider what is best for the business/ecosystem, especially if they accomplish the exact same thing, and you make adoption easier by providing an already existing language.
We spent a lot of time doing that calculus internally before deciding to move forward with the bicep project. We get that it's a big effort and there are risks involved. We wouldn't move forward with the project if we did not think it was best for the business & ecosystem.
That xkcd comic is about establishing some new universal standard, which is something we are explicitly not trying to do. We accept that there should be/will be lots of tools to deploy to Azure and they should all be great. We feel Bicep is the right tool for the audience we are focused on and it justifies the resourcing. We could certainly be wrong and it would not be the first time -- that's part of why we are releasing this so early.
I'm happy to leave this thread open and continue to hash out how a bicep/arm template library could be created for jsonnet, but if the goal is to stop the bicep project in favor of a jsonnet equivalent, that is not likely something that will gain much traction.
gotcha, thanks for the perspective! Ya definitely interested in jsonnet templates. Happy to move that to a new thread or keep that open here.
It's probably fine to leave this one open, but I'm good either way. Thanks!
Making anything look like JSON is taking the step back. I personally prefer YAML and ansible like approach with jinja2 or hcl2. The closest bicep gets to what terraform and hcl2 offers the better. Leveraging what-if and Azure blueprints with hcl2 look-alike is IMHO good way forward.
I personally believe that terraform/hcl2 has contributed to very large increase of Azure usage while JSON/ARM on its own had the opposite effect especially in IAC areas.
I do not think JSON/ARM had the opposite effect. I think the JSON/ARM usage has increased over time thus you see some of the API problems that were there for years being fixed.
Granted, however ARM grew alongside with Azure itself. I see JSON/ARM being very good for machines and more experienced users. Terraform/HCL is great for junior IAC devs and engineers making transition from onprem to cloud. In fact it is not uncommon to see HCL being the first programming* language for cloud engineers. Also in many cases it is quicker/easier to find ARM documentation on terraform website than Azure docs or rest API specs.
Hi all! I was hoping to open a discussion around leveraging jsonnet as opposed to building an entire new DSL. I've ran into a lot of frustrations with writing these types of yaml/json files, so understand the desire to create something simpler, but I've had a positive experience with jsonnet in the past, and think that it could be a good fit here.
jsonnet is a Pros:
prod_az1_config
which inherits from aprod
config, which in turn inherits from abase_config
, reducing the amount of duplication among configurations.Cons:
Possible next step:
I'll note that the jsonnet templates can enforce certain patterns to keep them more simple.