How do I choose which service I need first?
Start with the problem that is costing you the most today, not with the technology you think you should adopt. If you are not sure what that problem is, the Cloud and DevOps Health Check package is a read-only review that ranks findings by risk and effort, so the order of work is decided by evidence rather than preference.
If you already know the problem, the four groups on this page map to four common situations. Cloud foundations is for teams still moving to the cloud or running on hand-built infrastructure. Delivery is for teams whose releases are slow, manual or frightening. Platform operations is for teams running Kubernetes or production workloads who need more capability than they have in-house. Observe and recover is for teams who find out about outages from customers.
| If this describes you | Start with | Then consider |
|---|---|---|
| Infrastructure was created by hand in the console | ClickOps Cloud Setup and Terraform Infrastructure as Code | Landing zone work and Ansible Configuration Management |
| Releases are manual or the pipeline is fragile | CI/CD Pipeline | GitOps with Helm, ArgoCD and Flux |
| Kubernetes is running but nobody trusts it | Kubernetes Consulting or AWS EKS Consulting | Monitoring with Grafana and Prometheus |
| You hear about incidents from customers | Monitoring with Grafana and Prometheus | SRE and Incident Response |
| You have no tested way to recover | Backup and Disaster Recovery | Managed DevOps for ongoing restore testing |
How do the services relate to each other?
The services are layers rather than separate products. Cloud foundations sit at the bottom: accounts, networks, identity and infrastructure defined as code. Delivery sits on top of that, because a pipeline is only as safe as the environments it deploys into. Platform operations and observability sit on top of both, because you cannot run or monitor what has not been built in a repeatable way.
That ordering is why many engagements begin with infrastructure as code or a landing zone even when the visible pain is somewhere else. A Kubernetes cluster created by hand is hard to upgrade, hard to recreate and hard to review. Defining it in Terraform first makes every later change a pull request your team can read.
- Terraform Infrastructure as Code describes what exists. Ansible Configuration Management describes how servers are configured.
- CI/CD Pipeline builds and tests changes. GitOps with Helm, ArgoCD and Flux decides what is running in each cluster.
- Monitoring and Logging tell you something is wrong. SRE and Incident Response decides who acts and how.
- Backup and Disaster Recovery is the safety net under everything else.
What does a typical engagement look like?
Whatever the service, the work follows the same four phases described on the How We Work page: assess, plan, build, operate. We agree a fixed scope in writing, a named senior engineer is responsible for the work, and everything is delivered in your own cloud accounts and repositories, so you keep it whether or not we continue.
For a smaller piece of work, such as a CI/CD Rebuild or a Landing Zone Sprint, the phases are compressed into a time-boxed package with a defined deliverable. For ongoing operations, the Managed DevOps service continues after the build phase under a written agreement.
Should I choose a project or a managed service?
Choose a project when you have a defined outcome and a team that will own the result afterwards, for example migrating pipelines or building a landing zone. Choose Managed DevOps when the work is continuous, such as on-call cover, patching, upgrades and cost reviews, and you would rather not hire the whole function yourself.
The two combine well. A common pattern is to build with a project, hand over runbooks and documentation, then decide separately whether to keep us on for operations. The Engagement Models page explains the options, and the Managed DevOps Plans package describes coverage hours and exit terms.
Which cloud and tooling do these services cover?
The services cover AWS, Azure and Kubernetes. Kubernetes work applies to Amazon EKS, Azure AKS and Google GKE, with dedicated pages for EKS, AKS and GKE consulting. CI/CD work covers GitHub Actions, GitLab CI, Jenkins and Azure Pipelines, and the Azure DevOps Consulting service covers Azure Boards, Repos, Pipelines and Artifacts.
If you are weighing up tools rather than services, the Technologies section explains how we use each one and when we would choose something else, and the Compare section sets common alternatives side by side.
Frequently asked questions
Do I need all of these services?
Do you work inside our accounts and repositories?
Can you take over something another team built?
Is Kubernetes always the right answer?
How do I get a price?
Cloud & DevOps Services
End-to-end engineering across AWS, Azure, and Kubernetes, from your first cloud account to a fully automated, observable production platform.
Cloud foundations
Get onto the cloud and build it properly.
Delivery
Ship changes quickly and safely.
Platform operations
Run Kubernetes and production with confidence.
Observe and recover
See problems early and recover from the worst.
Not sure where to start?
Book a working session. We'll look at your current setup and discuss where to start.