Deze documentatie wordt actief uitgebreid — kom regelmatig terug.

Deployment View

Infrastructure and deployment architecture for Connected Trade Network

Deployment Overview

The Connected Trade Network is deployed on Microsoft Azure (reference cloud) using a cloud-native architecture designed for high availability, scalability, and security. The 2026 delivery centres on the Association Register (ASR); it is packaged as a portable OCI image so the same artefact can run on AWS or self-hosted Kubernetes. Later-phase components are tracked in the Roadmap.

Environment Strategy

Environment	Purpose	Configuration	Data
Development	Feature development, debugging	Single region, minimal resources	Synthetic test data
Testing	Integration and system testing	Single region, production-like	Test data, anonymized
Acceptance	UAT and performance testing	Multi-region, full stack	Production-like data
Production	Live operations	Multi-region, HA, auto-scaling	Real operational data

Azure Resource Architecture

Resource Group Organization

CTN-Production-Subscription
├── RG-CTN-Common-Prod
│   ├── Azure Front Door (Global)
│   ├── Azure DNS Zones
│   └── Shared Key Vault
│
├── RG-CTN-Association-Prod
│   ├── Association PostgreSQL
│   ├── Association API (AKS workload)
│   ├── Participant Portal (Static Web)
│   └── Association API Management
│
├── RG-CTN-Common-Prod (API Management for the discovery API)
│   └── API Management (Premium)
│
└── RG-CTN-Monitor-Prod
    ├── Application Insights
    ├── Log Analytics Workspace
    ├── Azure Monitor
    └── Azure Sentinel

Component Deployment Details

Association Register Deployment

As of November 20, 2025: Migrated from Azure Functions to a containerised Quarkus workload on Kubernetes (AKS), deployed via Helm + ArgoCD, for improved reliability and portability.

Database Tier:

Service: Azure Database for PostgreSQL 15 - Flexible Server
Configuration: Burstable B1ms (1 vCore, 2GB RAM) for dev
Storage: 32GB Premium SSD with auto-grow
Backup: Geo-redundant, 7-day retention
Server: psql-ctn-demo-asr-dev.postgres.database.azure.com

Application Tier (Kubernetes / AKS):

Service: Azure Kubernetes Service (AKS); workload deployed via Helm + ArgoCD (GitOps)
Runtime: Java 25 + Quarkus (OCI image) — per ADR-00002
Image: crctnasrdev.azurecr.io/ctn-asr-api:latest
Replicas: 1-10 (Horizontal Pod Autoscaler on CPU / concurrent requests)
Resources: 0.5 vCPU, 1GB RAM requests per pod
Region: West Europe
Namespace: ctn-asr-dev
Ingress: https://asr-api-dev.ctn.network (via Azure Front Door / ingress controller)

Web Tier:

Service: Azure Static Web Apps (2 instances)
- Admin Portal: stapp-ctn-demo-asr-dev
- Member Portal: ctn-member-portal
Framework: frontend stack not yet decided (see Coding Standards → Open Questions); a React + TypeScript SPA is one candidate
CDN: Azure Front Door with WAF protection
Authentication: Keycloak (OAuth 2.0 / OIDC) with RBAC — per ADR-00002, ADR-00008

Monitoring & Logging:

Log Analytics Workspace: log-ctn-demo (consolidated, Nov 20, 2025)
- 30-day retention, PerGB2018 pricing
- Shared by Application Insights and the AKS cluster
Application Insights: appi-ctn-demo-asr-dev
Active Alerts (4):
- ASR-API-5xx-Errors (Severity 1)
- ASR-High-Request-Rate (Severity 2)
- ASR-High-Memory-Usage (Severity 2)
- ASR-Slow-Response-Time (Severity 2)

Discovery API Gateway

API Gateway:

API Management:
  Tier: Premium
  Units: 2 (multi-region)
  Features:
    - OAuth 2.0 validation (VAD)
    - Rate limiting
    - Response caching
  Regions:
    - West Europe (Primary)
    - North Europe (Secondary)

Components for later phases (Orchestration Register, OPA policy engine, dual-token validation) are tracked in the Roadmap; their deployment-view notes are parked under docs/_out-of-scope-2026/.

Network Architecture

Virtual Network Design

VNET-CTN-Prod (10.0.0.0/16)
├── Subnet-DMZ (10.0.1.0/24)
│   └── API Management, Application Gateway
├── Subnet-Apps (10.0.2.0/24)
│   └── AKS node pool (ASR API pods)
├── Subnet-Data (10.0.3.0/24)
│   └── PostgreSQL, Redis (Private Endpoints)
└── Subnet-Management (10.0.4.0/24)
    └── Bastion, Management VMs

Network Security

Network Security Groups:

Subnet	Inbound Rules	Outbound Rules
DMZ	HTTPS (443) from Internet	Any to Apps subnet
Apps	From DMZ and Management	HTTPS to Data, Internet
Data	From Apps subnet only	Deny all except responses
Management	RDP/SSH from Bastion	Any (monitoring)

