Infrastructure Overview

Microtec ERP infrastructure is defined entirely as code using Azure Bicep, deployed at subscription scope via Azure DevOps pipelines. Each environment receives a dedicated VNet and a full set of isolated resource groups.

---

Design Principles

• Infrastructure as Code (IaC): All Azure resources are defined in Bicep. No manual portal clicks in any shared environment.
• Subscription-scoped deployments: The root main.bicep deploys at subscription level, creating resource groups as part of the deployment.
• Environment isolation: Each environment (dev, stage, preprod, uat, prod) has dedicated VNets, resource groups, and access controls. No shared resources between environments except the SQL VM.
• Config-driven: A single services-config.json drives container image names, scaling rules, and environment variables for all 13 microservices across all 5 environments.

---

Environment Inventory

Environment	VNet CIDR	Domain	Purpose
dev	10.0.0.0/16	microtec-test.com	Developer testing, feature branches
stage	10.1.0.0/16	microtecstage.com	Integration testing, QA
preprod	10.6.0.0/16	—	Pre-production validation
uat	10.5.0.0/16	microtec-uat.com	User acceptance testing
production	10.2.0.0/16	onlinemicrotec.com.sa	Live traffic

Shared SQL

mic-backend-shared-sql-rg hosts the SQL Server VM and is shared across all environments. It uses CIDR 10.100.0.0/16. Do NOT rename this resource group — it is referenced by name in multiple pipelines and Bicep modules.

---

Bicep IaC Structure

Devops/azure/infrastructure/
├── main.bicep                  # Subscription-scoped entry point
├── modules/
│   ├── network.bicep           # VNet, subnets, NSGs, peerings
│   ├── container-apps.bicep    # CAE (public + private), container apps
│   ├── key-vault.bicep         # Key Vault + RBAC assignments
│   ├── data.bicep              # SQL databases, Redis, Service Bus
│   ├── storage.bicep           # ACR, blob storage accounts
│   ├── monitoring.bicep        # App Insights, Log Analytics
│   ├── front-door.bicep        # Azure Front Door + WAF policies
│   └── identity.bicep          # User-assigned managed identities
└── params/
    ├── dev.bicepparam
    ├── stage.bicepparam
    ├── preprod.bicepparam
    ├── uat.bicepparam
    └── prod.bicepparam

---

Deployment Pipeline

Infrastructure is deployed via the Azure DevOps container-deployment orchestrator:

Build-BicepParams.ps1

The Build-BicepParams.ps1 script bridges services-config.json and Bicep parameters:

# Located at: Devops/azure/scripts/infra/Build-BicepParams.ps1
# Reads: Devops/azure/config/container-backend/services-config.json
# Writes: Devops/azure/infrastructure/params/{env}.bicepparam (generated)

param(
    [string]$Environment = "dev",
    [string]$ConfigPath = "../config/container-backend/services-config.json"
)

$config = Get-Content $ConfigPath | ConvertFrom-Json
$envConfig = $config.environments.$Environment

# Outputs container image names, replica counts, CPU/memory per service
# into the Bicep parameter file consumed by container-apps.bicep

---

Key Resource Types

Azure Service	Usage
Azure Container Apps	All backend microservices + Keycloak
Azure Container Registry	Docker image storage
Azure SQL Database	Tenant + admin databases (VM-based)
Azure Cache for Redis	Session state, distributed cache
Azure Service Bus	Async messaging between services
Azure Key Vault	Secrets, connection strings
Azure Front Door	CDN, WAF, global load balancing
Azure Blob Storage	Attachments, frontend static files
Application Insights	APM, traces, metrics
Log Analytics Workspace	Centralized log aggregation

---

Managed Identity Strategy

All services use user-assigned managed identities for authentication to Azure services. No connection strings with passwords for Azure-native resources.

---

Related Documentation

• Container Apps — Public vs private CAE, mTLS, scaling
• Key Vault — Secret naming, KV references in CAE
• Naming Conventions — Resource naming patterns
• Resource Groups — Full RG inventory per environment
• CI/CD Overview — Pipeline structure