What is MLOps? The parts nobody explains until production
Short answer: MLOps is the practice of getting machine learning models into production and keeping them useful there — versioning data and models, making training reproducible, automating deployment, and monitoring for the drift that quietly degrades every model. It is DevOps plus two things software does not have: data as a dependency, and silent failure.
A model that scores 0.94 in a notebook is not a product. It is a claim, made once, on a laptop, about a dataset that no longer exists in that exact form. MLOps is everything between that claim and a system your company can rely on next quarter.
The reason it needs its own name — rather than being "just DevOps" — comes down to two differences that break the normal software playbook.
Why machine learning breaks normal DevOps
Data is a dependency, and it is not in Git. Deploying software means shipping code. Deploying a model means shipping code, plus weights, plus the data those weights came from, plus the preprocessing that turned raw data into features. Change any one and the behaviour changes. "It worked last month" is not reproducible unless all four were captured, and by default none of them are.
Failure is silent. When an API breaks, something returns a 500 and an alert fires. When a model degrades, it keeps returning confident answers with the same latency and the same status code, and the only symptom is a business metric drifting in the wrong direction — often noticed weeks later, by someone in finance. Nothing in a normal monitoring stack catches that.
Everything MLOps does follows from those two facts.
The pieces, in the order you will need them
1. Experiment tracking
The first pain, and it arrives early. You ran forty experiments, one of them was good, and you cannot remember which parameters produced it. Tracking records every run — parameters, metrics, code version, dataset version, artefacts — so "the good one" is a record rather than a memory.
This is where MLflow fits, and it is the right first tool: it costs an afternoon to adopt and it removes the most common source of wasted weeks.
2. Data and feature versioning
A model is a function of its data. If you cannot say which rows trained it, you cannot reproduce it, debug it, or defend it to an auditor. In practice: version datasets (DVC, LakeFS, or plain object storage with immutable snapshots), and make the feature computation itself code that runs identically in training and in production. That last point deserves its own name.
3. Preventing training and serving skew
The most expensive bug in applied machine learning: the features computed during training are not quite the features computed at inference. A different default for missing values, a scaler fitted on the wrong split, a timezone. The model performs beautifully in evaluation and mediocrely in production, and the gap takes weeks to find because both sides look correct in isolation.
The fix is architectural. One implementation of feature computation, imported by both paths — not two implementations that are supposed to match.
4. A model registry
Where models go once they are worth keeping: versioned, staged (staging, production, archived), with lineage back to the run that produced them and the data they saw. It answers the question every incident eventually raises — which model is answering our customers right now, and who approved it?
5. Deployment
Three patterns cover almost everything:
- Batch: predictions computed on a schedule and written to a table. Boring, cheap, and the right answer far more often than teams assume.
- Real-time: the model behind an API, with latency budgets and autoscaling. This is where container and cloud skills stop being optional — the AI Deployment course covers this path end to end.
- Embedded: the model shipped inside an application or onto a device, where updating it means shipping a release.
Choose the simplest one your product tolerates. A daily batch job that works beats a real-time endpoint that pages someone.
6. Monitoring, which is where MLOps earns its keep
Three layers, and most teams only build the first:
- Operational: latency, error rate, throughput. Standard, necessary, insufficient.
- Data: are the inputs still what the model was trained on? Distribution shifts, new categories, a field that silently became null last Tuesday.
- Model: is it still right? Accuracy where you have ground truth, and proxy metrics where you do not — prediction distribution, confidence spread, override rate by human reviewers.
Drift is the umbrella term. Data drift is the inputs changing; concept drift is the relationship between inputs and outcome changing, which is worse because the data still looks normal. A fraud model degrades because fraudsters adapt, not because the schema changed. Only outcome monitoring catches that.
7. Retraining
Once monitoring works, retraining becomes a decision rather than a ritual. Retrain on a trigger — drift beyond a threshold, accuracy below a floor, enough new labelled data — and treat the retrained model as a candidate that must beat the incumbent on a frozen evaluation set before it is promoted. Automatic retraining without automatic evaluation is a machine for deploying regressions.
MLOps vs DevOps vs data engineering
| DevOps | Data engineering | MLOps | |
|---|---|---|---|
| Ships | Applications | Pipelines and datasets | Models, and the systems around them |
| Versions | Code | Schemas and pipelines | Code, data, features and weights |
| Fails by | Errors and outages | Late or broken pipelines | Silent degradation |
| Tests | Unit and integration tests | Data quality checks | Evaluation sets, drift monitors, shadow deployments |
| Core skill | Automation | Modelling data at scale | Both, plus statistics |
MLOps sits on top of the other two rather than replacing them. An MLOps engineer who cannot write a pipeline or read a Terraform file will be blocked constantly, which is why most people arrive here from one of the neighbouring disciplines rather than from a machine learning course.
A stack that is enough to start
Resist the platform. A first stack that works:
- Tracking and registry: MLflow.
- Data versioning: immutable snapshots in object storage, with a manifest committed to Git. Add DVC when that hurts.
- Training: a script, not a notebook, runnable by one command with a config file.
- Packaging: a container image, built by the same pipeline that builds everything else.
- Deployment: batch first. Real-time only when the product needs it.
- Monitoring: operational metrics from your existing stack, plus a scheduled job that compares input distributions and logs prediction summaries.
That is roughly a week of work for one engineer, and it covers most of what large platforms sell. Buy the platform when the week's worth of glue becomes the bottleneck — not before.
Where to learn each part
The three pieces build on each other: Machine Learning for the modelling foundations, MLflow and MLOps for tracking, registry and reproducibility, and AI Deployment for serving, scaling and monitoring in production. If your models are LLM-based rather than classical, the same operational concerns apply with different metrics — LLM Development covers evaluation harnesses, which are the LLM equivalent of a frozen test set.
And if you are missing the infrastructure half, that is the more common gap: containers, pipelines and cloud. Kubernetes is free with an account, and it is where most model serving ends up running.
Frequently asked questions
- What is MLOps in simple terms?
- MLOps is the set of practices for putting machine learning models into production and keeping them working: tracking experiments, versioning data and models, automating training and deployment, and monitoring for degradation. It is to models what DevOps is to applications, with data as an extra dependency.
- What is the difference between MLOps and DevOps?
- DevOps ships code and fails loudly — an error appears and an alert fires. MLOps ships code, data, features and model weights, and fails silently: a degraded model keeps returning confident answers at normal latency. That is why MLOps adds data versioning, evaluation sets and drift monitoring to the usual automation.
- What is model drift?
- Drift is a model becoming less accurate over time because the world moved. Data drift means the inputs changed distribution; concept drift means the relationship between inputs and the outcome changed, which is harder to detect because the inputs still look normal. Both require monitoring outcomes, not just infrastructure. The MLflow and MLOps course covers monitoring and registries.
- Do I need Kubernetes for MLOps?
- Not to start. Batch predictions on a schedule and a container behind a managed service cover most needs. Kubernetes becomes worthwhile when you serve several models in real time, need GPU scheduling, or already run the rest of your platform on it.
- What tools should a beginner learn for MLOps?
- MLflow for experiment tracking and the model registry, Docker for packaging, Git for everything, one CI/CD system, and one cloud. Add data versioning and a feature store only when the simple approach starts hurting — most teams adopt heavy platforms years earlier than they need to.
- Is MLOps a good career?
- Yes, and it is one of the harder roles to fill because it sits between three disciplines: software engineering, infrastructure and statistics. Most people arrive from data engineering or DevOps rather than from research, and the shortage is on the operational side rather than the modelling side.
Where to go next
If you have models that work in notebooks and nowhere else, start with tracking and a registry — MLflow and MLOps — then serving in AI Deployment. The roadmap shows how the AI track connects to the cloud and DevOps ones, which is where most MLOps work actually happens.