What Is MLOps?
The gap between a working notebook and a reliable production system, how MLOps differs from DevOps and DataOps, and five concrete failure stories
What Is MLOps?
TL;DR
A model that works once, on a held-out test set, on a laptop, is not the same thing as a model serving real traffic reliably as the world it predicts about keeps changing. MLOps is the discipline that closes that gap — it shares tooling with DevOps (CI/CD, containers) but adds concerns software alone never has: a model can pass every code test and still be a worse model, and it can silently degrade with no code changing at all.
| Property | Value |
|---|---|
| Level | Beginner — start here |
| Reading time | ~18 minutes |
| Prerequisites | None. |
| You will understand | Precisely what's missing between a notebook and production, and how MLOps differs from DevOps and DataOps |
What "Works in the Notebook" Actually Means
A model that scores well in a notebook has cleared exactly one bar: it performs well on a fixed, static snapshot of data, evaluated once, by the person who built it, with no time pressure and no real users depending on the answer. Production asks for three things a notebook never has to provide:
| Requirement | What the notebook was missing |
|---|---|
| Reliability under real traffic | Concurrent requests, malformed input, traffic spikes, infrastructure failures — none of which a notebook run ever sees |
| Observability into live behavior | The notebook's author watched it run. In production, nobody is watching by default — you only know what you instrumented |
| A response plan for the world changing | The notebook's test set is frozen forever. Production's input distribution keeps moving, and the model doesn't get retrained just because reality did |
"It worked when I tested it" is the weakest form of evidence a model can offer once it's serving real traffic. A notebook run tells you the model can be right. It tells you nothing about whether it stays right, under load, over time, as the data it sees drifts away from what it was trained on.
MLOps vs DevOps
What's shared, and what's genuinely different
Shared: deployment discipline
CI/CD pipelines, containerization, infrastructure-as-code, automated testing — MLOps builds directly on DevOps practice rather than reinventing it. Anyone who already knows DevOps has a real head start.
Different: correctness has two axes, not one
RecommendedSoftware either does what the code says or it has a bug — one axis. A model can execute its code perfectly, return a well-formed response in bounds, pass every unit test, and still be a worse model than the one it replaced. Model quality is a second axis that ordinary software testing has no way to check.
Different: silent degradation with no code change
RecommendedA piece of software behaves identically today and next year unless someone changes the code. A model can get quietly worse over months with the code completely untouched, simply because the world it's making predictions about moved — this is drift, and it has no equivalent in ordinary software operations.
MLOps vs DataOps
DataOps focuses on the reliability of data pipelines themselves — ingestion, transformation, quality checks, making sure data arrives complete and on schedule. MLOps depends on that foundation but extends past it into concerns DataOps doesn't own: training, evaluating, versioning, serving, and monitoring the model built on top of that data. A useful way to hold the distinction: DataOps asks "is the data trustworthy," MLOps asks that too, and then adds "is the model built from it still good, and is it running reliably."
Five Failure Stories
Each challenge from the crash course maps to a specific, realistic way things go wrong without it — not an abstract risk, but a scenario that plays out routinely on teams that skip the practice.
Deployment: the Friday-afternoon manual release
A data scientist SSHes into the production box, pulls the new model file, and restarts the service by hand. It works. Three weeks later, someone else does the same thing, forgets to restart one of two replicas, and the service silently splits traffic between two different model versions for a week before anyone notices the inconsistent predictions.
Monitoring: the model that got worse in silence
A fraud-detection model's precision drops from 94% to 71% over two months as fraud patterns shift. Nothing crashes. No error rate rises. The team finds out when finance flags a spike in losses, two months after the drop started — because nobody was tracking prediction quality, only that the service was up.
Scaling: the demo that fell over at launch
A recommendation model handles 50 requests per second comfortably in testing. Launch day brings 2,000 requests per second in the first hour. The fixed pool of servers, sized for the testing load, falls over completely — not because the model was wrong, but because nothing was watching load and adding capacity.
Versioning: "wait, which model is actually live?"
An incident review asks which model version produced a bad batch of predictions last Tuesday. Nobody can say for certain — deployments happened by hand, from whoever's laptop had the newest file, with no record kept. The investigation stalls for two days just establishing what was running.
Cost: the bill nobody was watching
A support chatbot quietly starts sending every request to the most expensive available model after a routing config bug, instead of the cheap model for simple queries. The bug ships on a Friday. The bill arrives, 4x normal, at the end of the month — the first anyone noticed.
Every one of these is a story about missing visibility or missing process, not about a fundamentally hard technical problem. That's the actual promise of MLOps: not that it makes any of this impossible, but that it makes each of these five stories something you'd catch in minutes instead of weeks.
Concept Checks
Check yourself
A model passes every unit test in CI and deploys cleanly. Why might it still be a worse production model than the one it replaced?
Because software correctness and model quality are separate axes. Unit tests check that the code runs, returns well-formed output, and doesn't crash — none of which says anything about whether the model's actual predictions are as accurate as the previous version's. A model can be flawless by every code-level test and still perform worse on the task it exists to do, which is exactly what a model-quality validation gate exists to catch.
Why can a model get worse over time with absolutely no code changing?
Because the model's quality depends on how well its training data still represents the world it's currently making predictions about — and that real-world data keeps shifting while the model's weights stay frozen. This is drift: the code and the model artifact are identical to six months ago, but the distribution of inputs (or the true relationship between input and correct output) has moved, so the same frozen model now performs worse on the current reality.
Why does MLOps build on DevOps practice rather than replace it?
Because the deployment mechanics — CI/CD, containers, infrastructure-as-code — are genuinely the same problem for a model-serving service as for any other service, and DevOps already solved that layer well. MLOps adds a layer on top for the concerns unique to models (quality validation, drift, versioning of trained artifacts) rather than needing to reinvent the deployment layer underneath it.
Key Concepts Recap
| Concept | One-line summary |
|---|---|
| The notebook-to-production gap | Reliability, observability, and a response to a changing world — none of which a notebook run has to provide |
| MLOps vs DevOps | Shared deployment tooling; different because model quality is a second axis software correctness doesn't cover |
| MLOps vs DataOps | DataOps ensures the data is trustworthy; MLOps extends that into training, evaluation, serving, and drift |
| Silent degradation | A model can get worse with zero code changes, purely because the world it predicts about moved |
| The five failure stories | Missing deployment discipline, monitoring, scaling, versioning, and cost control each fail in specific, recognizable ways |
| MLOps' real promise | Not making these problems impossible — making them visible in minutes instead of weeks |
Next
With the problem defined, the first practical piece is getting a model to actually answer requests: Model Serving Patterns.
MLOps Crash Course
All of MLOps on one page — serving, containers, orchestration, CI/CD, registries, monitoring, drift, caching, and the LLM-specific operational problems
Model Serving Patterns
REST, batching, and async serving in depth — plus the health-check mistake almost every team makes at least once