What is MLOps?
MLOps is the set of practices for deploying, monitoring, and maintaining machine learning models in production, extending DevOps to cover the parts of a system that change because data changes rather than because code changes.
Why DevOps is not enough
Conventional software is deterministic: the same input yields the same output, and behaviour changes only when someone edits code. A machine learning system has three moving parts — code, data, and the trained model — and it can degrade without anyone touching any of them, simply because the world moved. See model drift.
That single difference generates most of MLOps. Reproducibility now requires versioning data and models alongside code. Testing must cover data quality and model quality, not just function behaviour. And monitoring must watch prediction distributions, because a model that has silently become wrong still returns HTTP 200 for every request.
What it actually covers
Reproducibility. Any model in production should be traceable to the exact code, data snapshot, and hyperparameters that produced it. Without this, debugging a regression is guesswork and rolling back is impossible.
Pipeline automation. Turning a notebook into a scheduled, testable pipeline — ingestion, validation, training, evaluation, deployment. The notebook-to-production gap is where most projects stall.
Validation gates. A new model should not ship because it improved an aggregate metric. It should clear checks on important data slices, on latency, and on not regressing cases that previously worked.
Deployment strategy. Shadow deployment runs the new model alongside the old without acting on its output. Canary releases route a small traffic share. Both exist because offline evaluation regularly disagrees with live behaviour.
Monitoring and rollback. Track input distributions, output distributions, and business outcomes. Keep the previous model warm and make reverting a single action.
Get the order right
The common failure is buying a platform before establishing practice. Tooling does not create discipline, and a sophisticated MLOps stack around an unreproducible training script solves nothing.
A sane maturity order: first make training reproducible and get the model served behind a versioned API. Then add automated data validation and a real evaluation suite, because that is what makes any later automation safe. Then add drift monitoring and alerting. Then automate retraining — and only then, if the volume of models justifies it, adopt a feature platform or a full orchestration stack.
Two sizing notes. Automated retraining is often premature: for many systems a deliberate quarterly retrain with human review beats a nightly pipeline nobody is watching. And a feature store earns its complexity when several models share features or when training-serving skew has actually bitten you — not by default.
- Data changes, not just code — systems degrade with no deploy and no code edit
- Version all three — code, data, and model must be traceable together
- Gate on slices, not averages — aggregate improvement can hide serious regressions
- Practice before platform — reproducibility and evaluation first; tooling later
More on MLOps.
What is the difference between MLOps and DevOps?
DevOps manages code moving to production. MLOps manages code, data, and models together, because a machine learning system can break without any code change when the input distribution shifts. That adds data versioning, model registries, data-quality testing, prediction monitoring, and retraining pipelines to the standard DevOps concerns. The CI/CD foundations are shared; the data dimension is what is new.
Do I need an MLOps platform for one model?
No. For a single model, the valuable parts are cheap and mostly conventions: a reproducible training script under version control, a pinned data snapshot, a versioned serving endpoint, basic input and output monitoring, and a documented rollback. That covers most of the risk. Dedicated platforms start earning their operational cost once you are maintaining several models with shared features and retraining cadences.
Related terms.
Model Drift
Model drift is the gradual loss of a deployed model's accuracy because the statistical relationship it learned no longer matches t…
ReadFeature Store
A feature store is infrastructure that computes, stores, and serves model input features from a single definition, so that trainin…
ReadInference
Inference is the act of running a trained model on new input to produce a prediction, and because it happens on every request it u…
ReadHyperparameter Tuning
Hyperparameter tuning is the search for configuration values that are set before training rather than learned during it, such as l…
ReadNeed this built?
Applying this to a
real system?
We build and ship production machine learning. If mlops is part of a problem you are working on, tell us about it.
Start the conversationor write to us at [email protected]