Azure Infrastructure
The JavaScript platform had to operate inside a tightly controlled enterprise Azure environment.
The delivery layer combined:
- Azure Blob Storage
- Private Endpoint
- private networking
- Bicep
- separate Test / Acceptance / Production environments
Infrastructure view
┌──────────────────────┐
│ Repository │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Azure DevOps │
└──────────┬───────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Test Blob │ │ Acc Blob │ │ Prod Blob │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Planon Test │ │ Planon Acc │ │ Planon Prod │
└──────────────┘ └──────────────┘ └──────────────┘
Blob Storage
Blob Storage provided a central location for:
- the JavaScript library
- environment-specific deployed assets
- supporting documentation
The goal was to remove manual, scattered delivery of JavaScript.
Private Endpoint
The storage layer was not designed as a simple public static host.
Private networking was part of the platform architecture so the solution could fit the secured Azure environment.
Planon / internal environment
│
▼
private network path
│
▼
Azure Storage / Private Endpoint
Infrastructure as Code with Bicep
I used Bicep to provision the Azure infrastructure rather than relying on manual portal configuration.
Simplified public example:
resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Standard_LRS'
}
}
The actual enterprise configuration included more security and networking detail; those internal values are intentionally not reproduced here.
Why IaC mattered
| Manual setup | Bicep |
|---|---|
| harder to reproduce | repeatable |
| portal drift possible | configuration in code |
| changes less visible | changes reviewable |
| environment setup inconsistent | consistent structure |