The DevOps Map
DevOps is the work of getting code from a commit to a healthy production service, quickly and repeatably. The tools fall into layers, from Linux and containers up through orchestration, CI/CD, infrastructure as code, observability and deployment strategies, and each layer solves one problem. This page maps the landscape for a Java and Spring engineer who deploys to AWS, compares VMs, containers and serverless, gives a which-tool-for-which-problem guide, introduces the DORA metrics, and lays out the pages that follow.
Build, Ship, Run, Observe
DevOps is the practice of making the path from "code committed" to "code running and healthy in production" short, repeatable and safe, and of making the people who write the code responsible for how it behaves in production. The tools are a consequence of that goal, not the goal itself. Every tool in this section solves one stage of one loop.
| Stage | Question it answers | Typical failure when it is missing |
|---|---|---|
| Build | Can anyone, on any machine, produce the same artifact from this commit, and does it pass the tests? | "Works on my machine"; manual builds; a release nobody can reproduce |
| Ship | How does a tested artifact reach an environment, and who or what approves it? | Copying a jar by hand over SSH; different artifacts in test and prod |
| Run | Where does it execute, how is it restarted, scaled and configured? | A process started in a terminal; one server nobody dares reboot |
| Observe | Is it healthy, and if not, why? | Users report outages before you notice; hours spent guessing |
| Infrastructure | Who created these servers, networks and permissions, and can we recreate them? | Click-built environments that drift apart; no disaster recovery |
A Java/Spring engineer who deploys to AWS already touches every stage: Maven builds a jar, something copies it to ECS, EKS or EC2, an environment variable points it at RDS, and CloudWatch shows its logs. This section makes each stage explicit, with the Linux and container knowledge underneath it.
What Each Layer Solves
The tool names change every few years; the problems do not. Learn the problem each layer solves, and a new tool in that layer is a variation, not a new subject.
| Layer | Problem it solves | Representative tools | Page |
|---|---|---|---|
| Linux and shell | Everything runs as processes on a kernel: you must be able to inspect, limit and debug them | bash, systemd, ss, journalctl, cgroups | 01 |
| Containers | Package the app with its exact dependencies so it runs the same everywhere | Docker, Podman, containerd, OCI images, Amazon ECR | 02 |
| Orchestration | Run many containers across many machines: scheduling, restarts, scaling, service discovery, config | Kubernetes, Amazon ECS, Amazon EKS | 03, 04 |
| CI/CD | Build, test and release automatically on every change | GitHub Actions, GitLab CI, Jenkins, AWS CodePipeline, Argo CD (GitOps) | 05 |
| Infrastructure as code | Create and change cloud resources from reviewed, versioned definitions | Terraform, OpenTofu, AWS CloudFormation, AWS CDK, Pulumi | 06 |
| Observability | Understand a running system from its outputs: metrics, logs, traces, alerts | Prometheus, Grafana, OpenTelemetry, Loki, Jaeger, CloudWatch, X-Ray | 07 |
| Deployment strategies | Change what is running without downtime or with controlled risk | Rolling update, blue-green, canary, feature flags | 08 |
Two ideas connect the layers. Immutability: you never patch a running server; you build a new image and replace the old instance. Declarative state: you describe what you want (three replicas of this image, this load balancer) and a controller (Kubernetes, Terraform apply) makes reality match, instead of scripting the steps.
- A team of five with one service does not need a service mesh, a GitOps controller and a multi-cluster setup. Add a layer when its absence hurts: when manual deploys cause outages, add CI/CD; when environments drift, add infrastructure as code; when you cannot explain an incident, add observability. Operating a tool is a permanent cost.
VM, Container or Serverless
| Virtual machine (EC2) | Container (ECS, EKS, Fargate) | Serverless function (Lambda) | |
|---|---|---|---|
| Unit you deploy | A machine image plus your artifact | A container image | A function package or image |
| Isolation | Strong: own kernel | Process-level: shared kernel (namespaces, cgroups; see page 01) | Provider-managed, strong |
| Start time | Tens of seconds to minutes | Seconds, plus image pull | Fast, but a cold start for a JVM is a real concern |
| Scaling | Auto Scaling groups of whole machines | Add or remove containers; the platform packs them | Per request, automatic, can scale to zero |
| You manage | OS patching, runtime, scaling, config | The image and its manifests; node patching unless Fargate | Code and configuration only |
| Cost shape | Pay for the instance whether busy or idle | Pay for the nodes (or Fargate vCPU and memory), better packing | Pay per invocation and duration; poor fit for steady heavy load |
| Good fit | Legacy apps, special OS needs, stateful systems you own | Most long-running Spring services; many small services; portability | Event handlers, glue code, spiky or rare workloads |
| Watch out for | Snowflake servers, drift, slow rollouts | Operational complexity of Kubernetes; image hygiene | Execution limits, cold starts, vendor lock-in, hard local debugging |
For a Spring Boot service the practical order of preference on AWS is usually: ECS on Fargate when you want containers with the least operations; EKS when you want the Kubernetes ecosystem or portability and have the team to run it; EC2 with systemd (page 01) for simple or legacy deployments; Lambda for event-driven glue rather than a full Spring web application. Check current limits and pricing on the AWS documentation before deciding, as they change.
- A container is a Linux process with a private view of the system. Memory limits, signals, PID 1, file descriptors and DNS all behave exactly as on a plain server, so most container incidents are solved with the tools of page 01.
Which Tool for Which Problem
| Your problem | Reach for | Why | Page |
|---|---|---|---|
| "It works on my machine, fails on the server" | Docker image built in CI | Same image from laptop to production; dependencies travel with it | 02 |
| A service is slow, full or crashing and you are on the box | Linux tools: top, ss, df, journalctl, dmesg | Every incident starts at the OS; the playbooks give the first ten minutes | 01 |
| Run many containers, restart failed ones, scale them | Kubernetes (or ECS) | A control loop that keeps actual state equal to declared state | 03 |
| Pods restart, nodes fill up, resources are mis-sized, upgrades are scary | Kubernetes operations: requests and limits, probes, autoscaling, troubleshooting | Day-2 problems of a cluster | 04 |
| Every release is manual and error-prone | CI/CD pipeline | Automated build, test, scan and deploy on every merge | 05 |
| Environments differ, nobody remembers how the VPC was built | Terraform (or CloudFormation, CDK) | Reviewable, repeatable infrastructure with a plan before every change | 06 |
| "We found out from customers" | Metrics, logs and traces with alerting | You cannot fix what you cannot see; alert on symptoms, investigate with telemetry | 07 |
| Deployments cause downtime or risky big-bang releases | Rolling, blue-green, canary, feature flags | Limit blast radius and make rollback fast | 08 |
| Asynchronous communication between services | Messaging: Kafka, SQS, RabbitMQ | Decouples services; has its own operational concerns | other section |
| Choosing a database or cache | NoSQL and caching or SQL | Data store choice shapes the whole architecture | other section |
- 1. Put everything in Git and build the artifact in CI (page 05).
- 2. Containerise the service (page 02) so build and run environments match.
- 3. Run it on a managed platform (ECS on Fargate, or EKS if you need Kubernetes), not on hand-built servers (pages 03 and 04).
- 4. Define the infrastructure as code (page 06).
- 5. Add dashboards and alerts before the first incident, not after (page 07).
- 6. Adopt rolling then canary releases when the cost of a bad release justifies the effort (page 08).
Pages in This Section
The pages build upward through the layers. Read page 01 and page 02 first: everything else assumes you know what a process and a container are.
- 01 · Linux & Shell Essentials - permissions, processes and signals, load and memory, disks, networking, systemd, text pipelines, shell scripting, cgroups and namespaces, troubleshooting playbooks
- 02 · Docker - images and layers, Dockerfiles for Spring Boot, networking, volumes, Compose, image size and security
- 03 · Kubernetes Core - architecture, pods, deployments, services, config and secrets, ingress, storage
- 04 · Kubernetes Operations - resources, probes, autoscaling, rollouts, troubleshooting, Helm, security basics
- 05 · CI/CD Pipelines - pipeline design, build and test stages, artifacts and registries, GitOps, secrets in pipelines
- 06 · Infrastructure as Code - Terraform state, providers, modules, plan and apply workflow, drift
- 07 · Observability - metrics, logs and traces, Prometheus, OpenTelemetry, alerting, SLOs
- 08 · Deployment Strategies - rolling, blue-green, canary, feature flags, database migrations, rollback
- 09 · Interview Q&A - questions across all of the above
- AWS - the services these tools deploy onto: ECS, EKS, ECR, CloudWatch, IAM, VPC.
- Spring Guide - the applications being built and deployed, including Actuator health and graceful shutdown.
- Performance Engineering - JVM and database tuning that observability data feeds.
- Messaging - the asynchronous side of distributed systems.
DORA Metrics
How do you know whether your delivery process is good? The DORA research programme (DevOps Research and Assessment, now part of Google Cloud) identified a small set of metrics for software delivery performance. The current guide on dora.dev defines five metrics in two groups, checked against that page on 2026-10-31.
| Metric | Group | Definition (as published by DORA) | What it tells you |
|---|---|---|---|
| Change lead time | Throughput | Time for a change to go from committed to version control to deployed in production | How long the pipeline, reviews and approvals take |
| Deployment frequency | Throughput | Number of deployments over a period, or the time between deployments | Batch size: small frequent changes are lower risk |
| Failed deployment recovery time | Throughput | Time to recover from a deployment that fails and requires immediate intervention | How well rollback, alerting and on-call work |
| Change fail rate | Instability | Ratio of deployments that require immediate intervention afterwards, likely a rollback or a hotfix | Quality of tests, review and release strategy |
| Deployment rework rate | Instability | Ratio of deployments that are unplanned but happen as a result of an incident in production | How often incidents force extra, unplanned releases |
Older material (the Accelerate book and early State of DevOps reports) lists four key metrics: lead time for changes, deployment frequency, time to restore service and change failure rate. The current guide renamed the recovery metric (to failed deployment recovery time) and added deployment rework rate as a fifth. If an interview or a document quotes "the four DORA metrics", that is the older formulation; knowing both is the safe answer.
- Measure from data you already have: pipeline timestamps give lead time and frequency; incident tickets and rollbacks give fail rate and recovery time.
- Use them to find bottlenecks, not to rank people. Goodhart's law applies: a team told to maximise deployment frequency will deploy empty changes.
- Each page in this section moves a metric: CI/CD and GitOps shorten lead time; deployment strategies and observability shorten recovery time and cut change fail rate.
- Definitions above are quoted in substance from the DORA guide at
dora.dev/guides/dora-metrics/. DORA also publishes benchmark bands in its annual report; those change from year to year, so this section does not repeat them. Use the current report if you need targets.
Cheat Sheet and Recap
| Question | Answer |
|---|---|
| What is DevOps in one line? | A short, repeatable, safe path from commit to healthy production, owned by the team that writes the code |
| The loop | Build, ship, run, observe, repeat; infrastructure as code underneath |
| VM vs container vs serverless | Own kernel and OS vs shared kernel and an image vs only your function |
| Containers are... | Linux processes with namespaces (what they see) and cgroups (what they use) |
| Kubernetes is... | A declarative control loop that keeps actual state equal to desired state |
| Terraform is... | Declarative infrastructure as code with a plan step and a state file |
| Three telemetry signals | Metrics, logs, traces |
| DORA metrics (current guide) | Change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate |
| Adopt in this order | CI, containers, managed runtime, IaC, observability, safer release strategies |
- DevOps is a loop, not a toolbox: build, ship, run, observe, and feed what you learn back into the next build.
- Learn the problem each layer solves; tools are interchangeable within a layer.
- Immutable artifacts and declarative state are the two ideas behind nearly every tool here.
- Linux knowledge never goes away: containers and pods are still processes on a kernel.
- Add a layer when its absence hurts, not before; every tool has an operating cost.
- Measure with DORA: five metrics in two groups, throughput and instability, used to find bottlenecks and not to rank people.
DORA metric names and definitions were checked against dora.dev/guides/dora-metrics/ on 2026-10-31 (five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate). Tool names are representative examples, not an endorsement list. AWS service limits and prices are deliberately not quoted here; see the AWS documentation. The detailed pages in this section verify their own version-specific facts.
- Start with 01 · Linux & Shell Essentials, then 02 · Docker.