What is DevOps?
Tear down the wall between building software and running it: the culture, the CALMS model, the Three Ways and value streams.
- Explain the problem DevOps solves - the wall between development and operations
- Describe DevOps with the CALMS model and the Three Ways
- Map a value stream and find where work waits
Welcome to Byte Bakery: warm croissants and sourdough delivered by drone, ordered from a slick web app. The pastries are perfect. The software delivery is... not.
Once a month the whole company holds Release Night. Developers hand a zip file and a 40-step Word document to the operations team, who have never seen the code. Pizza is ordered. Something breaks at 2 a.m. Developers say “it worked on my machine”; operations says “your code broke the servers”. Everyone is tired, nobody trusts anybody, and new features take two months to reach customers. Last time, the drones delivered every order to the same rooftop for six hours.
Over this track you’ll help Byte Bakery go from Release Night to deploying on demand, many times a day, calmly. That journey is DevOps.
The wall of confusion
Traditionally, developers are rewarded for change (ship features!) and operations for stability (don’t break anything!). Those goals collide at a “wall of confusion” where work is thrown over, and each side optimizes for itself.
DevOps is a set of cultural values and engineering practices that join the two: the people who build a service share responsibility for running it, and they automate the path from a commit to production so that change becomes small, frequent, safe and boring. It isn’t a job title, a tool or a team you can buy - although you’ll meet plenty of all three.
CALMS
A handy model of what DevOps involves is CALMS:
| Letter | Stands for | At Byte Bakery, it looks like |
|---|---|---|
| C | Culture | shared ownership, blameless postmortems, “you build it, you run it” |
| A | Automation | every commit is built, tested and deployable without a Word document |
| L | Lean | small batches, limiting work in progress, removing waiting and waste |
| M | Measurement | measuring delivery speed and stability, not guessing |
| S | Sharing | shared dashboards, runbooks, tools and lessons across teams |
The Three Ways
The DevOps Handbook describes three principles:
- Flow - make work move quickly from idea to customer: small batches, automation, no waiting in queues.
- Feedback - see problems quickly and fix them where they start: automated tests, monitoring, alerts that reach the people who made the change.
- Continual learning and experimentation - treat failures as chances to improve, run experiments, and set aside time to improve the daily work itself.
Mapping the value stream
A value stream is every step from an idea to running software in customers’ hands. Mapping it - with how long each step takes to do and how long work waits before it - usually shocks people. Here is a croissant-tracking feature at Byte Bakery:
1steps = [ # (step, hours of work, hours waiting before it)
2 ("write code", 6, 0),
3 ("code review", 1, 20),
4 ("manual QA", 8, 50),
5 ("deploy on Release Night", 3, 230),
6]
7work = sum(hours for _, hours, _ in steps)
8waiting = sum(wait for _, _, wait in steps)
9print(f"lead time {work + waiting} h, of which work {work} h")
10print(f"flow efficiency {work / (work + waiting):.0%}")lead time 318 h, of which work 18 h flow efficiency 6%
Only 6% of the lead time is anyone actually working on the feature. The fix is rarely “type faster” - it’s removing the queues: smaller changes, quicker reviews, automated testing, and deploying whenever something is ready instead of once a month.
Try it
Sort the practices into CALMS
Which part of CALMS does each Byte Bakery change mostly belong to?
“Developers join the on-call rotation for the services they build”
“After an outage, the review asks “how did our system allow this?” rather than “who did it?””
“Every commit runs the tests and builds a deployable package”
“Big features are split into changes that ship within a day or two”
“The team tracks how often it deploys and how often deploys cause failures”
“The payments team publishes its deploy pipeline as a template other teams reuse”
Key takeaways
DevOps joins building and running software, so change becomes small, frequent and safe.
CALMS: culture, automation, lean, measurement, sharing.
The Three Ways: flow, feedback, continual learning.
Value stream maps show where work waits - usually far longer than it’s worked on.
Lesson quiz
7 questions · pass with 5 correct · up to 50 XP
Passing this quiz completes the lesson and keeps your streak going. Questions you miss come back in review sessions later.
Practice: automate DevOps chores in Python
Write the small Python tools DevOps teams really build - pipeline runners, plan checkers, metric calculators, scanners - and run them against sample inputs. They run locally in your browser; no servers or cloud accounts needed.
Map the value stream
Each input line is a step: name work_hours wait_hours, where the wait is how long work sat waiting before that step (step names use dashes instead of spaces). Print each step as code-review: 1h work, 20h wait, then lead time: 318h, process time: 18h, flow efficiency: 5.7% (one decimal) and biggest wait: before deploy (230h).
- Croissant tracking
- After automation
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Is it worth automating?
Each input line is a manual chore: task minutes_per_run runs_per_week hours_to_automate. Work out the hours saved per week and how many weeks until automating it pays back (hours_to_automate / hours_saved_per_week).
Print the chores from fastest to slowest payback as restart-oven-api: saves 2.5 h/week, pays back in 1.6 weeks -> automate now, with one decimal. The verdict is automate now for up to 13 weeks, automate this year for up to 52, otherwise not worth it yet.
- Byte Bakery chores
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Questions about this lesson
Stuck? Ask. Figured something out? Share it. Explaining is one of the best ways to learn.
Loading posts…