About this article
Thank you for visiting the site. This article is part 6, the last of the “IT Fundamentals” primers in the Architecture Crash Course for the Generative-AI Era series, and it covers the path from development to operations.
The primers so far have covered the building, the fittings and the security of the shop that is a web service. This last one is about time: “building the place, opening it, and trading every day thereafter”. Development, testing, release, operations, monitoring, incident response — what each of those words, scattered throughout the main series, actually involves.
The point of this article
- Development is "creating a new dish", testing is "tasting it", release is "putting it on the menu"
- A service is not finished when it ships; the trading (operations) lasts far longer
- Monitoring is the shop's health check, and incidents are prepared for, not wished away
It does not end when you ship
The premise first. A web service is not finished when you build it and publish it.
The restaurant makes this obvious. Opening day is not the finish line, it is the start: from there, every day of trading begins. Buying ingredients, servicing equipment, adding dishes, handling complaints. Most of the work of a restaurant is after opening.
A web service is identical. New features, bug fixes, looking after the servers — it goes on indefinitely. In fact, across the life of a service, the trading period is far longer than the building period. That is why the main series treats operations as something weighty.
Development and testing: creating a dish, and tasting it
Development is writing the program and building the features. In shop terms, devising and trialling a new dish.
Its inseparable companion is testing — checking that what you built “works properly and does not misbehave”. In shop terms, tasting.
Do not underestimate tasting; it is a deep discipline. Tasting the new dish alone is not enough, because you also have to check “whether adding it broke the preparation of the existing dishes”. Change the flow of the kitchen and a dish that was always fine starts arriving late — that sort of thing happens constantly in software. Which is why the main series keeps returning to automated testing: doing that checking with a program rather than by hand.
Release: putting the dish in front of customers
If testing finds nothing, you start serving it. That is a release (also called a deploy). The moment the new dish officially joins the menu.
There is one interesting difference from a physical restaurant here. A web shop refits without closing. It trades around the clock, so “closed today while we prepare the new menu” is barely available. You are expected to swap out the kitchen, unnoticed, while customers are eating in front of you. Which sounds exhausting when you put it like that.
CI/CD, which appears in the main series, is “the machinery that automates everything from tasting to updating the menu”. Doing it by hand invites procedural mistakes, so you build a production line where passing the tests carries the change automatically through to release.
Operations and monitoring: trading, and health checks
Once released, you are in operations. Daily trading.
The part of operations that matters most is monitoring. Monitoring means continuously checking that the shop is trading in good health. How many seconds from order to serving, whether the kitchen is overloaded, whether there is room left in the store. You measure numbers like these constantly on instruments, and arrange for a human to be told the moment they start going wrong.
Why does this matter so much? Because trouble in a web service is “hard to see from the outside”. In a physical shop the queue and the panicking staff are visible; in a web shop nothing is. Without instruments, you get the most embarrassing situation of all: “we found out about the outage from a customer complaint”.
Incident response: not “if” but “when”
Which brings us to incident response. An incident is any trouble that stops the service working properly.
One piece of mindset for reading the main series: in the profession, incidents are not something you try hard to prevent, but something you assume will happen and prepare for. No restaurant, however good, gets power cuts and equipment failures down to zero. So you settle “the plan for afterwards” in advance: how you keep trading when the gas goes off, how many minutes recovery should take.
Redundancy (keeping duplicate equipment) and backups (keeping a copy of the ledger elsewhere) are all tools of that “assume it happens” preparation. Incident-response articles specify procedures in oddly fine detail for the same reason: working out the fire exit during the fire is too late.
A rehearsal shop: production and staging
One more term worth knowing before the main series: environment. You meet it as “production environment”, “staging environment”, “development environment”.
An environment is roughly “a building with a complete set of the service running in it”. And in real operations you keep, alongside the actual shop customers visit (production), an identically built shop for rehearsals. That is staging.
Why the extravagance? It ties back to “refitting without closing”. Try a new dish directly in the real shop and get it wrong, and the customers in front of you suffer. So you build it on your own practice bench (development), take it to the rehearsal shop (staging) for a final check under production-like conditions, and only then put it into the real shop (production). When the main series says “verify in staging before going to production”, this rehearsal is what it means.
Common misconceptions about development and operations
A few misunderstandings beginners tend to carry.
First, seeing “testing as an optional extra that follows development”. In real projects the effort spent on testing is often equal to the effort of writing the thing, or more. And in recent years, how good the automated tests are determines development speed itself. A kitchen with a solid tasting regime can push out new dishes with confidence.
Second, the intuition that “fewer releases are safer”. Understandable, but industry research finds the opposite. Ship six months of changes at once and, when something goes wrong, you cannot tell which change caused it. A shop that ships small changes frequently has smaller individual failures, identifies causes immediately, and ends up safer. That is why “deployment frequency” shows up in the main series as a measure of quality.
Third, judging teams by “zero incidents means a good operations team”. Fewer is better, obviously, but what the profession actually looks at is how fast you recover when it does happen and whether you can build machinery that stops the same failure recurring. The postmortem you meet in the main series is not a hunt for the culprit; it is the minutes of a meeting about not doing it again.
Mapping to the terms used in the main series
| This article’s analogy | Term in the main series | Meaning |
|---|---|---|
| Devising the new dish | Development, implementation | Writing the program and building features |
| Tasting, and rechecking the rest | Testing, automated testing, regression testing | Confirming it behaves correctly |
| The line from tasting to serving | CI/CD, pipeline | Automating test through release |
| The rehearsal shop | Staging environment | A production-like place for final checks |
| Putting the dish on the menu | Release, deploy | Getting it to users |
| Daily trading | Operations | Keeping the service running |
| Health-check instruments | Monitoring, observability | Noticing trouble early |
| The day book | Logs | The record of what happened |
| Minutes of the review meeting | Postmortem | Incident review and prevention |
How this connects to the main series
All of this is covered in detail in the “DevOps Architecture” category — building the release machinery, the daily trading, and preparing for incidents. Turning this loop quickly and safely is precisely its subject.
Related articles
Summary
This article, the last of the primers, covered the path from development to operations as the running of a restaurant.
Development is devising the dish, testing is tasting, release is serving, operations is daily trading, monitoring is the health check, and incidents are prepared for rather than wished away. With that mapping in your head, the later categories of the main series read much more easily.
That completes all six primers. If you have read this far, you are more than ready to start the main series. Begin with the guide to reading it and pick whichever category interests you.
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (9/95)