MLOps
Also known as: Machine Learning Operations, ML Ops, ModelOps
- MLOps
- MLOps (machine learning operations) is the discipline of reliably deploying, monitoring, and maintaining machine learning models in production, covering the full lifecycle from data and model versioning through training, deployment, and governance, and adding continuous retraining to the standard DevOps practices of continuous integration and delivery.
MLOps (machine learning operations) is the set of practices for deploying, monitoring, and continuously retraining machine learning models in production, applying DevOps discipline to systems whose behavior depends on changing data.
What It Is
A machine learning model that scores well in a data scientist’s notebook is not a product. It becomes one only when it runs in production, serves real requests, and keeps performing as the world around it changes. MLOps is the discipline that handles everything between “the model works on my laptop” and “the model works for customers, reliably, month after month.” It exists because machine learning systems fail in ways ordinary software does not: the code can be perfect while the model quietly grows wrong, because the data it sees in production drifts away from the data it was trained on.
The name blends “machine learning” with “DevOps,” the software practice of automating how code is built, tested, and released. MLOps borrows that automation and adds the parts unique to ML. According to Google Cloud, it is a paradigm for deploying and maintaining models in production reliably, bridging model development and operations. Where traditional DevOps revolves around continuous integration and continuous delivery, automatically testing and shipping code, MLOps adds a third loop. According to Google Cloud Architecture, it extends CI/CD with continuous training: automated retraining on fresh data when a model’s performance starts to slip.
That makes versioning the base layer. To retrain a model and trust the result, a team has to know exactly which dataset and which code produced which model, the properties called reproducibility and lineage. This is where data versioning fits into MLOps: tools like Git LFS, DVC, and lakeFS track large datasets the way Git tracks code, so a regression can be traced to the exact data that caused it. On top of that base sit feature stores, model registries, monitoring, and serving infrastructure. According to Google Cloud Architecture, MLOps maturity is described in levels: a manual, notebook-driven process at the bottom, then pipeline automation with continuous training, and finally full CI/CD automation of the whole loop.
How It’s Used in Practice
Most people meet MLOps not as a tool they install but as the operating model behind a machine learning feature their company already ships, such as a recommendation engine, a fraud filter, or a demand forecast. The model launched once; MLOps is what keeps it honest afterward. A team sets up automated pipelines so that retraining, testing, and deployment happen the same way every time, instead of a data scientist manually rerunning a notebook and copying files to a server.
In practice this usually runs on a managed platform such as Amazon SageMaker, Google Vertex AI, or Databricks, which handles the plumbing: scheduling retraining jobs, storing model versions in a registry, and watching live predictions for data drift, the gradual divergence between today’s inputs and the training data. When monitoring flags drift, the pipeline retrains on recent data and promotes the new model only if it passes its tests. For the product manager, the payoff is concrete: fewer silent failures, a clear record of what shipped when, and a model that degrades gracefully instead of failing unnoticed.
Pro Tip: Before buying an MLOps platform, ask one question: when this model’s accuracy drops next quarter, who finds out, and how? Most teams over-invest in slick deployment and under-invest in monitoring. The deployment happens once; the monitoring runs forever. Get the alerting and retraining trigger right first, and the rest earns its keep.
When to Use / When Not
| Scenario | Use | Avoid |
|---|---|---|
| A model serves live traffic and must stay accurate as data changes | ✅ | |
| One-off analysis or a model that runs once and is never updated | ❌ | |
| Several models, frequent retraining, multiple people on the team | ✅ | |
| A solo prototype still being explored in a notebook | ❌ | |
| A regulated domain that needs reproducibility and audit trails | ✅ | |
| A tiny project where full pipeline automation costs more than it saves | ❌ |
Common Misconception
Myth: MLOps is just DevOps with a machine learning label, so set up CI/CD and you are done. Reality: DevOps assumes the software behaves the same way as long as the code does not change. Machine learning breaks that assumption. A model’s inputs drift, its accuracy decays, and the artifact that needs versioning is not only code but data and trained models too. That is why MLOps adds continuous training, data versioning, and live monitoring of predictions on top of standard DevOps. The code can sit untouched for a year while the model silently becomes wrong.
One Sentence to Remember
MLOps is the difference between a model that works in a demo and a model that keeps working in production: it brings versioning, automated retraining, and monitoring to systems whose accuracy quietly erodes as their data changes, so failures get caught and corrected instead of discovered by customers.
FAQ
Q: What is the difference between MLOps and DevOps? A: DevOps automates building and shipping code. MLOps adds the parts unique to machine learning: versioning datasets and models, retraining on fresh data, and monitoring live predictions for the accuracy decay that code-focused DevOps never checks for.
Q: Do I need MLOps for a single machine learning model? A: If the model runs once and is discarded, no. If it serves live traffic and must stay accurate as data changes, yes, even a lightweight pipeline beats manually rerunning notebooks and copying files to a server.
Q: How does data versioning relate to MLOps? A: Data versioning is a foundational layer of MLOps. Retraining or reproducing a model requires knowing exactly which dataset produced it, so tools like DVC and lakeFS track datasets the way Git tracks code.
Sources
- Google Cloud: What is MLOps? - Vendor-neutral overview of the MLOps discipline and lifecycle.
- Google Cloud Architecture: MLOps: Continuous delivery and automation pipelines in machine learning - Defines the CI/CD/CT extension and the MLOps maturity levels.
Expert Takes
MLOps treats a deployed model as a system that decays, not a finished artifact. The principle is simple: a model’s accuracy depends on how closely production data resembles training data, and that resemblance erodes over time. Everything else, the versioning, the automated retraining, the monitoring, follows from accepting that drift is the default state of any model meeting the real world.
Think of MLOps as making the entire model lifecycle reproducible by specification rather than by memory. The dataset, the training code, the resulting model, and the deployment config all become versioned, declared artifacts, so any model in production can be traced to the exact inputs that built it. Get that lineage right and retraining becomes a routine, auditable step instead of a risky manual ritual nobody wants to repeat.
MLOps is where machine learning stops being a science project and starts being a product line. The companies pulling ahead are not the ones with the cleverest models; they are the ones that can retrain, redeploy, and recover faster than their data goes stale. Operational discipline, not model novelty, is becoming the real moat that separates the teams that ship from the ones that demo.
A model that quietly drifts is making consequential decisions on assumptions that no longer hold. MLOps promises to catch that, but monitoring only watches what someone chose to measure. Who decides which failures count, and which silently slide through? Automating retraining can also automate the spread of yesterday’s bias into tomorrow’s predictions. Reliability and accountability are not the same thing.