Private Endpoints:

All databases use private endpoints
Storage accounts restricted to VNet
Key Vault with private endpoint
Redis Cache private access only

High Availability Architecture

Multi-Region Setup

graph TB
    subgraph "Global"
        FD[Azure Front Door]
        DNS[Azure DNS]
    end
    
    subgraph "West Europe (Primary)"
        APIM1[API Management]
        APP1[Application Services]
        DB1[(PostgreSQL Primary)]
        REDIS1[(Redis Primary)]
    end
    
    subgraph "North Europe (Secondary)"
        APIM2[API Management]
        APP2[Application Services]
        DB2[(PostgreSQL Replica)]
        REDIS2[(Redis Replica)]
    end
    
    FD --> APIM1
    FD --> APIM2
    APIM1 --> APP1
    APIM2 --> APP2
    DB1 -.-> DB2
    REDIS1 -.-> REDIS2

Disaster Recovery

Recovery Targets:

RTO (Recovery Time Objective): 1 hour
RPO (Recovery Point Objective): 15 minutes

Backup Strategy:

Component	Backup Frequency	Retention	Location
Databases	Continuous	30 days	Geo-redundant storage
Blob Storage	Incremental daily	7 days	RA-GRS
Configuration	On change	Unlimited	Git repository
Certificates	Daily	90 days	Key Vault backup

Security Deployment

Certificate Management

Certificate Hierarchy:
├── Root CA (External)
│   ├── TLS Certificates (Let's Encrypt)
│   └── Wildcard: *.ctn.network
├── BDI Signing (Internal)
│   ├── Association Signing Cert (VAD)
│   └── Auto-rotation: 90 days
└── mTLS Certificates
    └── Client certificates for connectors

Key Management

Azure Key Vault Premium: HSM-backed keys
Managed Identities: For service authentication
Secret Rotation: Automated (scheduled job)
Access Policies: Least privilege principle

Monitoring and Observability

Monitoring Stack

Application Monitoring:
  Service: Application Insights
  Features:
    - Distributed tracing
    - Live metrics
    - Custom events
    - Availability tests

Infrastructure Monitoring:
  Service: Azure Monitor
  Metrics:
    - CPU, Memory, Network
    - Database performance
    - Queue depths
    - Cache hit rates

Security Monitoring:
  Service: Azure Sentinel
  Capabilities:
    - Threat detection
    - Incident response
    - Compliance dashboards
    - SIEM integration

Dashboards and Alerts

Operations Dashboard:

System health status
API response times
Token (VAD) generation rates
Active participant / endpoint count

Security Dashboard:

Failed authentication attempts
Suspicious access patterns
Certificate expiration status
Compliance violations

Business Dashboard:

Participant registrations
Endpoint registrations
VAD tokens issued
Data access requests

Deployment Pipeline

CI/CD Architecture

GitHub Repository
    ↓
GitHub Actions (CI)
    ├── Maven build (Quarkus)
    ├── Unit & integration tests
    ├── Security scanning
    └── OCI image build
         ↓
    Artifact Registry
         ↓
    Release Pipeline
    ├── Dev Deployment
    ├── Integration Tests
    ├── Test Deployment
    ├── Load Testing
    ├── Acceptance Deployment
    ├── Approval Gates
    └── Production Deployment

Infrastructure as Code

Infrastructure is provisioned with OpenTofu; the Kubernetes workload is deployed via Helm + ArgoCD (GitOps). Everything runs from the GitHub Actions workflows — never by hand: the pipeline runs tofu plan on pull requests and tofu apply on merge, after which ArgoCD reconciles the Helm release onto the cluster.

Repository layout:

/infrastructure
├── /tofu                      # OpenTofu (cloud resources: AKS, PostgreSQL, networking, monitoring)
│   ├── main.tf
│   ├── modules/
│   │   ├── networking/
│   │   ├── databases/
│   │   ├── aks/
│   │   └── monitoring/
│   └── env/
│       ├── dev.tfvars
│       ├── test.tfvars
│       └── prod.tfvars
└── /deploy
    ├── helm/ctn-asr/          # Helm chart for the ASR API
    └── argocd/                # ArgoCD Application manifests (per environment)

Scaling Configuration

Auto-Scaling Rules

Component	Metric	Scale Out	Scale In	Min/Max
API Management	CPU > 70%	+1 unit	CPU < 30%	2/10
ASR API (AKS HPA)	CPU / concurrent HTTP > threshold	+1 pod	below threshold	1/10
PostgreSQL	CPU > 80%	+4 vCores	< 40%	4/32

Performance Optimization

CDN: Static content caching
Redis: Application data caching
Database: Query optimization, indexing
API: Response caching, compression

This deployment view describes the production infrastructure and operational aspects of the Connected Trade Network.

In samenwerking met