Hey everyone! I'm currently working at a company that sets up a separate resource group for each microservice, and each microservice is deployed across development, testing, and production environments in three different regions. This means each microservice has its own storage account, application insights, and if it uses CosmosDB, that too is included in the resource group.
For example, if we add a new microservice that requires a storage account and CosmosDB, it results in 9 resource groups, 9 storage accounts, 9 application insights, 9 Cosmos DB instances, and 9 web apps/functions!
I'm starting to feel like this is way too much overhead. It almost makes storage containers seem pointless since every resource has a dedicated storage account. Plus, finding specific resources can get really tricky.
So, is this how it's commonly done? What's the best way to organize resources? I'd love to hear your thoughts or if anyone has good articles on best practices!
3 Answers
What you're describing isn't too excessive in general, but I recommend having a single Cosmos account per environment with multiple databases for each. Keeping storage accounts and application insights separate is smart, although I'd suggest having one log analytics workspace per environment. Are you using Infrastructure as Code (IaC) for setup? That's where it really helps!
Yeah, that makes sense for Cosmos. What about the storage accounts, though?
Resource groups are really just for grouping resources that have a shared lifecycle—basically, things that you want to create or delete as a unit. They can also be used for permissions management in larger IAM setups. Regional resource groups can sometimes make sense, but often they’re seen as an anti-pattern since it's better to include region details in the names of the resources directly. Each storage account has its own replication modes and it's good to keep that in mind!
You might want to check out the Cloud Adoption Framework (CAF) and enterprise landing zones. Generally, resource groups (Rgs) are not as crucial since the real separation usually happens at the subscription level. It's pretty standard to have some duplication across environments. Just remember, production shouldn't share dependencies with development—though it's fine to share infrastructure like DNS.
We've been using a shared application insights per environment (like one for all 'dev' and another for 'prod'). What’s the advantage of keeping them separate? We use cloud_role_name to differentiate between deployed instances, which helps with searches.