DevOps & CI/CD
Pipelines, containers, environments and monitoring — so deploying is boring and rollback takes a minute.
The question I ask of any environment I inherit: if this disappeared tonight, how long until it is back, and does anyone actually know? When the answer depends on what someone configured by hand several years ago, that is the first thing to fix — ahead of performance, ahead of cost, ahead of everything.
Architecture that matches the team
The best architecture is the one your organisation can actually operate. A Kubernetes platform with service mesh and GitOps is excellent if someone owns it; if nobody does, it becomes an outage waiting for the person who set it up to be on holiday.
For most teams that means managed services over self-hosted, containers on simpler orchestration over full Kubernetes, and a small number of well-understood components over a diagram that impresses. I will push back on complexity that exceeds what you can maintain, which occasionally means recommending less than you came in expecting to buy.
Infrastructure as code, without exception
Terraform or CloudFormation for infrastructure, Ansible or immutable container images for configuration, remote state with locking, and separate workspaces or accounts per environment. The objective is that recreating an environment is a command rather than an archaeology exercise, and that every production change is reviewable in a pull request.
Where I inherit hand-built infrastructure, importing it into code is usually an early deliverable. It is unglamorous and it is what makes everything after it safe.
Migration to cloud, or between clouds
Lift-and-shift moves you quickly and preserves your existing costs and inefficiencies wholesale. Re-architecting captures the benefits and takes considerably longer. Most successful migrations do both in sequence — move, stabilise, then modernise the pieces where it pays — rather than attempting a rewrite mid-flight.
The parts that consistently take longer than planned: data migration with acceptable downtime, DNS cutover and its propagation, anything with a hardcoded IP address, and licensing that turns out to be tied to hardware. These belong in the plan from the start.
High availability and disaster recovery
High availability handles component failure — instances across availability zones, managed database failover, health checks that remove bad nodes. Disaster recovery handles losing a region, a provider account, or the data itself.
Every DR engagement I run includes an actual restore into a scratch environment, timed, with the gaps documented. A backup nobody has restored from is a hypothesis, and recovery time and recovery point objectives should be numbers you have measured rather than numbers you agreed to in a document. Testing this reliably reveals at least one thing nobody expected.
Security
Least-privilege IAM rather than broad administrative roles, private subnets with no direct internet exposure for anything that does not need it, secrets in a managed secret store rather than environment files or repositories, encryption at rest and in transit, and audit logging that is retained somewhere the compromised account cannot delete it.
Most cloud breaches are misconfiguration rather than sophisticated attack — a public storage bucket, an over-permissive role, a management port open to the world. Reviewing for those specifically is worth more than any single tool.
Cost
Bills rarely balloon from one bad decision. They grow through instances sized for a load test in 2022, storage left on the default class, non-production environments running around the clock, snapshots nobody expires, and data transfer paths that never appeared on a diagram.
Right-sizing against actual utilisation, lifecycle policies, scheduled shutdown of non-production, committed-use discounts where the baseline genuinely justifies them, and tagging that makes the bill legible by team or service. Reductions of a third or more are common on environments that have never been reviewed, usually without giving anything up.
See this in practice: Cloud & DevOps Modernization
Common questions
AWS, Google Cloud or Azure?
For most workloads the technical differences matter less than existing skills, existing commercial relationships and the specific managed services you need. AWS has the broadest service range and deepest hiring pool; Azure fits organisations already committed to Microsoft licensing; GCP is strong on data and Kubernetes. I would choose based on what your team knows rather than on feature comparison.
Should we use Kubernetes?
Only if someone will own it. Kubernetes solves genuine problems at scale and introduces a substantial operational surface — upgrades, networking, storage, RBAC. For teams running a handful of services, managed container platforms deliver most of the benefit for a fraction of the burden. I have recommended against Kubernetes more often than for it.
How much can we realistically save on our bill?
On an environment that has never been reviewed, a third is a common outcome and more is possible where non-production runs continuously or instances were sized for a peak that never recurred. The review itself is quick; the savings are mostly right-sizing, storage lifecycle and shutting down what is idle rather than anything architecturally dramatic.
Can you work with our existing DevOps team?
Yes, and that is frequently the arrangement — a second pair of eyes on architecture, taking on a specific migration, or covering an area the team has not done before such as disaster recovery testing. Knowledge transfer is explicit rather than assumed; leaving a team dependent on me is a bad outcome for both of us.
Do you provide ongoing infrastructure support?
Yes, typically as a retainer covering monitoring and alert response, patching and updates, backup verification, cost review, and a defined amount of engineering time each month. For anything requiring 24/7 response I would rather help you set up appropriate on-call arrangements than be a single point of failure.
Want to talk this through?
Describe the problem in your own words — I will tell you what I would actually build, and what I would not.
Start a conversation