Technologies we work with
A practical guide to the cloud platforms, Kubernetes tooling, infrastructure as code, pipelines, observability and security tools we run for clients: how we use each, when we would choose something else, and what to watch for.
Cloud platforms
AWS, Azure and Google Cloud, designed, secured and cost-controlled.
Containers and Kubernetes
Docker, Kubernetes, managed clusters on EKS, AKS and GKE, Helm and autoscaling.
Infrastructure as code
Terraform, Ansible, CloudFormation, Pulumi and Terragrunt for reproducible infrastructure.
CI/CD and GitOps
GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, ArgoCD and Flux.
Observability and monitoring
Prometheus, Grafana, ELK, Loki, OpenTelemetry and Datadog.
DevSecOps and secrets
Vault, Trivy, SonarQube, Falco and Checkov built into your pipelines.
How do we choose between technologies?
We choose the tool your team can run and understand after we leave, not the one that is newest. The deciding factors are usually where your code and cloud already live, how large the team is, what skills it already has, and what compliance or data location rules apply.
That is why each technology page says when we would pick something else. Terraform is a common default for infrastructure as code, but AWS CloudFormation can be the better fit for a team that is entirely on AWS and wants no extra state to manage. The right answer depends on your situation, and we state the trade-offs rather than defend a favourite.
Which tools fit together as a stack?
The six categories on this page are layers of one platform. A cloud platform hosts the workloads, containers and Kubernetes run them, infrastructure as code defines them, pipelines and GitOps deliver changes, observability shows how they behave, and DevSecOps tools check them for risk.
A typical combination looks like this, though none of it is mandatory:
| Layer | Common choices on this site | Question it answers |
|---|---|---|
| Cloud | AWS, Microsoft Azure, Google Cloud | Where does it run? |
| Containers | Docker, Kubernetes, EKS, AKS, GKE, Helm | How is it packaged and scheduled? |
| Infrastructure as code | Terraform, Ansible, CloudFormation, Pulumi, Terragrunt | How is it created repeatably? |
| Delivery | GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, ArgoCD, Flux | How do changes reach production? |
| Observability | Prometheus, Grafana, Loki, ELK, OpenTelemetry, Datadog | How do we know it is healthy? |
| DevSecOps | HashiCorp Vault, Trivy, SonarQube, Falco, Checkov | How do we catch risk early? |
Where do I start if I am comparing similar tools?
Start with the Compare section for the decisions teams ask about most: ArgoCD versus Flux, EKS versus AKS versus GKE, Terraform versus CloudFormation, Prometheus versus Datadog, and GitHub Actions versus GitLab CI versus Jenkins. Each comparison is written around the choice rather than the products.
Then read the individual technology pages for the two or three contenders. They describe how we run the tool in production, what usually goes wrong, and which service pages cover the related work.
- Already on GitHub and want simple pipelines: GitHub Actions is usually the shortest path.
- Heavily invested in Azure Boards and Repos: Azure Pipelines keeps work tracking and delivery together.
- Large Jenkins estate: migrate in stages rather than all at once.
How do open source and managed tools differ?
Open source tools such as Prometheus, Grafana, Loki and ArgoCD have no licence fee, but your team carries the operating cost: upgrades, storage, scaling and on-call. Managed or commercial products such as Datadog move much of that work to the vendor in exchange for a recurring charge that grows with usage.
Neither is automatically cheaper. A small team with little time may spend less overall on a managed product, while a team with existing platform skills and high data volumes may prefer to run its own. We compare the realistic operating effort as well as the price.
What if my tool is not listed?
The roster is the set of tools we have written about in depth, not a limit on what we can work with. If your stack includes something else, raise it when you book a consultation and we will say honestly whether we have the experience to help or whether another specialist would serve you better.
Where a tool has a service page rather than a technology page, such as Docker containerisation or logging with ELK, Loki and OpenTelemetry, the Services section covers the implementation work in more detail.