Quick answer: MLOps (machine learning operations) is the set of practices and tools teams use to get a machine learning model from a notebook into production and keep it working once it is there. It borrows the automation and version-control discipline of DevOps and applies it to the parts that are unique to ML: shifting data, retraining, and models that quietly get worse over time. In practice MLOps is what turns a one-off trained model into a system someone can actually rely on.
So what does that look like day to day? It is the pipeline that retrains a fraud model every week on fresh transactions, the registry that tracks which version of a model is live, and the dashboard that flags when predictions start drifting off. This entry covers how MLOps works mechanically, where teams actually use it, how it differs from plain DevOps and from model deployment specifically, and where it still falls short.
What Is MLOps?
A trained model is not a finished product. It needs a repeatable way to get evaluated, packaged, deployed, and watched, and it needs that process to survive the model being retrained next month on different data. MLOps is the answer to that problem: a set of practices for building and running that repeatable pipeline instead of hand-carrying a model to production once.
The term mirrors DevOps on purpose. DevOps closed the gap between writing code and running it reliably in production. MLOps does the same job for machine learning, but adds pieces DevOps never had to deal with, chiefly the data feeding the model and the fact that a model’s accuracy can decay on its own even when the code never changes.
Most teams describe MLOps maturity in stages. At the bottom is a fully manual process: a data scientist trains a model in a notebook and hands it to an engineer to deploy by hand, with no automated testing and no scheduled retraining.
In the middle, teams automate the training pipeline itself so a model can be retrained and redeployed on a schedule or a trigger. At the top, the whole path from code change to tested, deployed, monitored model runs through continuous integration and delivery with little manual intervention.
How Does MLOps Work?
MLOps extends three familiar continuous practices and adds a fourth. Continuous integration tests not just code but data schemas and model quality before anything merges. Continuous delivery automates packaging and deploying the trained model and the pipeline that produced it.
The fourth is continuous training: the model gets retrained automatically, on a schedule or when monitoring detects it has drifted, and the new version goes out through the same tested path. Continuous monitoring is what watches the live predictions and the data flowing into them, so a drop in accuracy or a shift in the inputs raises an alert instead of going unnoticed.
Underneath those practices sit a handful of concrete components: a version control system for code, a place to track datasets and training data versions, an experiment tracker that logs which parameters and data produced which result, a model registry that records which version is approved and live, and an orchestrator that runs the pipeline steps in order. MLflow, originally built at Databricks, is one of the more widely used open source tools for the experiment tracking and registry pieces. Kubeflow and Google’s TensorFlow Extended (TFX) cover the pipeline orchestration side, often running on Kubernetes.
The registry step matters more than it sounds. Before a newly trained model replaces the one currently serving traffic, it usually has to clear an evaluation gate, matching or beating the incumbent model on a held-out test set, so a retraining run that happens to learn something worse never gets promoted automatically. That gate is what lets continuous training run unattended without a human reviewing every new version by hand.
Where Is MLOps Used?
Uber’s Michelangelo platform is one of the clearer public examples. Uber began building it in mid-2015 after running into the problem directly: there was no standard place to store training results, no easy way to compare one experiment against another, and no established path to production, so an engineering team typically built a custom serving container for each project.
Michelangelo replaced that with a single internal platform covering data preparation, training, evaluation, deployment, and monitoring, and it has been serving production models at Uber since around 2016.
Retail and finance companies lean on MLOps for models that need frequent retraining, like fraud detection and demand forecasting, where the data distribution genuinely shifts week to week. Companies fine-tuning open models on their own support tickets or product catalogs use MLOps pipelines to make that a repeatable process rather than a one-time project, which matters as fine-tuning smaller models becomes a normal part of building an AI product instead of something only a few labs do.
On-device and mobile ML teams use a version of the same discipline, just with an extra deployment target: a model has to be tested, packaged, and monitored for a phone or edge device, not only a server, which is where on-device AI work and MLOps practice overlap.
MLOps vs Model Deployment vs DevOps: What’s the Difference?
Model deployment is one step inside MLOps, not a synonym for it. Deployment is the act of putting a specific trained model into a place where it can serve predictions. MLOps is the whole surrounding system, including everything that happens before deployment, like data validation and training automation, and everything that happens after, like monitoring and scheduled retraining.
DevOps and MLOps share the same instinct: automate builds, test before release, deploy consistently, monitor in production. What DevOps does not handle on its own is data.
A code deployment either works or it does not, and it stays working until the code changes again. A deployed model can get quietly worse as the real world drifts away from the data it was trained on, even though nothing about the model itself changed. MLOps exists largely to catch that.
What Are the Limits of MLOps?
Setting up a real MLOps pipeline is a genuine engineering investment. Small teams often deploy a model by hand for months before any of this automation is worth building, and a heavyweight pipeline can slow down a team that just needs to ship one model.
Tooling in this space is also fragmented. Experiment tracking, pipeline orchestration, feature stores, and monitoring each have several competing open source and vendor options, and stitching them into one coherent system is its own project, one reason platform teams like Uber’s built a single internal system rather than assembling one from parts. Leaning on a single cloud vendor’s bundled MLOps stack solves that fragmentation but trades it for lock-in, since pipelines built around one provider’s registry and orchestrator rarely move cleanly to another.
MLOps also cannot fix a bad model. It can catch drift and automate retraining, but if the underlying data is biased or the model was the wrong approach for the problem, faster, more automated deployment just gets the wrong answer to users sooner. The discipline manages the pipeline around a model; it does not replace the judgment that goes into building the model in the first place.