What the DevOps arc builds, one concept at a time.
Where each of these appears is read directly from the journey data, so this
page and the journey cannot disagree about it.
A container packages an application with the filesystem and libraries it needs to run, so the same image behaves identically on a laptop, a CI runner and a server.
what it solves
The "works on my machine" gap, and slow environments. Building an image once and shipping that artefact means provisioning a host stops being a prerequisite for deploying.
On this site: From stage 5 onward the arc stops using Docker to deploy. It becomes the cluster driver, and the Dockerfiles move to a sibling application repository.
in the journey · 6 of 7 stages
new marks where the journey
first puts the concept to work.
Kubernetes & Orchestration
A control plane that holds a declared description of your workloads and continuously works to make reality match it — rescheduling failed pods, replacing drifted ones, scaling replicas.
what it solves
Managing a fleet by hand. You stop asking "is the server up?" and start declaring "there should be three of these", which is a question the control plane answers continuously.
On this site: First appears at stage 5. Stage 7 designs an EKS/AKS platform for it, in documentation only — there are no cluster manifests in that repository.
in the journey · 2 of 7 stages
new marks where the journey
first puts the concept to work.
A naming layer that maps a stable logical name to whatever addresses currently back it, so callers never hold an IP address that can change.
what it solves
Hardcoded addresses and the ordering problem they create. In Kubernetes a Service plus cluster DNS gives a name that survives pod replacement, restarts and scaling.
On this site: Introduced only by Kubernetes, at stage 5. The four VM stages before it discover nothing — every address in a Vagrantfile is fixed at provision time.
in the journey · 2 of 7 stages
new marks where the journey
first puts the concept to work.
Distributing incoming requests across several interchangeable backends, so no single server is a bottleneck and any one of them can disappear without taking the service down.
what it solves
A single point of failure and a single scaling ceiling. It also decouples the address clients know from the set of servers actually running.
On this site: Present in all seven stages, but never the same twice: a hand-written nginx upstream, then an inventory-templated one, then metric-driven weights, then kube-proxy, then an Ingress class.
in the journey · 6 of 7 stages
new marks where the journey
first puts the concept to work.
An active or passive signal about whether a dependency is actually usable — HTTP probes, cluster health endpoints, TCP checks — that other systems act on.
what it solves
Routing traffic to something that cannot serve it. Without a health signal, a load balancer keeps sending requests to a process that is alive but broken, which is worse than being down because it looks fine.
On this site: The arc shipped no automated health check for its first three stages. Stage 4 is the first real one, and even at stage 5 only the backend has probes — the frontend has none.
in the journey · 4 of 7 stages
new marks where the journey
first puts the concept to work.
Collecting metrics, logs and traces from running systems so their internal state can be inferred from their output — the four golden signals being latency, traffic, errors and saturation.
what it solves
Debugging production by SSHing into it. It converts "the site feels slow" into a query you can run, and it is what makes the load-balancer stage and the capacity planning stage possible at all.
On this site: Stage 3 consumes Prometheus rather than deploying it, and stage 7 ships a monitoring stack with no Alertmanager — the other two monitoring stages both have one.
in the journey · 7 of 7 stages
new marks where the journey
first puts the concept to work.
An automated, repeatable path from a commit to a running deployment, where each stage — build, test, scan, publish, deploy — can fail the run before it reaches the last one.
what it solves
Hand-deployed releases and "it worked when I ran it". Scanners sitting in the pipeline also make security a build gate rather than a periodic audit.
On this site: Stage 7 designs a GitLab and ArgoCD pipeline with zero implementation: no .gitlab-ci.yml and no Jenkinsfile exist in that repository.
in the journey · 4 of 7 stages
new marks where the journey
first puts the concept to work.
Describing servers, networks and configuration in version-controlled files that a tool applies, rather than as a sequence of commands someone ran.
what it solves
Undocumented drift and the "works on this box" server. It makes infrastructure reviewable and diffable, and it makes rebuilding a whole environment a single command.
On this site: Stage 7 has no Terraform, CloudFormation or Ansible at all. The word appears only as a ManagedBy: Terraform tagging convention in a design document.
in the journey · 5 of 7 stages
new marks where the journey
first puts the concept to work.
Keeping credentials out of source code and out of the process environment, in a store that can issue, rotate and audit them — typically one secret per environment rather than one per person.
what it solves
Credentials committed to git, where they persist in history even after a later commit deletes them, and are shared freely because rotating them is painful.
On this site: Stage 5 uses Kubernetes Secrets, which are base64-encoded rather than encrypted at rest — acknowledged in that project's own notes, and the specific gap stage 6 closes.
in the journey · 4 of 7 stages
new marks where the journey
first puts the concept to work.
Having a rehearsed way to restore service after losing a machine, a disk or a region, with the acceptable downtime and data loss agreed in advance as RTO and RPO.
what it solves
Discovering during an incident that there was no backup, or that the backup had never been restored. Recovery is a capability you test, not a file you have.
On this site: Stage 1 provisions a backup server and never uses it. Stage 6's recovery is control-plane only — a deleted ArgoCD Application is recreated — with no data backup anywhere in the arc.
in the journey · 2 of 7 stages
new marks where the journey
first puts the concept to work.