clarify reliance on bicep

[trondhindenes]

Overview of feature request

I get the impression that radius is tightly coupled to the bicep language. There's some mention of terraform in the docs too, but as a person just browsing the docs it's very difficult to determine if radius requires bicep or just supports it. We're not an azure shop, and we are reluctant to introduce yet another language/dsl to our stack.

Acceptance criteria

Some docs section description radius' relationship to bicep - whether it's required or not

Additional context

No response

Would you like to support us?

• Yes, I would like to support you

AB#13121

AB#13153

[radius-triage-bot]

👋 @trondhindenes Thanks for filing this feature request.

A project maintainer will review this feature request and get back to you soon.

We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.

For more information on our triage process please visit our triage overview

[itpropro]

It's detailed in the docs:

What languages does Radius support?
For application code, Radius supports any programming language as long as it is containerized.

Radius resources (applications, environments, portable resource) can be authored in Bicep. See the Radius resource schema for more details. Additional support for other languages (like Terraform) is on our backlog.

Recipes support both Bicep and Terraform. See the Recipe docs for more details.

(https://docs.radapp.io/concepts/faq/#what-languages-does-radius-support)

I would recommend using Bicep, it's not that much change if you already know Terraform.

[trondhindenes]

Thanks for the link. So, resources have to be bicep, while recipes can be either terraform or bicep. It's not completely clear to me how resources and recipes play together, but regardless it seems to me that there's no way around using bicep if an org wishes to implement radius.

The orgs I work with use neither terraform nor bicep, preferring to use higher-order languages such as cdk/pulumi for IaC so radius is probably not a good fit then.

[itpropro]

Thanks for the link. So, resources have to be bicep, while recipes can be either terraform or bicep. It's not completely clear to me how resources and recipes play together, but regardless it seems to me that there's no way around using bicep if an org wishes to implement radius.

The orgs I work with use neither terraform nor bicep, preferring to use higher-order languages such as cdk/pulumi for IaC so radius is probably not a good fit then.

Pulumi for example has a smaller range of use cases than TF, as they are great when you use it from within applications, for example a shared service that deploy resources either directly for customers or to provide a specific functionality. It would be very hard to achieve the same level of use case coverage that you have with Bicep or TF, especially as you have additional overhead in CI/CD and for the skills required.
But if you have the right people and you whole process is built around Pulumi, I totally agree, you will probably not have the best time.
What I saw in some companies that worked a lot with Pulumi was that they worked with TF in parallel to close some of the Pulumi gaps and for services like Radius. The good thing is that if you don't use Bicep or TF, yet, you could directly go for Bicep and have the best Radius experience possible.