I'm currently working on designing our Azure infrastructure using Bicep, and I'm facing some challenges in creating a scalable and well-structured architecture. My team manages about 40 resource groups that each correspond to different applications, with both production and development environments. We rarely create or edit new resource groups. Each resource group is expected to include essential components like Virtual Networks (VNet), Network Security Groups (NSG), Log Analytics Workspaces, Application Insights, Databases, and Virtual Machines (VMs). I'm looking for advice or best practices to set this up in a maintainable and modular way. The infrastructure isn't too complex, as most of the applications don't interact with each other, and everything is hosted within the same tenant with different subscriptions. Searching for a simple, modular structure for easy maintenance and updates.
3 Answers
Just a heads-up, it's better to avoid having resource groups that mix environments. Instead, deploy separate environments for each subscription. You can segregate your resource groups by purpose, such as having them for apps, monitoring, and networking. This way, you keep everything organized and manageable. It also helps to share environments for specific resources like AKS while still keeping them in different subscriptions.
You’ve got a few things to rethink here. Firstly, dev and prod resources shouldn’t mix in one resource group. It’s better to use separate subscriptions for development and production. Also, consider separating networking, applications, and data into different resource groups, potentially even utilizing different subscriptions for networking. This separation really helps with security and managing deployments effectively.
I had a similar setup recently. I created three main folders: 1) **core** for basic templates (like databases and app services) that comply with our policies, 2) **templates** for common resource compositions, reusable across apps, and 3) **application** for specific app configurations. Each application has a main.bicep file that uses as many templates as possible. This approach really simplifies maintenance. Additionally, leveraging Bicep's typing and lambda functions can enhance your structure significantly. For instance, have a generic types.bicep for common types you use across your setup.
Also, you can mark outputs as secure to redacted sensitive data when they show up in the Azure portal.
Check out the Azure Developer CLI or any Bicep starter resources. I'm using some core templates I found in the starter repo.