Skip to main content

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 setupBicep
harder to reproducerepeatable
portal drift possibleconfiguration in code
changes less visiblechanges reviewable
environment setup inconsistentconsistent structure