Most machine learning models that get built never reach production. They sit in a notebook on someone’s laptop, perform well on a held-out test set, and then stall. The gap is not modelling skill — it is the absence of the operational scaffolding that turns a trained model into a service the rest of the business can actually use. MLOps, short for Machine Learning Operations, is the discipline that closes that gap: the deployment pipeline, the monitoring, the retraining loop, and the version control that together let a model run in production without a human babysitting it.
For organisations that have never operationalised a model before, the practical question is not “what is MLOps in the abstract” but “what is the smallest viable stack that still produces a production-quality deployment?” That is the question this article answers. It’s also the starting question behind our MLOps engagement pack.
Understanding MLOps
DevOps principles provide the foundation, yet three distinctive challenges separate machine learning operations from conventional software deployment: continuous data pipelines, post-deployment statistical drift, and weight-file rollbacks instead of code reversions. The end-to-end lifecycle MLOps automates runs from data collection through feature engineering, training, validation, deployment, monitoring, and retraining.
In our experience, the first MLOps implementation in an organisation rarely needs the full lifecycle on day one. What it needs is a working path from a registered model artifact to a served prediction, plus enough monitoring to detect when that path breaks. Everything else — automated retraining, feature stores, shadow deployments — is layered on once the first model is genuinely running.
Why do most ML models never reach production?
Bridging the notebook-to-production divide requires first understanding its precise contours. We see the same pattern across our consulting engagements with teams attempting their first deployment:
- The model lives in a Jupyter notebook with hard-coded paths and undocumented dependencies.
- There is no separation between training code and serving code, so the inference logic has to be re-derived.
- The data the model was trained on is not versioned, so the model itself cannot be rebuilt deterministically.
- There is no agreed contract for how the rest of the business calls the model — REST, batch file, message queue.
- Once deployed, no one knows whether the model is still working a month later.
Each of these is a missing MLOps capability. The reason most models stall is not that the team lacks data science talent; it is that none of the five items above are anyone’s explicit responsibility.
What does a first MLOps stack actually need?
Teams often replicate enterprise AI infrastructure wholesale—feature stores, inference clusters, automated retraining pipelines, drift detection, canary releases—delaying initial model deployment indefinitely. That is overengineering for a first project and almost always fails on cost or complexity grounds.
The minimum viable stack for a first deployment has four parts:
| Capability | Why it matters on day one | Realistic first-deployment tools |
|---|---|---|
| Model registry | Lets you point a serving system at “the current model” without rebuilding it | MLflow Model Registry, or even a versioned S3 bucket |
| Containerised serving | Makes the model environment reproducible across machines | Docker + FastAPI or BentoML; Kubernetes only if you already run it |
| CI/CD for models | Automates the path from “new model file” to “deployed endpoint” | GitHub Actions or GitLab CI invoking the container build |
| Basic monitoring | Tells you when latency, error rate, or input distribution shifts | Prometheus + Grafana for ops metrics; simple input statistics logging |
This is the floor. It is not glamorous, but in our experience it carries 80% of the production benefit of a full MLOps stack at perhaps 20% of the build cost. Once this stack is running and a model is actually serving requests, the team has the operational vocabulary to decide what to add next — usually automated retraining or a feature store, not both at once.
Which MLOps capabilities are overengineering for a first project?
The capabilities most often built too early, in our observation, are:
- Online feature stores — useful when many models share features, painful when only one model exists.
- Shadow / canary deployment infrastructure — valuable at scale, expensive overhead for one model serving low traffic.
- Automated retraining pipelines — premature until you have at least a month of production data showing the model actually needs retraining.
- Custom drift detection frameworks — start with logging input distributions and reviewing them weekly; only build automation once you know what drift looks like in your data.
The discipline is to add each of these after a triggering signal from the running system, not before.
How does MLOps differ from DevOps?
While both disciplines embrace version control, CI/CD, infrastructure-as-code, and monitoring, three operational dimensions create meaningful divergence.
Data is part of the artifact. A DevOps pipeline versions source code. An MLOps pipeline must also version the training data and the feature transformations, because the same code on different data produces a different model. Tools like DVC and lakeFS exist specifically to bring data under the same version control discipline.
Drift is a first-class failure mode. A deployed web service that worked yesterday will, all else equal, work today. A deployed model that worked yesterday may quietly degrade today because the input distribution has shifted — a new product category, a seasonal pattern, a change in upstream data formatting. Monitoring has to cover not just latency and error rate but also the statistical properties of the inputs and outputs.
Rollback semantics are different. Rolling back a code commit is well-understood. Rolling back a model means restoring a previous model version and understanding whether the input data the older model expects still matches what’s flowing through the pipeline. The model registry exists precisely to make this clean.
Which MLOps tools are realistic, and which assume maturity?
First-time deployers frequently encounter MLOps tools that presuppose robust data engineering capabilities not yet in place. A realistic mapping:
| Tool | Realistic for first deployment? | Why |
|---|---|---|
| MLflow | Yes | Lightweight, runs locally, covers tracking + registry without a Kubernetes cluster |
| Docker + FastAPI | Yes | Standard container serving; no MLOps-specific infrastructure needed |
| DVC | Yes | Git-like data versioning; low operational overhead |
| Kubeflow | Only if you already run Kubernetes | Powerful, but operating Kubernetes is itself a major undertaking |
| TensorFlow Extended (TFX) | No, for most first projects | Assumes TensorFlow throughout and a maturity of data pipelines that first-time teams rarely have |
| Feature stores (Feast, Tecton) | No | Pay off when multiple models share features; overhead for a single model |
| Airflow / Prefect | Yes, if batch | Useful for batch retraining or batch inference orchestration |
The pattern is consistent: tools that wrap a single concern (registry, container, data version) are realistic on day one; platforms that assume an orchestrated ecosystem are realistic on day 200.
A recognisable first-deployment arc
Our typical initial engagements follow a predictable trajectory. The team starts with a model in a notebook that demonstrably outperforms the existing rule-based system. We extract the inference logic into a Python module with a clear function signature, containerise it with FastAPI, register the trained model in MLflow, and wire a GitHub Actions workflow that rebuilds the container when a new model version is registered. Prometheus and Grafana cover latency and error rate; a separate logging job snapshots input feature distributions daily into a Parquet file that a data scientist can inspect when the model misbehaves.
Each phase produces an artifact that has value independent of the final system. The containerised inference module is reusable for the next model. The CI/CD workflow is a template. The monitoring dashboard generalises. This is what we mean when we say the second model deployment costs less than the first: the infrastructure is the durable output, not just the served model.
What usually remains imperfect after the first deployment is automated retraining and drift response. Both require enough production data to calibrate, which by definition does not exist on day one. Naming that explicitly is part of the engagement — a first MLOps implementation closes the notebook-to-production gap, and prepares the team to close the drift-response gap next.
FAQ
What does MLOps actually mean for an organisation that has never operationalised a model?
It means installing the minimum operational scaffolding to move a trained model out of a notebook and into a service the rest of the business can call, monitor, and update. Concretely: a model registry, containerised serving, a CI/CD pipeline that builds and deploys the container, and basic monitoring of latency, error rate, and input distributions.
Which MLOps capabilities does a first project genuinely need, and which are overengineering?
A first project needs a model registry, container-based serving, CI/CD for the container, and basic ops + input monitoring. It does not need an online feature store, automated retraining, canary infrastructure, or a custom drift framework on day one. Each of those should be added after a specific signal from the running system, not before.
Which MLOps tools and frameworks are realistic for a first deployment, and which assume mature data engineering already in place?
Realistic: MLflow, Docker + FastAPI, DVC, GitHub Actions / GitLab CI, Prometheus + Grafana. Assumes maturity: Kubeflow (requires Kubernetes operations), TFX (assumes TensorFlow-first pipelines), Feast / Tecton (pay off only with multiple models sharing features).
What is the smallest viable MLOps stack that still produces a production-quality deployment?
Model registry + containerised serving + a CI/CD workflow that rebuilds the container on a new model version + ops and input-distribution monitoring. Four moving parts, all available as open source, none requiring a Kubernetes cluster.
How does MLOps differ from DevOps in the data-pipeline, drift, and rollback dimensions?
DevOps versions code; MLOps must also version data and feature transformations, because the same code on different data yields a different model. DevOps does not have to monitor for statistical drift; MLOps must. DevOps rollback restores a code commit; MLOps rollback restores a model version and must verify the expected input contract still holds.
Why do most ML models never reach production, and which MLOps gaps cause that?
Because the operational scaffolding is no one’s explicit job. The recurring gaps we see are: notebooks with hard-coded paths instead of a packaged inference module, no separation between training and serving code, unversioned training data, no agreed calling contract for the rest of the business, and no monitoring once the model is deployed. Each gap maps directly to an MLOps capability.
We cover this transition in more depth in our companion piece on MLOps for organisations that have never operationalised a model, and revisit the broader operational picture in our introduction to MLOps.
Building MLOps infrastructure that survives contact with reality
Production deployments across three organizations have yielded velocity gains ranging from 40% to 3x (measured on the deployment). MLOps we need rewards teams that measure first and argue later — start with the smallest instrumented slice and let the numbers settle the design.
