Cloud & Platform Engineering
Where your systems should run - and why.
We design, build, and run the platforms your systems live on - Azure as our daily driver, AWS as a first-class alternative, your own servers where that's the right call - and we size them to the workload: a single hardened host where that's enough, scale-out groups and orchestrated containers where it isn't. Every platform we build is defined as code, monitored from the first deployment, and exposed to the internet only where it has to be. If you're here for the network side - racks, power, cabling, segmentation - that lives under Networking & Enterprise Connectivity.
- The smallest thing that works is the first proposal, not a concession. It comes with an answer about growth: whether more machines will cover it, or whether that is the point where Kubernetes starts to make sense.
- Every server we put on your premises has out-of-band management configured on the first day - you can bring a host back up without driving to the rack, including when the operating system will not boot at all.
- Terraform and Ansible instead of clicking through a portal - every change is in the history, checked before rollout, and can be rolled back from a known state. A platform can be rebuilt from nothing, not just described after the fact.
- We build the platform on your account and your hardware - the subscription, the domain and the bill are yours from day one. If you have nobody in-house to run it, we offer to run it ourselves: as a separate decision, never as a condition.
- GPU servers are built to the same standard as the rest of the platform: defined in code, monitored from the first day, and priced against the rental alternative before anything is bought.
Before we recommend a platform, we answer seven questions:
- 01
Workload shape - steady, bursty, batch, or a few minutes a day; that decides VM, scale set, container, or function.
- 02
Where the data may live - a region, a country, your own building. For personal data and your customers' data, residency and contracts decide before performance does; for public data they do not decide at all, and we say so straight away.
- 03
Who runs it day to day - your IT, one administrator, or us.
- 04
Cost shape - capex or opex, reserved or on demand, and which tier actually covers the job.
- 05
Exposure - private over a tunnel, public behind zero-trust access, or public by design.
- 06
Scale path - whether the growth you expect fits on what we are putting up, or forces a rebuild. Sometimes the answer is that it will not grow, and does not need to.
- 07
What already exists - the cloud tenant, the rack, the licenses you already pay for.
Managed cloud services pay off when you'll use what they buy - elasticity, built-in operations, one bill. When you won't, a well-run server you already own is the better deal - or leaving what works where it is, with the provider you already have. We'll tell you which case is yours.
Azure
- Compute sized to the workload - hardened virtual machines for single services; Virtual Machine Scale Sets with autoscale rules that scale out under load and back in when it passes; App Service when the workload is a web application that benefits from managed runtimes, deployment slots, and built-in scaling; AKS when there are enough services and environments to justify an orchestrator.
- Provisioning as code - subscriptions, resource groups, virtual networks, and compute defined in Terraform, or Bicep where the estate already uses it, with role-based access and managed identities instead of shared credentials.
- Azure networking - virtual networks, network security groups, VPN gateways, private endpoints, and peering, designed by the same people who build your physical network.
- Storage - managed disks and Blob storage for compute, managed databases where the application calls for them.
- Monitoring - Azure Monitor, Application Insights, and Log Analytics wired in before the first workload lands, with alerts that reach a person.
A managed service you don't use is still a service you pay for. Platform-as-a-service earns its price when it removes operations work you would actually have done.
AWS and multicloud
- AWS as a first-class alternative - EC2 with Auto Scaling groups, VPC design with subnets, route tables and security groups, IAM roles instead of access keys, S3, RDS, and EKS when Kubernetes is the right shape. Same discipline as on Azure: everything in Terraform, monitored from day one.
- Azure and AWS together - VPC and VNet joined over IPsec tunnels with BGP peering between them, so systems on both sides reach each other as if they stood in one network.
Multicloud by design is a strategy; multicloud by accident is two bills and two sets of outages. We'll say which one you have.
Containers and Kubernetes
- Docker Compose on a VM - for a handful of services that belong together; simple to run, simple to hand over.
- k3s - lightweight Kubernetes for small clusters and edge hosts where the full distribution is more than the job needs.
- Kubernetes with Helm, AKS or EKS - when there are enough services, teams, or environments to justify an orchestrator, managed by the cloud where that removes work.
Kubernetes for three containers is an operations burden with no upside; Compose carries it until the requirement changes.
On-premises servers
- HPE, Dell, Supermicro, Lenovo - rack and tower, older generations to current, with out-of-band management (iLO, iDRAC, IPMI) set up from day one.
- Factory-new or post-lease - vetted refurbished enterprise servers deliver the same platform at a fraction of list price when the case calls for it.
- Hybrid with the cloud - on-premises servers connected to Azure or AWS over site-to-site VPN, so identity, backups, or extra capacity can live in the cloud while the rest stays where it is.
- Racking, power, and the network around it - covered under Networking & Enterprise Connectivity; the same team does it.
On-premises hardware without someone to run it is a cloud bill you paid up front.
Virtualization and storage
- Proxmox VE with Ceph - where the case genuinely calls for a cluster, Proxmox is the default: managed through Terraform and Ansible or the GUI, with distributed storage that survives a node failure.
- VMware ESXi and vCenter with vSAN - where it's already in place or the estate is large enough to justify it, with vSAN when storage should live in the same hosts; licensing cost is now a design input, not an afterthought.
- Nutanix - when one vendor for hypervisor, storage, and management fits how the organization wants to operate.
- Hyper-V and on-premises Active Directory (Windows Server) - we configure and run them where they are already in place or where the software a company runs requires them. For new environments we propose the platforms listed above, and Entra ID for accounts and sign-in.
- VMware to Proxmox migration - planned and rehearsed, workload by workload, when licensing changes make the move worth it.
- Backups and recovery - restores that have actually been rehearsed, with an agreed time to be back and an agreed amount you can afford to lose, live under Reliability, Security & Lifecycle Management; we design the platform so that they are possible.
A cluster you can't rebuild from code is a cluster you'll be afraid to touch.
Platform as code, identity, and exposure
- Terraform, Ansible, cloud-init - infrastructure and configuration in Git; changes reviewed, applied, and reversible.
- Secrets - stored and rotated in a vault, never in files or pipelines.
- One identity provider - Entra ID for most of our clients, or the OpenID Connect or SAML provider you already run, is the directory everything hangs off: Azure roles, VPN and Zero Trust access, and sign-in for the products and internal tools we deliver - with access assigned rather than assumed. And where some of the people will never have an account in that directory - on the floor, on the line - we design a separate way in for them and say plainly what it costs in security.
- Exposure by design - private services reachable only over WireGuard; public ones behind Cloudflare Tunnel and Zero Trust Access; hosts hardened by switching off everything the service running on them does not need.
A secret in a repository stops being a secret the day somebody clones that repository.
GPU and AI infrastructure
- GPU servers - built, installed, and configured for training and inference workloads, on-premises or as Azure GPU instances.
Renting GPU capacity for a month is cheap; owning a GPU server that runs two days a week is not. We'll compare both before you buy.
Every project follows the same sequence:
- 01
Discovery - workloads, data residency, who operates it, what already exists.
- 02
Design - platform, exposure, and cost model agreed with you before we build; if the cheaper option is the one you already own, we'll say so.
- 03
Build - everything as code from the start, documented as it is created. You talk directly to the engineers building it, with nobody in between, and we show you where the work stands against the schedule whenever you ask.
- 04
Implementation - cut-overs in windows chosen for the least disruption to your operations.
- 05
Testing and documentation - running alongside the build, so monitoring, access, and runbooks are in place before handover.
- 06
Support - we stay on an SLA for as long as it is needed: until the day your own IT takes the system over, or for years afterwards. The length is yours to set - we tie nobody to a term they did not choose.
At handover you get:
- The infrastructure code, in a repository you own
- An architecture diagram and an exposure map: what's reachable from where
- Administrative access documented, and out-of-band access where there is hardware to reach
- Monitoring and alerting wired to someone who will see them
- A cost model for the platform as built
- Runbooks the next engineer can pick up and follow