Skip to content

Service 04 · Cloud

Somewhere is still a place.

Cloud does not remove the questions of where a workload runs, what it costs to keep running, who may reach it and which jurisdiction the data sits in. It changes who answers them, and how quickly the answer can be wrong.

Where is a question

Regions, latency and data residency are constraints before they are architectural preferences.

The service, by capability family

Eight families, in roughly the order they are needed. Most engagements start in the middle, because something is already running.

Cloud strategy and architecture

  • Assessment of the estate as it runs today, and what it costs
  • Target-state architecture, and the case for reaching it
  • Workload placement — public, private, hybrid or unchanged
  • Residency and sovereignty decisions made deliberately

Landing zones and platform foundations

  • Account and subscription structure
  • Identity federation and access boundaries
  • Guardrails and policy applied before workloads arrive
  • Environment separation and repeatable provisioning

Migration and modernisation

  • Assessment of what should move, and what should not
  • Re-host, re-platform and re-architect, chosen per workload
  • Data migration and cutover sequencing
  • Rollback that is real, not theoretical

Compute, storage and hybrid infrastructure

  • Compute, storage and managed database services
  • Virtualisation and on-premise estate alongside cloud
  • Storage tiering, lifecycle and capacity planning
  • Hybrid operating patterns a team can support long term

Cloud and enterprise networking

  • Network design, segmentation and connectivity
  • Routing, private links and hybrid connectivity to on-premise
  • Remote access, site-to-site links and third-party connectivity
  • Traffic management and edge delivery where it matters

Cloud-native platforms and automation

  • Containers and orchestration where they earn their cost
  • Infrastructure as code and repeatable environments
  • Delivery pipelines shared with the engineering team
  • Platform services offered to internal teams as a product

Resilience, backup and recovery

  • Backup, replication and restore testing on a defined schedule
  • Recovery point and recovery time objectives agreed, then measured against
  • High-availability design across zones, regions and sites
  • Disaster recovery and continuity plans rehearsed against likely failures

Cloud operations, observability and cost

  • Observability — logs, metrics and traces that answer a question
  • Monitoring, alerting and escalation paths
  • Patching, upgrades and change control
  • Spend visibility by service, environment and owner
  • Right-sizing against measured usage, not estimates
  • Managed cloud operations, and who is on call for what

The order it has to happen in

  1. 01

    Assess

    What is running, what it depends on, and what it costs today. Every later decision — what moves, what is rebuilt, what stays — is made against that inventory.

  2. 02

    Build the landing zone

    Network, identity and policy first, so that everything arriving afterwards inherits them rather than negotiating with them.

  3. 03

    Move

    In waves, smallest risk first, with each wave proving the pattern the next one will use.

  4. 04

    Hand over

    The operating model, the runbooks and the on-call rota. A migration that ends at go-live has not ended.

Chosen against the workload

Noble works across public cloud, private infrastructure, the on-premise estate and the hybrid arrangements most organisations run in practice. The platform is chosen against the workload, the residency requirement and what the organisation can operate, not against a supplier relationship.