AWS & GCP • Kubernetes • Hybrid • FinOps

Cloud

We were consolidating production onto shared infrastructure before "cloud" was a product category — the region’s first VMware vCentre deployment, DR platforms banks trusted, and AWS estates run with the same discipline as carrier cores. Cloud rewards engineers who already understand networking, systems, and failure modes. That is the practice.

Built on telecom discipline. Executed in the cloud.

01 — Approach

Cloud Rewards Fundamentals

Cloud does not replace engineering fundamentals — it rewards them, and it bills you for their absence. A VPC is a routing domain; an availability zone is a failure domain; an egress charge is a peering decision someone didn’t make. Because we spent two decades in operator networks — planning submarine capacity, building peering, running the region’s first VMware vCentre estate at KDN — we read cloud architectures the way carriers read networks: where does traffic actually flow, what fails together, and who pays for every gigabyte.

The practice spans both directions of the hybrid line. Upward: AWS and GCP architecture, migration, and operations — grounded in AWS training and applied in production, including the AWS deployment delivered for DSI in the DRC. Downward: virtualization and private cloud — VMware, Proxmox, Hyper-V — where data gravity, sovereignty, or the post-Broadcom licence bill argue for owned infrastructure. We have built DR platforms whose early customers (Centum, HELB) later trusted them with primary production; that is the standard resilience work has to meet.

Eight practice areas below. Each stands alone; all of them assume the same truth: operations is where cloud projects live or die, and the bill is an engineering artifact.

02 — What We Deliver

Cloud Practice Areas

Eight disciplines from landing zone to disaster recovery — engineered on fundamentals, priced with eyes open.

AWSGCPLanding Zones

Cloud Architecture & Landing Zones

Accounts, networks, and guardrails designed before the first workload.

Most cloud sprawl is a missing foundation: workloads landed in one account with one flat VPC, and three years later nobody can say what talks to what or why the bill doubled. We build landing zones first — account and project structure, identity and permission boundaries, network segmentation, logging, and guardrails — on AWS and GCP, matched to the organisation rather than copied from a reference PDF. VPC design and CIDR planning get carrier-grade attention because re-addressing a production cloud later is the most expensive network change you will ever make.

Account/organisation architecture: OUs, projects, guardrails (SCPs, org policies), and break-glass design
VPC design and CIDR planning — subnets, route tables, and segmentation that survive growth and peering
Identity foundations: IAM roles and least privilege, federation with Entra ID, and permission boundaries
GCP comparative strengths applied deliberately: global VPCs, native any-to-any routing, and global load balancing
Compute strategy: instance families, autoscaling, spot/on-demand/reserved economics, stateless vs stateful placement
Storage architecture: S3/EBS/EFS and GCS/PD trade-offs on durability, performance, and cost
Logging, audit, and encryption baselines wired in from day one — CloudTrail, KMS, and config rules
Architecture reviews of existing estates: what to keep, what to fix, what to stop paying for

A cloud foundation that scales by addition, not by archaeology.

Go deeperCloud practice page Reference Architecture

Direct ConnectSD-WANTransit Gateway

Hybrid & Cloud Networking

The demarc between your network and the cloud, engineered from both sides.

Hybrid networking is where our carrier history pays directly: latency, routing symmetry, failure propagation, and security boundaries are telecom problems wearing cloud names. We design the connectivity between your sites and your cloud — VPN, Direct Connect / Interconnect, SD-WAN overlays, even satellite backup for hard geographies — and the cloud-side topology it lands in: transit gateways, hub-and-spoke VPCs, and DNS that resolves correctly from both worlds. Cloud-hosted NOCs, monitoring platforms, and OSS/BSS workloads all live on this seam; we have built them there.

Hybrid connectivity design: site-to-cloud VPN, Direct Connect/Partner Interconnect, and SD-WAN integration
Routing architecture across the seam: BGP to the cloud edge, symmetry, and deterministic failover
Transit Gateway / hub-spoke topologies, VPC peering strategy, and shared-services networks
Hybrid DNS and private endpoints so services resolve privately from every site
Latency engineering for African routes: region selection, edge caching, and the paths packets actually take
Satellite and LTE backup paths for cloud-dependent operations in hard geographies
Security boundaries at the seam: inspection points, egress control, and management-plane isolation
Cloud-hosted NOC, monitoring, and OSS/BSS workload placement — designed with the operators who use them

Cloud that behaves like part of your network — with failover you can predict and paths you can defend.

Go deeperEnterprise WAN — SD-WAN & MPLS Cloud practice page

Assess & SequenceWave CutoversRollback-Ready

Migration & Modernisation

Sequenced moves, parity checks, and no bet-the-business weekends.

