My first instructor had a habit whenever I got too impressed by automation. Somewhere on the leg home, usually with light turbulence and a dim horizon, he would tap the autopilot panel twice and ask one question: “Who’s flying the airplane?” The correct answer was never “the airplane.” The answer he wanted was “I am — with help.” Years later, whenever somebody tells me their company reached NoOps, I hear that tap on the panel and ask the same thing in a different dialect: who is flying the operation?
This piece is the explanation I wish somebody had given me before I learned the vocabulary the slow way. No jargon walls, no vendor slides. Just the idea itself, what it keeps on your plate no matter what the brochures say, and one honest way to test any claim built on it.
What NoOps Actually Means
NoOps is the notion that a business can rent and script enough of its machinery that hiring a dedicated operations crew stops making sense. Servers get provisioned by clicking, deployments roll themselves out, monitoring alerts find the right phone automatically, and backups run on schedule without anybody feeding them tape. The routine disappears into software, which is precisely the point. The ambition is not laziness. It is arithmetic: if a tool does the task better and cheaper than a person, the person should be doing something else.
Say the word out loud, though, and you will discover it carries two meanings — which is why so many arguments about NoOps turn out to be two people arguing about different things.
Two Definitions, One Endless Argument
The first meaning is practical. A small company runs its whole platform on managed services, writes automation in place of runbooks, and simply never hires an operations department. Nobody carries the job title, yet the work still happens — spread across the provider, some scripts, and whichever engineer drew the short straw that week. Under this reading, NoOps describes a staffing arrangement, and plenty of startups live inside it happily.
The second meaning is absolute. True NoOps, as some dictionaries of the field describe it, is information technology that runs itself completely, with zero human hands — a vision usually mentioned in the same breath as AIOps. This version is a destination nobody has reached. Every company that claims it eventually produces an incident report proving otherwise.
The word itself dates back to 2011, when an analyst suggested developers would never need to speak with operations people again, and the claim has been softly corrected ever since. Neither of the two definitions above is the correction. The first one just reframes who is doing the work; the second keeps getting postponed, one decade at a time.
What NoOps Never Puts Down
Here is the part the brochures skip. Microsoft — a company that sells more managed services than almost anyone — publishes guidance listing the responsibilities that stay with you in every service model. The list is short and it does not shrink as you climb from raw servers to fully managed platforms:
- Your data, including where it lives, who can read it, and how it is backed up.
- Your identities, meaning the accounts and credentials that open the doors.
- Your configuration, every setting you or your tools have ever touched.
- Your access policies, the rules deciding who gets in and what they may do.
A student pilot already understands this pattern. Rent the cleanest, newest aircraft on the field and four things remain stubbornly yours: your medical certificate, your licence, your insurance, and your decisions. The rental company maintains the machine; it cannot maintain the pilot. Managed cloud behaves the same way. The provider maintains the datacentre; it cannot own your credentials or your judgement.
Serverless: One Route Toward NoOps, Not the Map
When serverless computing arrived — code that runs only when triggered, billed by the millisecond — many people announced that NoOps had finally arrived with it. The Cloud Native Computing Foundation disagreed, and its whitepaper on the subject says so without hedging: going serverless does not mean servers disappear, and it certainly does not mean the engineers who understand them become unnecessary. Somebody still chooses regions, sets memory limits, wires permissions together, and explains to the finance team why the bill moved.
Serverless is better described as one road out of many. Some workloads love it — spiky traffic, short tasks, unpredictable demand. Others outgrow it, and teams end up moving back to servers they manage themselves, accepting the operational chores as the price of control. Neither direction is a mistake; each is a trade priced in chores, and the honest teams write down which chores they chose. The road exists; it simply does not go everywhere.
A Pilot’s Test for NoOps Claims
Before you accept any pitch built on the promise, run the check my instructor would have run. It takes ten minutes and it has never once embarrassed the person asking:
- Name the human whose phone rings when the platform falls over in the small hours. If the answer is “nobody,” the real answer is “whoever notices first.”
- Ask who owns the four items on the list above — data, identities, configuration, access. “The vendor” is not an owner; it is a hope.
- Request the recovery story. How long until the service is back after a bad delete, and when was that path last rehearsed?
- Ask what the vendor explicitly does not cover. The exclusions page tells you more than the sales page ever will.
Notice that every question is about people and ownership, not about technology. That is the quiet lesson of fifteen years of this debate. When the tools improve, the chores move; the accountability stays seated exactly where it was.
Why Flight Students Should Care About NoOps
Modern flight training already runs on this kind of rented machinery: scheduling apps, online ground school, exam portals, logbook services. Each one is a small managed platform with somebody’s pager attached, even if you never see it. Understanding the pattern makes you a smarter customer of every tool you touch, and it foreshadows the systems you will meet in an airline cockpit, where automation runs deep and responsibility is deliberately kept human. Airlines learned decades ago that the crew cannot be automated out of the loop; the software world is only now catching up to that particular piece of aeronautical common sense.
If you are early in training, our checklist of documents needed for flight school admission is a good example of an operational register — a list that exists precisely so nothing is forgotten on the day it matters. Our weather study tips for student pilots show the same principle in the sky: check, verify, then trust the automation. And when you start planning hour-building, the complete guide to building flight hours applies the same arithmetic mindset that separates a real NoOps plan from a slogan: know your numbers before you commit.
The Operations Atlas keeps a useful summary of the whole story — origins, claims, and counter-evidence — at its NoOps reference page, if you want the version with dates and citations. Bring the ten-minute test with you. It works there too.
So, who’s flying the operation? Somebody always is. NoOps, at its best, just changes who buckles in — and a good pilot, like a good engineer, always checks who is in the seat before trusting the autopilot.
