Dana kept a sticky note on her monitor for eleven months. It read, in her own handwriting: no ops. ever. The story of how that note got there, and why she eventually threw it away, is the most useful way we know to explain NoOps — the ambition to automate and outsource operational work so completely that nobody has to do it as a job. Dana and Miguel ran software for Harbor Flight Services, a small flight-school chain with four locations, a fleet of tired but honest trainers, and a scheduling app the front desk swore at daily. Two developers. No operations staff. A dream, a sticky note, and a December booking rush heading toward them like weather.
The Promise Behind the NoOps Dream
The dream had a pedigree, which is partly why it survived contact with reality for so long. Dana had read how the term took hold at Netflix back in 2012: Adrian Cockcroft used the label to describe a world where developers owned their own deployments and answered their own pagers — no separate operations group standing between the code and the customer. To Dana, engineering a two-person shop, that sounded less like history and more like instructions. Netflix ran enormous systems with small, senior teams. Harbor ran a booking app. How different could the trajectory be?
Miguel was the sceptic. He had grown up wrenching on pipers and trusted one rule above all others: every system needs a maintenance program, and pretending otherwise just moves the failure to an inconvenient altitude. Dana argued that cloud services were different — someone else’s maintenance program, billed monthly. That argument won the room, because the room was her.
Going Serverless for the Busy Season
The rebuild went exactly as advertised, which is the part nobody warns you about. They moved scheduling, payments, and notifications onto managed functions, and for three glorious months the infrastructure disappeared from their lives. No patch Tuesday. No capacity planning. Deploys took minutes. Dana updated the sticky note to read done.
The architecture had a shape worth describing, because thousands of small teams run something similar. Every user action triggered a short-lived function. State lived in a managed database. Glue between steps ran through a workflow service. On a quiet Wednesday in March, the whole design was elegant and nearly free. The bill read eleven dollars. Dana printed it and taped it beside the sticky note, which tells you everything about the mood in the room that spring.
And the feeling itself deserves a paragraph, because it is the real product being sold. For those three months, neither of them thought about infrastructure at all. No spare-parts shelf, no version pinned in a config file, no Sunday evening spent reading changelogs. They shipped features students actually asked for. Miguel, to his credit, kept a private list of the things that could bite — the retry behaviour, the cold starts, the workflow quotas — and the list felt paranoid right up until the week it became the agenda.
The Night the NoOps Dream Met December
December arrived on schedule, as it does. Every location opened its holiday booking window the same morning, and the fleet calendar became the most contested document on the West Coast. The functions scaled, as promised — and then the workflow service began timing out, retries stacked on retries, and the cost meter started recording numbers that looked like charter deposits. Miguel watched the dashboard at 6:40 a.m. with the expression of a man listening for a rough cylinder.
The app did not go down, which almost made it worse. It went slow — slow enough that students abandoned bookings, and the front desk restarted its phones. Revenue for the morning dropped by roughly a third. What failed, they worked out later, was not cloud computing but the fit between the workload and the building block: their heavy, steady, stateful pipeline had been forced through components designed for short, spiky, stateless tasks.
Reading the post-mortems of better-funded teams later, they found the same story at scale. Amazon’s own Prime Video engineers built a monitoring service on Step Functions and Lambda and watched it strain at around five percent of the load they had expected, then cut running costs by ninety percent by moving that workload to containers on EC2. The widely shared lesson was never “serverless bad”. It was that a building block must match the workload — and that Dana’s sticky note had been true and useless at the same time.
Retrofitting, Not Retreat
The fix took one focused quarter. They moved the steady core — the calendar engine, the reconciliation jobs — onto a small cluster of containers, sized and priced like a hangar lease rather than a taxi meter. They kept functions for what functions are good at: spiky, brief, stateless bursts like confirmation emails and webhooks. Nobody “went back to servers” in any sense that matters. They matched tools to jobs and wrote down who owned which seam between them.
Along the way Dana found the maturity ladder that practitioners use to grade this exact journey, and it stung in the helpful way. Level 0 is the claim itself — NoOps by assertion, which is what the sticky note had been. Higher levels track registers of duties, named ownership, rehearsed failures, and honest cost accounting, topping out at what the framework calls low-ops by design. Harbor, they agreed, had briefly been a Level 0 organisation with a very confident note on the monitor.
The money told the rest of the story. The rebuilt stack cost more in March than the eleven-dollar triumph — roughly a fixed hangar fee instead of metered taxi rides — and vastly less than the December spike had cost in a single morning, once abandoned bookings were counted. Finance understood the new shape immediately, which surprised both developers: predictable spend, reviewed quarterly, with the load test attached as evidence. Sometimes the most persuasive engineering document is an invoice pair from two different seasons.
What Dana Tells Two-Person Teams Now
She gives the same briefing these days, usually over hangar coffee, and it runs like this:
- Automation removes tasks; it has never once removed accountability, so put a name on every seam before the busy season does it for you.
- Match the building block to the workload — spiky and stateless goes to functions, steady and stateful goes to something you can size and lease.
- Rehearse your rush hour. Load that has never been practised is not capacity, it is a rumour.
- Keep a written register of who owns what, including the parts a vendor owns, and read it out loud once a quarter.
The parallel she draws for pilots is the one Miguel taught her, and it is the reason this story belongs on an aviation site: a light aircraft stays safe not because maintenance is avoided but because it is scheduled, owned, and logged — as covered in these safety checks every pilot should know and the mistakes owners most commonly make. Software estates work identically; only the vocabulary changes. Owners planning bigger machines will recognise the same discipline in turbine maintenance planning, where the cost of skipping a program compounds faster than anyone expects.
The sticky note is gone. In its place is a laminated card with five owner names and a rehearsed failure plan — less romantic, considerably cheaper. For readers who want the full framework behind Dana’s ladder, the definitions, the metrics, and the cautionary cases all live in the atlas’s full NoOps entry, which is the reference she now hands out instead of advice.
