ResourceModules VS bicep-registry-modules

That is a great question, and not the least because it's the one I've been struggling with for the past few years. As for Azure and Bicep, we tried out a few things until we found out about the Common Azure Resource Modules Library (https://github.com/Azure/ResourceModules) and started experimenting on how to leverage that. Wheter you find such modules useful or not, I would suggest taking a look at the module design principles they have (https://github.com/Azure/ResourceModules/wiki/The%20context%20-%20CARML%20library), which I've found to be great.

In general resource group is lifecycle and deployment boundary. So your Bicep or ARM templates should deploy resource groups with all resources included. To make it easier you can use resource modules from https://github.com/Azure/ResourceModules.

For modularized Bicep, I'd suggest you to take a look at Common Azure Resource Modules Library - probably not much of an use right now if you have implemented everything, but could be of use if you feel like refactoring something. I wouldn't suggest it as an example on how to do custom bicep implementation, but one can certainly take some inspiration from there, if not directly using the modules.

What I found is that using the Resource Modules (https://github.com/Azure/ResourceModules) repo is the best approach. It simplifies the authoring quite a lot in my opinion. And every module on the repo is bicep. But since the modules are created by Microsoft/the community, not every resource or service has a ready module. I have been using it for the last 6-8 months, and find it covers 90% of my scenarios. And each module is quite well documented, but in some cases you have to study the module to figure out the required inputs.

We don't have a team in place to update and maintain modules so that's where my thought about CARML comes into the picture. Unsure how this is maintained though and how to update the modules, and i think it makes it more complex and hard to understand for people unfamiliar with IaC.

We have a separate parameter file for every landing zone instance (our implementation is a bare-bones CAF landing zone, kinda like https://github.com/Azure/bicep-registry-modules/tree/main/modules/lz/sub-vending, which is avaible from bicep public registry), where instance is for example a separate environment (dev/test/prod). This parameter file only represents the configuration, so things like subnets, nsgs and so on, and it has nothing to do with the landing zone implementation as such.

As you point out, it is another layer of abstraction that can make it more complex. Specifically it will add a pain point with the replication of the modules from /ResourceModules to the private repo. (I dont have a good solution for that at the moment) Microsoft has a public container registry (https://github.com/Azure/bicep-registry-modules) that someday may be updated to contain everything in /ResourceModules

Still a work in progress, but the official bicep registry - https://github.com/Azure/bicep-registry-modules