# DevOps as an Operating Model, Not a Job Title

## You've already been doing this — just not naming it yet

Every course before this one taught you a Kubernetes skill: declaring desired state, hardening
a Pod, diagnosing a failure with a repeatable framework, running an incident with real
discipline. This module doesn't teach a new hands-on skill — it names the OPERATING MODEL those
skills are all part of, so you can recognize it and apply it beyond Kubernetes specifically.

## DevOps: a set of practices, not a team you join

"DevOps" is often misused as a job title ("I'm a DevOps engineer") or a team name ("throw it
over to DevOps"). Properly understood, DevOps is a set of PRACTICES for how development and
operations work together: shorter feedback loops, automation over manual process, and shared
ownership of what happens after code ships — not a separate team that operations gets outsourced
to.

Concretely, you already practiced core DevOps ideas without the label:

- **Declarative thinking** (ROOT 05) — describing desired state and letting a system enforce it,
  instead of manually executing steps, is the same principle behind Infrastructure as Code.
- **Fast, safe rollback** (ROOT 06) — treating recovery as a rehearsed, ordinary action rather
  than a crisis is a direct DevOps practice (fast feedback, low-drama recovery).
- **A repeatable troubleshooting framework** (ROOT 10) and **structured incident response**
  (ROOT 12) — both are operational discipline, the "Ops" half of DevOps, practiced for real.

## Platform Engineering: what DevOps looks like at scale

**Platform engineering** is the next layer: instead of every application team reinventing how
to deploy safely, monitor, and secure their own workloads, a platform team builds SELF-SERVICE
tooling and golden paths that let other engineers move fast without needing deep infrastructure
expertise themselves. The Kubernetes cluster, the CI/CD pipeline, the observability stack — all
of it becomes a PRODUCT a platform team builds for INTERNAL customers (other engineers), not
just infrastructure that happens to exist.

A useful lens: platform engineering exists to **reduce cognitive load**. A developer who can
deploy a well-configured, secure, observable service through a simple, guided path doesn't need
to personally understand every Kubernetes concept from ROOT 05-10 to ship safely — the platform
encodes that expertise once, for everyone.

## Where Kubernetes fits in the larger picture

Kubernetes is INFRASTRUCTURE, not the whole platform. A real platform engineering practice
typically layers several things around it:

- **Declarative delivery** — describing what should be deployed and letting automation apply it
  (the GitOps model — future ROOT 11 content, requires a Git+deployment-automation environment
  this course doesn't yet provide).
- **Continuous integration/delivery** — automatically testing and shipping code changes (CI/CD —
  future content, requires a CI runner environment).
- **Infrastructure as Code** — declaring cloud/infrastructure resources the same way you declare
  Kubernetes objects (future content, requires a provisioning environment like Terraform).
- **Observability** — knowing what's actually happening in production beyond "is the Pod
  Running" (future content, requires a metrics/logging/tracing stack).

None of these require abandoning what you learned in ROOT 05-10 — they build directly on the
same mental models (desired vs. actual state, evidence-based diagnosis, least privilege) applied
to a wider set of systems.

## Instructor Notes

**Lesson goal:** Give students a name and a framework for practices they've already exercised,
and an honest map of what ROOT 11 will eventually cover once appropriate lab environments exist —
without pretending those labs exist today.

**Approximate timing:** 20 minutes read; 15 minutes live with discussion.

**Preparation:** None beyond having read `docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md` to speak
accurately about what's planned versus what exists.

**Likely misconceptions to watch for:**
- "DevOps" as a job title/team is a very common prior belief — correct this directly and early,
  it's the central point of the lesson.
- Platform engineering is sometimes conflated with "just Kubernetes." Emphasize the self-service/
  golden-path angle — the PRODUCT framing, not just the technology.

**Questions to ask students:** "Which ROOT_ course so far most directly practiced a DevOps
principle, even though it was never labeled that way?" (Most will cite ROOT 06's rollback
discipline or ROOT 12's incident framework — both are legitimate, good answers.)

**When to let a student struggle vs. provide a hint:** Not applicable — this is an orientation
lesson with no hands-on task.

**Optional extension:** ask students to name one manual process at a company they've worked for
(or heard about) that platform engineering-style self-service tooling could have eliminated.

**Expected takeaway:** DevOps and platform engineering are the organizing ideas behind almost
everything ROOT_ has already taught — not a new, separate subject to learn from scratch.