We have run large migrations where failure was not an option — moving banks, embassies, and UN agencies from satellite to fibre at KDN taught us that migration is a sequencing discipline, not a lift event. Cloud migration gets the same method: assess the estate honestly (including what should not move), choose rehost/replatform/refactor per workload on economics rather than ideology, and cut over in waves with parity checks, rollback points, and the old system kept warm until the new one has earned trust. Modernisation follows adoption, not the other way round.

Migration assessment: dependency mapping, data gravity, licence and egress economics per workload
Honest keep/move/retire calls — including the workloads that are cheaper and better on-premises
Rehost/replatform/refactor strategy per application, costed against business value
Wave planning with parity validation, rollback points, and parallel-run periods
Data migration engineering: replication, cutover windows, and integrity verification
Database moves: managed-service adoption (RDS, Cloud SQL) with performance baselining before and after
Legacy modernisation: containerising what earns it, leaving alone what does not
Post-migration optimisation: rightsizing and architecture cleanup once real usage data exists

Workloads that arrive in the cloud working, on budget — with the receipts to prove parity.

Go deeperCloud practice page Hadoop modernisation (Big Data)

DockerKubernetesEKS · GKE · AKS

Containerization & Kubernetes

Advanced container architecture — from first Dockerfile to production clusters.

Containers are how modern software ships, and Kubernetes is how it runs at scale — but both punish teams that adopt the tooling without the architecture. We design and implement containerization across all the modern platforms: Docker and compose-based stacks where a single host is the honest answer, managed Kubernetes on EKS, GKE, and AKS, and self-managed clusters (k3s, RKE2, kubeadm) where sovereignty, cost, or on-premises placement demand them. The networking heritage matters here more than anywhere: CNI, ingress, service meshes, and cluster egress are routing problems — and we architect them like carrier engineers, not YAML copiers.

Containerization strategy: what to containerise, what to leave alone, and honest sizing of the payoff
Docker engineering: image design, multi-stage builds, registries, and compose stacks for single-host realities
Kubernetes architecture and implementation: managed (EKS, GKE, AKS) and self-managed (k3s, RKE2, kubeadm)
Cluster networking done properly: CNI selection, ingress architecture, load balancing, and network policies
GitOps delivery: Helm, Kustomize, and ArgoCD/Flux pipelines with staged environments and rollback
Stateful workloads on Kubernetes: storage classes, operators, and databases — with the honesty about when not to
Cluster security: RBAC, pod security standards, image scanning, secrets management, and supply-chain hygiene
Autoscaling and capacity engineering: HPA/VPA, node pools, and spot strategies that respect the bill
Observability for clusters: Prometheus/Grafana, log pipelines, and alerts tuned to what actually pages
On-premises and hybrid Kubernetes: clusters on your virtualization estate, wired into cloud control planes

Container platforms engineered for the workload and the budget — not for the conference talk.

Go deeperDevOps & Automation (Helix Studios)Cloud practice page

VMware & ProxmoxPost-Broadcom StrategySAN Engineering

Virtualization & Private Cloud

The owned half of hybrid — run with the discipline it deserves.

We deployed the first VMware vCentre in the region at KDN with Dell, engineered EqualLogic iSCSI SAN storage underneath it, and built shared virtualization platforms whose capacity was leased to third parties at DSI. Private cloud is not legacy — for data-heavy, latency-sensitive, or sovereignty-bound workloads it is frequently the correct answer, and the post-Broadcom licence reality has made the question strategic again. We design, migrate, and operate estates across VMware, Proxmox VE, and Hyper-V, and we model the stay/migrate/hybrid decision on numbers, not vendor pressure.

vSphere/vCentre design, lifecycle, and health remediation — grounded in formal VMware training and estates run since 2010
Post-Broadcom strategy: stay/migrate/hybrid cost modelling across vSphere, Proxmox, Hyper-V, and KVM stacks
Hypervisor migrations executed workload-by-workload with rollback — not big-bang conversions
Storage architecture: iSCSI SAN design, multipathing, snapshots, and replication scheduling (Dell EqualLogic heritage)
Consolidation engineering: sizing, oversubscription discipline, and the power savings that funded our KDN Telehouse work
Shared/private cloud economics: leasing virtual capacity, chargeback models, and tenant isolation
High availability and clustering: failure domains, quorum, and maintenance that does not take production down
Virtualization security: management-plane isolation, VM escape surface reduction, and backup immutability

An owned platform with cloud-grade discipline — and a hypervisor bill you chose, not inherited.

Go deeperSystems engineering (Enterprise)Cloud practice page

RunbooksAlert DisciplineNamed Ownership

Cloud Operations & Observability

Where cloud projects live or die — run like a NOC.

