Discuss jsonnet as alternative to Bicep

[steeling]

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:

• OSS
• Has been around for a long time
• Looks similar to json
• Allows for more complicated logic
• Already adopted in k8s community (ksonnet, https://github.com/grafana/tanka, prometheus operators https://github.com/prometheus-operator/kube-prometheus/tree/master/jsonnet/kube-prometheus)
• Simple templates can provide a clean API that transpiles to ARM json templates.
• Don't need to maintain a completely separate DSL.
• Huge savings in dev time since writing jsonnet templates should be relatively trivial.
• Users don't need to learn an entire new DSL.
• Nested hierarchies and overrides allow for simple instatiation of templates even with multi deployments, ie: imagine you have prod, with 2 availability zones, and staging also with 2 availability zones. It is trivial to have a prod_az1_config which inherits from a prod config, which in turn inherits from a base_config, reducing the amount of duplication among configurations.

Cons:

• Might not be perfectly tailored.
• Maintaining jsonnet templates.
• Allows for more complicated logic

Possible next step:

• Create some jsonnet templates and compare/contrast with bicep templates.

// azure_rm_templates.libsonnet

local BaseObject(_config) = {
  name = _config.Name,
}

VM(_config) = BaseObject(_config) {
  properties = {
      diskSize = _config.diskSize,
      example_default_property = 'WindowsVM',
  }
}

//my_base_deployment.libsonnet

import "azure_rm_templates.libsonnet" as azrm_templ
{
 _config = {/*config values */}
  BaseVM = azrm_templ.VM(_config)
}

// prod.libsonnet. Note: libsonnet files are templates, while jsonnet files are leaf files.

import "my_base_deployment.libsonnet" as base
{
  _config = base._config {
    Name = "prod_" + super.name,
  }
  VM = Base.VM(_config)
}

// prod_az1.jsonnet
// this inherits all of prod.
import "prod.libsonnet" as prod

prod {
  // Overide the config tuple within prod.
  _config+: {
     Name = super.Name + "_az1"
  }
}

I'll note that the jsonnet templates can enforce certain patterns to keep them more simple.

[slavizh]

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.

[slavizh]

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 :)

[alex-frankel]

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.

[steeling]

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.

https://xkcd.com/927/ :)

[alex-frankel]

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.

[steeling]

gotcha, thanks for the perspective! Ya definitely interested in jsonnet templates. Happy to move that to a new thread or keep that open here.

[alex-frankel]

It's probably fine to leave this one open, but I'm good either way. Thanks!

[JayDoubleu]

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.

[slavizh]

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.

[JayDoubleu]

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.