The DevOps toolchain
Every lesson in this course has pointed at specific tools in passing — Terraform, Kubernetes, Prometheus, PagerDuty. This page collects them into one reference, organized by the job each category does rather than by vendor, so you can look up "what handles this stage" instead of relearning a product catalog. By the end you'll be able to name the category behind any DevOps tool you encounter and reason about whether your own stack has a gap or a redundancy.
Think of a kitchen. You don't buy "a kitchen tool" — you buy a knife for cutting, a pan for heating, a fridge for storing. Different brands make each one, and a good cook doesn't argue about knife brands before deciding they even need a knife. The DevOps toolchain works the same way: first figure out which job needs doing — cutting, heating, storing, in DevOps terms provisioning, building, or watching — then pick a brand that fits your kitchen's size. A four-person food truck and a hundred-seat restaurant both need a knife and a pan, but buying the restaurant's six-burner range for the food truck just clutters a space that has nowhere to put it.
Why organize by lifecycle stage, not by vendor
Toolchain conversations tend to collapse into vendor debates — Jenkins versus GitHub Actions, Datadog versus Prometheus — before anyone has agreed on what job is actually being filled. That's backwards. The more useful question is always two questions in sequence: which stage of the DevOps lifecycle needs support, and only then, which product in that category fits your team's constraints (budget, hosting model, existing vendor relationships, in-house expertise).
A tool's category tells you what problem class it solves regardless of brand: a CI/CD orchestrator runs a pipeline defined in code on every push; a configuration management tool enforces a desired state on machines that already exist; an artifact registry stores and versions what a build produced. Multiple vendors compete inside each category, often with real feature differences, but confusing a category decision with a vendor decision is how teams end up either missing a stage entirely or running three tools that all do the same job slightly differently.
How the stages connect
The eight categories below aren't independent — they form a chain, and the chain is the same lifecycle this course has walked stage by stage. Source control holds the change; a CI/CD orchestrator picks it up and drives the pipeline described in CI/CD pipelines; infrastructure-as-code and configuration-management tools make sure the target environment exists and is configured correctly before anything lands on it; the build step packages the result into a container image and pushes it to a registry; containers and orchestration tools schedule that image onto running infrastructure; monitoring and observability tools watch what happens once it's live; and when something breaks, incident and on-call tooling routes the alert to a human and coordinates the fix. The diagram below traces that path.
The tool landscape, category by category
The table below names two to four representative, currently-used tools per category — chosen because they're widely deployed and commonly referenced in job postings and postmortems, not as an endorsement of one over another. Most categories have real competitors not listed here; treat this as a starting map, not an exhaustive catalog.
| Category | Representative tools | What it's for |
|---|---|---|
| Source control | GitHub, GitLab, Bitbucket | Hosts the git history, code review, and branch protection that every later stage builds on. |
| CI/CD orchestration | GitHub Actions, GitLab CI/CD, Jenkins, CircleCI | Runs the pipeline defined in code on every push — lint, test, build, and deploy gates, as covered in CI/CD pipelines. |
| Infrastructure as code | Terraform, OpenTofu, Pulumi, AWS CloudFormation | Declares and provisions cloud resources — networks, compute, databases — from versioned configuration files. |
| Configuration management | Ansible, Chef, Puppet, SaltStack | Enforces a desired software and configuration state on machines that already exist, correcting drift over time. |
| Containers & orchestration | Docker, containerd, Kubernetes, Helm | Packages an application into a portable image and schedules and runs it across a fleet of machines. |
| Artifact / package registries | JFrog Artifactory, Docker Hub, GitHub Container Registry, Sonatype Nexus | Stores and versions the built, scanned artifacts a pipeline produces and a deployment later pulls from. |
| Monitoring & observability | Prometheus, Grafana, Datadog, OpenTelemetry | Collects metrics, logs, and traces so you can tell what a running system is actually doing. |
| Incident / on-call / ChatOps | PagerDuty, Opsgenie, Slack, incident.io | Routes an alert to the right human, tracks the response, and coordinates the fix in real time. |
Read as a sequence, this is the same path traced in the diagram above: a change enters through source control, a CI/CD orchestrator drives it through build and test, IaC and configuration management make sure the target environment is ready, containers and orchestration run the result, a registry holds the versioned artifact throughout, and monitoring plus incident tooling close the loop once the change is live.
Where the categories overlap
Few real stacks map cleanly onto eight separate products, because several tools deliberately span categories. GitLab and, increasingly, GitHub bundle source control, CI/CD orchestration, and a container registry into one product — you can run an entire pipeline without a single third-party integration. GitOps controllers such as Argo CD or Flux blur CI/CD orchestration and deployment: the pipeline builds and pushes an artifact, but the controller itself continuously reconciles the cluster's live state against a git repository, which is really a deployment strategy decision wearing a CI/CD-shaped hat. Kubernetes operators blur containers/orchestration and configuration management, since an operator encodes the same "enforce desired state" logic Ansible or Puppet apply to virtual machines, just aimed at cluster resources instead — see containers & orchestration for where that boundary sits in practice.
The IaC/configuration-management boundary itself trips up a lot of teams: infrastructure as code provisions resources that don't yet exist, while configuration management configures resources that already do. Terraform can install a virtual machine; it's a poor fit for continuously making sure that machine's packages stay patched. Knowing which side of that line a task falls on is more useful than memorizing a vendor list.
Choosing tools: fit, sprawl, and boring technology
Three practical rules cut through most toolchain decisions better than a feature comparison spreadsheet:
- Match tooling to team size and maturity. A five-person startup running a self-hosted Jenkins cluster with custom plugins is almost always over-tooled — a managed CI product with a free tier solves the same problem with none of the operational burden. A two-hundred-engineer organization still filing infrastructure change tickets by hand is under-tooled in the other direction. The right toolchain scales with headcount and system complexity, not with what a conference talk recommended.
- Avoid tool sprawl. Two IaC tools provisioning overlapping resources, three alerting channels nobody has fully turned off, a metrics stack and a logging stack that don't share a data model — each redundant system is another thing to patch, another vendor contract, and another surface where on-call engineers have to remember which tool has the answer tonight. Consolidating to one tool per category, even a mediocre one everyone already knows, usually beats running the "best" tool in each category if it means five different login screens during an incident.
- Prefer boring, proven tools on the critical path. Engineer Dan McKinley's essay "Choose Boring Technology" frames this as a budget of innovation tokens: a team has only so much capacity to absorb the operational surprises of an unfamiliar system, so spend that budget on what differentiates the product, not on infrastructure tooling. Terraform, Jenkins, and Prometheus are boring in the best sense — well-documented, widely staffed, predictable in failure modes — which is exactly what you want provisioning production and watching it break.
A toolchain gap and a toolchain redundancy cost you in opposite ways but are equally worth auditing for: a missing category (no configuration management, so servers drift silently) shows up as an incident; a duplicated category (two competing artifact registries) shows up as a slow leak of maintenance time and confused on-call runbooks. Both are found the same way — walk the eight categories above against your actual stack and mark what's missing or doubled up.
1. Name one representative tool from the CI/CD orchestration category and one from configuration management, and state in one sentence what distinguishes the two categories' jobs. 2. Why does a GitOps controller like Argo CD blur the line between "CI/CD orchestration" and "deployment strategy"? 3. What's the practical difference between infrastructure as code and configuration management, using Terraform and Ansible as the example? 4. According to the "boring technology" guidance on this page, why would a team deliberately choose an older, less exciting tool for its critical path?
Check your answers
- CI/CD orchestration example: GitHub Actions, GitLab CI/CD, Jenkins, or CircleCI. Configuration management example: Ansible, Chef, Puppet, or SaltStack. The distinction: CI/CD orchestration runs a pipeline of build/test/deploy steps triggered by a code change, while configuration management enforces a desired state on machines that already exist.
- Because the controller continuously reconciles a cluster's live state against a git repository rather than running as a discrete pipeline stage, which makes it function as both the mechanism that ships a change (CI/CD-adjacent) and the mechanism that decides how that change rolls out (a deployment strategy).
- Infrastructure as code provisions resources that don't yet exist — Terraform can create a virtual machine. Configuration management configures resources that already exist and keeps them from drifting — Ansible would install and maintain packages on that already-provisioned machine.
- Because a team has limited capacity to absorb the operational surprises of unfamiliar systems (the "innovation token" budget from Dan McKinley's essay), and a well-documented, widely-staffed, predictable-failure-mode tool is a safer place to spend that limited budget than on infrastructure the product's differentiation doesn't depend on.