Deployment is a week; operations is a decade. The failure pattern is always the same: monitoring incomplete, alerting noisy, changes undocumented, costs ignored, nobody owning the system end-to-end. We run cloud estates the way we ran carrier NOCs — alarms that mean something, runbooks that match reality, change discipline with rollback, and a named owner for every system. CloudWatch, Cloud Monitoring, Grafana, and log pipelines get engineered deliberately: collect what informs a decision, alert on what demands an action, archive the rest cheaply.

Observability architecture: metrics, logs, and traces with retention tiers that respect the budget
Alert engineering: severity taxonomy, escalation paths, and the war on alert fatigue
Runbook development for cloud incidents — including the cross-seam failures hybrid estates produce
Change management: IaC-gated changes, maintenance windows, and rollback rehearsals
Patch and lifecycle management across instances, managed services, and container platforms
Availability engineering: SLO definition, error budgets, and multi-AZ design reviewed against real failure modes
Managed cloud operations under SLA — or co-managed alongside your team with structured handover
Monthly operations reviews: incidents, spend, capacity, and the fix list actually getting fixed

A cloud estate somebody demonstrably owns — measured, patched, and boring in the best way.

Go deeperManaged IT & NOC (Enterprise)Cloud practice page

Tagging & AllocationRightsizingUnit Economics

FinOps & Cost Engineering

Cloud bills punish sloppy engineering. We engineer the bill.

Every line on a cloud invoice is an engineering decision someone made — or failed to make. We practise FinOps as engineering, not spreadsheet archaeology: tagging and allocation so every shilling has an owner, rightsizing driven by real utilisation, commitment strategy (savings plans, reserved capacity, spot) matched to workload stability, and egress economics treated as the peering problem it is. In 2026 the remit is wider than "cloud" — GPU and AI-service spend, SaaS, licences, and the private-cloud racks all belong in one unit-economics view. The KDN Telehouse and DSI consolidation projects cut facility power outright; the same instinct applied to cloud cuts invoices.

Cost visibility foundations: tagging standards, allocation, and showback/chargeback per team or product
Rightsizing programmes from real utilisation data — compute, storage tiers, and idle-resource reaping
Commitment strategy: savings plans, reservations, and spot adoption engineered per workload profile
Egress and data-transfer engineering: architecture changes that remove transfer costs at the design level
AI/GPU spend governance: quota discipline, batch scheduling, and consumption alerts before the surprise
Unit economics: cost per customer, per transaction, per gigabyte — the numbers a board can steer by
Anomaly detection and budget alarms wired to owners, not shared inboxes
Cloud vs on-prem TCO modelling for the workloads where owning wins

A bill that trends with the business, not against it — and no invoice line without a named owner.

Go deeperCloud practice page

Multi-AZ / RegionImmutable BackupDrilled Failover

Cloud Resilience & Disaster Recovery

Resilience proved by drills — the standard banks held us to.

We built DR platforms whose early corporate customers — Centum, HELB — trusted them enough to later move primary production onto them. That is the bar: recovery infrastructure good enough to run the business. In the cloud era we design resilience in layers — multi-AZ by default, multi-region where the business case is real, and cloud-DR for on-premises estates (including Azure Site Recovery and replication into AWS) with the failback plan most designs forget. Immutable, air-gapped backup copies and clean-room restore procedures answer the ransomware question. And everything gets drilled, because an untested DR plan is a hypothesis with a budget.

Resilience architecture: failure-domain analysis, multi-AZ design, and honest multi-region cost/benefit
Business impact analysis with signed-off RTO/RPO per system — targets engineering can actually meet
Cloud DR for on-prem estates: replication topologies, Azure Site Recovery, and pilot-light/warm-standby designs
Backup architecture: 3-2-1-1-0 with immutability, air-gapped copies, and lifecycle-tiered retention
Ransomware resilience: isolated recovery environments and clean-room restore procedures
Failover and failback orchestration — the return journey most DR designs forget
Scheduled DR drills with timed, reported results — and the architecture fixes they expose
Chaos-informed testing for cloud-native stacks: kill an AZ on purpose before the region does

Recovery as a rehearsed procedure with measured times — resilience you have watched work.

Go deeperBusiness Continuity & DR (Enterprise)Cloud practice page

03 — Ecosystem

Platforms & Provenance

Delivered under AWS and Google Cloud partnerships, grounded in AWS certification and re/Start training, VMware vSphere and Dell EqualLogic formal training — and proven from the region’s first vCentre estate at KDN to the DSI virtualization and AWS delivery in the DRC.

AWS
Google Cloud
Microsoft Azure
VMware vSphere
Proxmox VE
Hyper-V
Docker & Kubernetes
Terraform & Ansible
Grafana & CloudWatch

Start With Your Estate as It Actually Runs

A Phase 0 review maps your workloads, network seams, spend, and recovery posture as one system — and tells you what belongs in the cloud, what does not, and what it should all cost.

Begin Phase 0 Review See the Practice Page