1 · What MLOps is
Your trained model in a notebook is not a product. MLOps is the discipline of getting a model into production and keeping it healthy — the practices that close the gap between 'it works on my machine' and 'it serves real users reliably'.
MLOps is DevOps adapted to machine learning: it adds DATA and MODEL versioning, experiment tracking, and DRIFT monitoring on top of the usual build/test/deploy automation — because an ML system can silently rot as the world's data shifts, even when the code never changes.
Without this:
Without MLOps you ship a model once, lose track of which version is live, can't reproduce how it was trained, and never notice when it quietly degrades — the classic 'we deployed it and forgot about it' failure.
You finished the scikit-learn capstone in bc-py-59: a Pipeline tuned by GridSearchCV, evaluated on a held-out set, and saved with joblib.dump. That .joblib file is a real, valuable artifact — but it is not a product. Nobody can use it. It sits on your laptop. To make it useful you have to wrap it in an API, package it so it runs anywhere, deploy it to a server, and keep watching it after launch. That whole journey — from a trained artifact to a reliable, monitored service — is what MLOps covers.
The notebook-to-production gap. A notebook is interactive, single-user, and full of hidden state (cells run out of order, variables left over from earlier experiments). Production is the opposite: unattended, multi-user, and it must give the same answer every time for the same input. Bridging that gap is the core problem MLOps solves.
The ML lifecycle is a loop, not a line. Traditional software ships and is "done". ML is never done, because the data keeps changing. The lifecycle cycles continuously:
data ──▶ train ──▶ evaluate ──▶ deploy ──▶ monitor
▲ │
└────────────────────────────────────────────┘
(drift detected → collect new data → retrain)
You collect data, train a model, evaluate it, deploy it, and monitor it in production. When monitoring detects that the live data has drifted away from what the model was trained on, you loop back: gather fresh data and retrain. The loop never closes for good.
Hidden technical debt. The famous Google paper "Hidden Technical Debt in Machine Learning Systems" (Sculley et al., 2015) made a now-classic observation: the ML model code is only a tiny box in a much larger system. Surrounding it are data collection, feature extraction, configuration, serving infrastructure, and monitoring — and that surrounding machinery is where most of the long-term cost and risk live. Ignoring it is how a model that scored beautifully in a notebook becomes an un-maintainable liability six months later.
DevOps vs MLOps. MLOps borrows almost everything from DevOps — version control, automated testing, CI/CD pipelines, containers, infrastructure-as-code. But ML adds problems plain software doesn't have. In normal software the inputs are code; if the code doesn't change, behavior doesn't change. In ML, the data is also an input that changes on its own. So MLOps adds three ML-specific concerns: data + model versioning (not just code), experiment tracking (which data + hyperparameters produced which metrics), and drift monitoring (catching when the live world no longer matches the training world).
The ML lifecycle loop and exactly what MLOps adds on top of DevOps: data/model versioning, experiment tracking, and drift monitoring.
What primarily distinguishes MLOps from plain DevOps?
- A trained `.joblib` model is an artifact, not a product; MLOps is the discipline of turning it into a reliable, monitored service and keeping it healthy.
- The ML lifecycle is a loop — data → train → evaluate → deploy → monitor → back to data — because drift means a model is never permanently 'done'.
- MLOps = DevOps + ML-specific additions: data/model versioning, experiment tracking, and drift monitoring; the model code is only a small box in a much larger system (Sculley et al., 2015).
Every model that ever serves a real user — a fraud scorer, a recommender, a churn predictor — lives or dies on the MLOps practices that wrap it: packaging, deployment, versioning, and monitoring.
If you remove it: You'd build great models that never leave the notebook, or ship them once with no way to reproduce, track, or notice when they break — the gap this whole track exists to close.