Modify Web App + MongoDB sample to add Network Services and Log Analytics

[paolosalvatori]

Description

This pull request modifies the Azure Web App with Azure Cosmos DB for MongoDB sample by adding the following resources:

1. Azure Virtual Network: Hosts two subnets:
   • app-subnet: Dedicated to regional VNet integration with the Function App.
   • pe-subnet: Used for hosting Azure Private Endpoints.
2. Azure Private DNS Zone: Handles DNS resolution for the Cosmos DB for MongoDB Private Endpoint within the virtual network.
3. Azure Private Endpoint: Secures network access to the Cosmos DB for MongoDB account via a private IP within the VNet.
4. Azure NAT Gateway: Provides deterministic outbound connectivity for the Web App. Included for completeness; the sample app does not call any external services.
5. Azure Network Security Group: Enforces inbound and outbound traffic rules across the virtual network's subnets.
6. Azure Log Analytics Workspace: Centralizes diagnostic logs and metrics from all resources in the solution.

The pull requests modifies also the following artifacts:

1. Bicep modules. Now they are organized in separate modules, one for each resource type.
2. Terraform modules. Same as above, one for each resource type.
3. Deployment scripts
4. README.md files
5. Architecture diagram
6. Visio file.

Testing

All the samples have been successfully deployed on both Azure and latest version of the LocalStack for Azure emulator.

[bryansan-local]

In the case of Terraform, I would say it is far better, cleaner and with less amount of files if instead of having multiple terraform modules we just have one terraform file per resource. Like instead of having this structure:
app_service_plan:
- main.tf
- outputs.tf
- variables.tf

just do app_service_plan.tf with no variables nor outputs blocks. Just use the resource block

that will remove the whole ceremony of variables.tf and output.tf. I would understand the current structure if this module were going to be reused or shared outside of the samples like the AVM initiative of microsoft but here it is only used by this sample sooo.... in my head is unnecessary.

Yea in Bicep we are forced to use the modules structure even when is not necessary (hence why i hate it) but in terraform we don't have to.

PS: I don't really want to open an unhealthy 1h debate like the ones we always have sooo if you dont agree with my perspective I wont be a blocker for this PR

[paolosalvatori]

In the case of Terraform, I would say it is far better, cleaner and with less amount of files if instead of having multiple terraform modules we just have one terraform file per resource. Like instead of having this structure: app_service_plan: - main.tf - outputs.tf - variables.tf

just do app_service_plan.tf with no variables nor outputs blocks. Just use the resource block

that will remove the whole ceremony of variables.tf and output.tf. I would understand the current structure if this module were going to be reused or shared outside of the samples like the AVM initiative of microsoft but here it is only used by this sample sooo.... in my head is unnecessary.

Yea in Bicep we are forced to use the modules structure even when is not necessary (hence why i hate it) but in terraform we don't have to.

PS: I don't really want to open an unhealthy 1h debate like the ones we always have sooo if you dont agree with my perspective I wont be a blocker for this PR

Thanks for the feedback @bryansan-local! I appreciate the perspective. The modular approach, where each resource is encapsulated in its own module with main.tf, variables.tf, and outputs.tf, is a well-established Terraform best practice. The flat and simple approach you propose with a single Terraform file per resource is definitely simpler, but less maintainable. It's fine to create a single main.tf for small samples, but this approach is unfit for large samples. And missing to define an output.tf and variables.tf files is an antipattern. The current structure provides the following benefits:

1. Reusability across samples. These modules are not scoped to a single sample. When I was at Microsoft, I created my set of Bicep and Terraform modules, and any time I wanted to build a new sample, I was composing them like Lego bricks. The Bicep and Terraform modules I created are designed to be reused across multiple samples and projects. A flat structure would force us to duplicate resource definitions every time, which is exactly the problem modules were created to solve.
2. Alignment with industry best practices. The module-per-resource pattern with explicit inputs (variables.tf) and outputs (outputs.tf) follows the conventions promoted by HashiCorp and adopted by initiatives like Microsoft's Azure Verified Modules (AVM) that I heavily contributed to. Since these samples are customer-facing, they should reflect the standards our customers are expected to follow in their own environments.
3. Customer perception and sample quality. These samples serve as reference implementations for our customers. If we present a simplified, non-modular structure, customers may reasonably infer that this reflects the quality of our product. Providing well-structured, enterprise-grade samples reinforces confidence in both our engineering standards and our platform.

I hope this clarifies my approach and why we'll use this approach from now on for complex projects.

P.S. No AI assistant was used to create this comment 🙂