What is MLOps? It is the set of engineering practices that lets a team train, ship, run and update machine learning models as reliably as it ships any other software. The name comes from DevOps, but the work is different, because a model's behavior depends on data as well as code.
This article defines the term without the marketing, lists what the practice actually covers, and describes the stages most teams pass through. If you are weighing whether to invest in it, the last sections say when it pays off and when it does not. For what we build in this area, see our MLOps services.
The short definition
Google's architecture guidance on MLOps describes it as an engineering culture and practice that unifies ML system development and ML system operation, with automation and monitoring across the whole lifecycle: integration, testing, releasing, deployment and infrastructure management (Google Cloud architecture center). That is a fair summary. Strip the vocabulary and MLOps answers one question: how do we get from a notebook that works once to a service that keeps working next quarter?
Why models need their own operations discipline
A conventional service is defined by its code. If the tests pass and the build is the same, behavior is the same. A model is defined by code, training data, hyperparameters, the random seed, the library versions and the hardware it was trained on. Change any of them and you may get a different model, and nothing will throw an error to tell you.
The 2015 NeurIPS paper Hidden Technical Debt in Machine Learning Systems made this argument early: the model is a small part of a production ML system, and the surrounding code, data dependencies and feedback loops carry most of the maintenance cost. That paper is still a good reading assignment for anyone new to the field.
Three consequences follow, and they explain most of what MLOps tooling does.
- Reproducibility is not free. You have to record which data, code and configuration produced each model, or you cannot rebuild it or explain it.
- Models degrade silently. The world changes while the model stays fixed. Input distributions shift, labels arrive late, and accuracy drifts down without a single exception in the logs.
- Training and serving can disagree. If features are computed one way in a notebook and another way in the production service, the model sees inputs it never trained on. This is usually called training-serving skew.
What MLOps covers
Different organizations draw the boundary differently. This is the scope we use when we scope an engagement.
| Area | The question it answers | Typical artifacts |
|---|---|---|
| Data validation | Is the data we are about to train on what we expect? | Schema checks, distribution checks, data versions |
| Experiment tracking | Which run produced which result? | Run records with parameters, metrics, code revision |
| Pipelines | Can training run without a person at the keyboard? | Orchestrated, containerized steps |
| Model registry | Which model version is in production, and where did it come from? | Versioned models with lineage and stage or alias |
| CI and CD | Is it safe to release this change? | Unit, data and model tests, automated deploys |
| Serving | How do predictions reach the product? | Online API, batch job, or embedded model |
| Monitoring | Is it still working? | Latency and error metrics, drift and quality signals |
Tools exist for every row. MLflow covers tracking and a registry, DVC versions data alongside Git, Kubeflow runs pipelines on Kubernetes, and KServe serves models on Kubernetes. None of them is MLOps by itself. They are parts, and the practice is deciding which parts you need and wiring them so the whole lifecycle is repeatable.
The maturity levels
The Google guidance above describes three levels of automation. They are a useful map even if you never use their cloud.
- Level 0, manual. Every step from data analysis to validation is done by hand, usually in notebooks. A data scientist hands a trained model to an engineer. Releases are rare, there is no CI or CD, and monitoring is minimal or absent.
- Level 1, pipeline automation. Training is an automated pipeline. It validates incoming data, trains, validates the new model against the current production model, and records metadata so a run can be traced and rolled back. It can be triggered on a schedule, on new data, or on a degradation signal. The goal is continuous training.
- Level 2, CI/CD for the pipelines themselves. The pipeline code is built, tested and deployed automatically. Tests cover feature logic, training behavior and the prediction API, and releases move through test and pre-production before production.
A common starting point is between levels 0 and 1: a model in production that one person knows how to retrain. That is a legitimate place to be for a first model. It becomes a problem at the second or third model, or the day that person leaves.
MLOps, DevOps and LLMOps
MLOps builds on DevOps and keeps its habits: version control, automated tests, infrastructure as code, observability. If your delivery pipeline is weak, fix that first; our DevOps services cover it. What MLOps adds is the handling of data and model artifacts as first-class, versioned things, plus monitoring for quality, not just uptime.
LLMOps is the same idea applied to applications built on large language models. The artifacts change: prompts, retrieval indexes and evaluation sets matter more than training runs, and cost per request becomes an operational metric. If you are in that world, read LLM monitoring and observability and look at our LLMOps services.
What a minimal setup looks like
You do not need a platform to start. A defensible first version for one model looks like this:
- Code in Git, with training as a script that takes a config file and does not depend on a notebook's hidden state.
- Training data in a versioned location, with a content hash or version recorded for every run.
- Each run logs parameters, metrics and the Git commit to a tracking server.
- A container image that holds the serving code and loads a specific model version, not "latest".
- A test that loads the candidate model and checks predictions on a fixed set of known examples before release.
- Basic service metrics plus at least one model-quality or input-distribution signal, with an alert that a person sees.
That is a modest amount of engineering, not a platform project. Add a scheduler or orchestrator when retraining becomes routine, and a feature store only when several models share the same features and you are paying for inconsistencies.
When it is worth doing, and when it is not
It is worth it when a model's output feeds a product or a decision, when it needs retraining as data changes, when more than one person touches it, or when someone outside the team will ask how a prediction was produced. It is premature for a one-off analysis, a prototype that may be discarded, or a model that is retrained once a year with a person checking every output. Over-building here is a common failure: a team adopts an orchestrator, a feature store and a registry for a single batch model that a cron job and a bucket would have handled.
A useful test: if the person who trained the production model were unavailable tomorrow, could someone else rebuild it from the repository and retrain it on new data? If not, you have a level 0 process, whatever tools you have installed.
Where to go next
If you want to build the skills yourself, the learn MLOps path sets out an order to study things in, and the MLOps interview questions are a good self-check. If you are about to ship a model, model deployment strategies covers how to roll it out safely, and AI model deployment challenges in production lists what tends to go wrong afterward.
If you would rather have this built and handed over with documentation, request a quote and tell us which model you need to run in production.