DevOps

Modern infrastructure didn’t appear overnight. Each layer of today’s DevOps stack was a response to a specific pain point in the layer before it. Knowing the order helps you reason about why a tool exists, not just what it does.

A Compressed Timeline

Era	Movement
1990s	Manual sysadmins, snowflake servers, ticket-based ops.
~2005	Config management (CFEngine, Puppet, Chef, Ansible).
~2006	Cloud IaaS; AWS EC2 launches, “cattle, not pets”.
~2009	“DevOps” as a movement, shared dev/ops responsibility.
~2013	Containers; Docker, immutable images.
~2014	Kubernetes; declarative orchestration.
~2014	Infrastructure as Code; Terraform, HashiCorp tools mature.
~2015	Cloud Native / CNCF; microservices.
~2016	Site Reliability Engineering goes mainstream (Google book).
~2017	Service mesh (Istio, Linkerd); CI/CD-as-code matures.
~2017	GitOps coined; Argo CD / Flux.
~2018	Serverless and edge mature.
~2020	Platform Engineering as a named discipline.
~2022	FinOps and AIOps grow alongside platform teams.
~2024+	AI in the loop, code review, ops, runbooks.

The dates are approximate; movements take years to spread, and many shops are still on earlier rungs of the ladder. That’s fine; the later layers depend on the earlier ones.

The Driving Forces

The three pressures that drove every major change. Automation replaced manual ops with code; immutability replaced hand-fixed pets with replaceable cattle; self-service replaced ops gatekeeping with platform building. Each new layer is one of these pressures finding fresh expression.

Three trends do most of the work:

• Automation, replace manual operations with code. Started with shell scripts, ended with declarative reconciliation.

• Immutability, replace pets with cattle. Stop fixing servers in place; replace them when something is wrong.

• Self-service, developers should not need a ticket to do their job. Move from “ops as gatekeeper” to “ops as platform builder”.

Pets vs. Cattle

The metaphor that defined the DevOps cultural shift. Pets are named, hand-tuned, and irreplaceable; cattle are numbered, identical, and disposable. The progression from manual pets to managed cattle to ephemeral functions captures most of the last fifteen years of infrastructure.

A defining DevOps metaphor (Bill Baker, Microsoft, c.2012):

• Pets, named servers, hand-tuned, irreplaceable. When sick, you nurse them back to health.

• Cattle, numbered, identical, disposable. When sick, you cull.

The progression:

1. Pets only, manual ops.

2. Pets at scale, config management trying to keep many pets healthy.

3. Cattle in the cloud, new VMs are cheaper than fixing old ones.

4. Cattle in containers, pods are cheaper than VMs.

5. No long-lived hosts, serverless / function-on-demand.

Modern systems still have a few pets (databases, stateful services), but the application layer is increasingly cattle.

Mutable vs. Immutable

• Mutable, the running server is the source of truth; you patch it in place. Drift is inevitable; “snowflake servers” emerge.

• Immutable, the deployed artifact is fixed; you replace, not patch. New version → new image → new instance. Drift is impossible by construction.

Containers and managed cloud services pushed everything toward immutable.

Imperative vs. Declarative

• Imperative, “run these steps” (Bash, Ansible playbooks). The result depends on starting state.

• Declarative, “the system should look like this”. A reconciliation loop makes it so. Idempotent by construction.

Kubernetes, Terraform, GitOps, Crossplane, Pulumi-with-state all sit on the declarative side. Most modern infrastructure does.

The Stages

The remaining pages walk the stages of evolution the field has been through, grouped into six buckets that match how engineers talk about infrastructure today. Each bucket is a layer built on top of the ones before it, and the order is the order in which the pressures of automation, immutability, and self-service produced them. Most shops live across several buckets at once; the value of the map is knowing which rung you are on and which one comes next.

Runtimes are the substrate the application actually executes on, from bare metal up through VMs, containers, orchestrators, and serverless. Each layer trades a little control for a lot more density, immutability, or scale-to-zero.

1. Traditional Ops, bare metal, snowflake servers.

2. Virtualization, VMs and hypervisors.

3. Runtimes, OCI runtimes, microVMs, Wasm, language runtimes.

4. Containers, Docker / OCI; immutable artifacts.

5. Orchestration, Kubernetes scheduling.

6. Service Mesh, per-service traffic / mTLS.

7. Serverless, managed compute, scale-to-zero.

Pipelines carry code from a commit to a running production artifact. CI/CD automates the build and test path; GitOps makes the repository the source of truth for what is deployed and where.

8. CI / CD, build, test, ship.

9. GitOps, Git as operational source of truth.

Clouds are the rented primitives every other layer sits on, the compute, network, and storage exposed as APIs by hyperscalers and their software-defined cousins. The shift here was from physical inventory to on-demand allocation paid by the second.

10. Cloud, AWS / GCP / Azure primitives.

11. Software-Defined Infrastructure, SDN / SDS / SDDC.

IaC is how the cloud and the runtime are declared, versioned, and reconciled. Config management codified the inside of a server; Terraform and its peers codified the cloud account around it, turning infrastructure into reviewable, diffable artifacts.

12. Configuration Management, Puppet / Chef / Ansible.

13. Infrastructure as Code, Terraform / OpenTofu / Pulumi / CloudFormation.

Components are the cross-cutting building blocks every system draws from, compute, networking, storage, security, and observability. They are not a stage so much as the parts list each later stage rewires into a new shape.

14. Compute, VMs / containers / serverless options.

15. Networking, load balancers, proxies, DNS, CDN.

16. Storage, object / block / file / databases / queues.

17. Security, identity, secrets, network policy.

18. Observability, metrics, logs, traces, alerts.

Practices are the operating disciplines that wrap the technical stack, the way humans run the system rather than the system itself. Platform Engineering productises infrastructure for developers; SRE applies engineering to reliability, on call, and toil; DevSecOps folds security into the same loop instead of bolting it on at the end.

19. Platform Engineering, Internal Developer Platforms.

20. SRE, SLOs, error budgets, toil reduction.

21. DevSecOps, shift left, supply chain, policy as code, runtime detection.

Where Most Teams Are

A 2026 mid-sized engineering org typically lands around stages 5-9: some Terraform, containerized services, Kubernetes (or managed equivalent), CI/CD-as-code, Prometheus/Grafana, structured logs.

• Stages 10-14 are increasingly common but not universal.

• Stages 1-4 are still real; legacy environments don’t go away because fashion did.

You’ll meet teams at every stage. The evolution narrative is most useful as a map, not a checklist.