Division 06 — Cloud infrastructure

Nexiv Cloud

The infrastructure division. Multi-region Kubernetes, everything described as code, progressive delivery, real observability and a disaster recovery plan that has actually been executed.

Talk to the platform team System status

Multi-region active-active 100% infrastructure as code 24/7 on-call

Region topology

8 edge regions residency-pinned tenants

Platform pillars

What the infrastructure division actually owns

Compute & orchestration

Managed Kubernetes across multiple regions with autoscaling, spot capacity for stateless workloads, pod-level resource governance and node pools isolated by data classification.

Infrastructure as code

Terraform modules for every resource, GitOps reconciliation with Argo CD, and admission policy that rejects non-compliant manifests before they ever reach a cluster.

Observability

OpenTelemetry traces on every request, structured logs with correlation IDs, RED and USE dashboards per service, and alerting driven by symptoms rather than by CPU graphs.

Progressive delivery

Canary and blue/green rollouts driven by SLO signals. If error budget burn accelerates during a rollout, the deployment reverses itself without waiting for a human.

Security & secrets

Workload identity instead of long-lived credentials, secrets from a managed vault with automatic rotation, network policy default-deny, and image signing verified at admission.

FinOps

Cost attributed per division, per service and per environment, with budget alerts, rightsizing recommendations and a standing review that removes orphaned resources.

Platform latency

Rollout

Reliability engineering

Error budgets, not heroics

Every service has a stated objective and a budget for failing it. When the budget is healthy we ship fast; when it is burning, feature work stops and reliability work starts. That decision is a rule, not an argument.

Objective	Target	Measured as
Availability	99.9% monthly	Successful requests ÷ total, per tenant
Latency	p95 < 300 ms	Server-side API response, excluding media
Durability	RPO ≤ 5 min	Point-in-time recovery window
Recovery	RTO ≤ 60 min	Region failover, tested quarterly
Change failure	< 5%	Deploys requiring rollback or hotfix

Contractual commitments and the service credit schedule are in the Service Level Agreement.

Data residency

Where the data lives is a configuration, not a hope

Tenants are pinned to a region at provisioning. Clinical data does not replicate outside it, backups stay in-region, and the pinning is enforced by admission policy rather than by convention.

Region selected per tenant: UK, EU or US
Storage classes and queues bound to the tenant's region
Cross-region calls blocked at network policy for pinned workloads
Encryption keys held per region, with tenant-scoped envelope keys
Sub-processor list published and versioned in the Trust Centre

Read the trust centre

platform/tenants/acme.tf

# Residency is declared, reviewed and enforced.
module "tenant" {
  source   = "../modules/tenant"

  name     = "acme-health"
  tier     = "clinical"
  residency = "uk"          # uk | eu | us

  encryption = {
    kms_key       = "tenant-scoped"
    rotation_days = 90
  }

  backup = {
    pitr_window_minutes = 5
    retention_days      = 35
    cross_region        = false   # clinical: never
  }

  slo = {
    availability = "99.9"
    latency_p95_ms = 300
  }
}

Incident response

What happens when something breaks

Not if — when. The value of an incident process is that it is identical at 3am on a bank holiday and at 3pm on a Tuesday.

T + 0 MIN

Detect

SLO-based alerting pages the on-call engineer. Symptom alerts only — nobody is woken by a CPU graph.

Automated

T + 5 MIN

Declare & communicate

Severity assigned, incident channel opened, status page updated. Affected customers hear it from us first.

Incident lead named

T + 15 MIN

Mitigate

Restore service before diagnosing it: roll back, shed load, fail over to a healthy region. Root cause can wait.

Rollback first

T + 5 DAYS

Review & fix

Blameless post-incident review with dated, owned actions — and a customer summary for any Severity 1 or 2 event.

Published to affected tenants

Questions

Common questions

Yes. The managed platform offering gives an external client the same Kubernetes foundation, delivery pipeline, observability stack and on-call rotation we run for our own divisions. We can operate in your cloud account so ownership of the underlying resources never leaves you.

We standardise on Kubernetes and Terraform precisely so the provider is a substitutable layer. We use managed services where they are genuinely better and accept the coupling deliberately, documenting the exit path for each one rather than pretending portability is free.

Quarterly, as a real exercise against a live-like environment — restoring from backup and failing over to a secondary region against the stated RTO and RPO. The results, including anything we failed, go into the platform review. A recovery plan that has never been run is a document, not a plan.

Nobody standing. Production access is just-in-time: requested against a named ticket, approved by a second person, time-boxed, fully session-logged and revoked automatically at expiry. Clinical data access additionally triggers a record in the tenant's own audit log.

Hand us the pager

Migration, platform build or fully managed operations — we will start with an honest assessment of what you run today.

Talk to the platform team Read the SLA