What Is MLOps? Running Machine Learning in Production

Your data scientist built a model that predicts which customers will cancel. In the notebook, it looked great. Six months later, nobody can say which data trained the version running in production, the person who deployed it has left, and its predictions have quietly gotten worse. Nobody noticed until a sales manager asked why the list stopped making sense.

That story is why MLOps exists. Building a model is the easy part. Keeping it accurate, traceable and running in production, week after week, is where most machine learning projects succeed or fail. This guide explains what MLOps is, the practices it covers and a simple path to adopt it without buying a giant platform on day one.

What MLOps means

Google Cloud’s architecture guidance describes MLOps as an ML engineering culture and practice that unifies ML system development and ML system operation. In plain terms, it’s DevOps for machine learning: the habits, tools and automation that get models from experiment to production and keep them healthy there.

Machine learning needs its own discipline because a model is not just code. Its behavior depends on 3 things that all change over time:

• Code: the training and serving logic
• Data: the examples the model learned from
• The model itself: the trained artifact, its settings (hyperparameters) and its evaluation results

Regular software breaks when someone changes the code. A machine learning model can break when nobody changes anything, simply because the world it’s predicting has changed. Customer behavior shifts, a supplier changes a product code, or a new sales channel sends data in a different format. MLOps is built around that reality.

If you’re still sorting out the basic terms, our explainer on machine learning vs deep learning is a good primer.

Why the model is the small part

A widely cited Google research paper, “Hidden Technical Debt in Machine Learning Systems” (Sculley and colleagues, NeurIPS 2015), argued that real-world ML systems commonly carry large ongoing maintenance costs. The authors pointed to risks specific to ML, including hidden feedback loops, tangled data dependencies, configuration problems and changes in the external world.

Google’s MLOps guidance makes the same point another way: only a small fraction of a real-world ML system is the ML code. The rest is data collection, data verification, feature extraction, serving infrastructure, configuration and monitoring. That surrounding system is what MLOps is designed to manage.

The core practices of MLOps

MLOps covers the full model life cycle. These are the practices most teams adopt first.

Versioning everything

You need to know exactly which code, which data and which settings produced each model. That means:

• Code in version control (Git)
• Data snapshots or dataset versions, so you can retrain on the same data
• Experiment tracking that records parameters, metrics and results for each training run
• A model registry that stores trained models with their version, lineage and approval status

Google’s guidance describes an ML metadata store that records each pipeline run’s parameters, artifacts and evaluation metrics. That record is what makes rollbacks and audits possible.

Automated pipelines and continuous training

Instead of a person rerunning a notebook, a pipeline handles data preparation, training, evaluation and validation as repeatable steps. Google’s guidance adds a practice unique to ML on top of CI and CD: continuous training (CT), which retrains and serves models automatically on fresh data. Triggers can be a schedule, the arrival of new data, a drop in performance or detected drift.

Testing beyond code

In ML, continuous integration tests more than code. Google’s guidance notes that CI also covers validating data, data schemas and models. Typical checks include:

• Does the incoming data match the expected schema and value ranges?
• Is the new model at least as accurate as the current one on a held-out test set?
• Does it perform acceptably for important customer segments, not just on average?
• Is prediction speed within your limits?

Deployment

Models are served as an API, embedded in an application, or run in batches (for example, scoring all customers overnight). Safer rollout patterns, such as testing a new model on a small share of traffic or A/B testing it against the current one, reduce the risk of a bad release.

Monitoring

Once live, you watch both the system and the predictions. That includes uptime and latency, but also data drift (inputs that look different from the training data) and model decay (accuracy dropping over time). Google’s guidance recommends tracking data statistics and online performance so you know when a model is stale and should be retrained.

Key takeaway: MLOps is not a tool you buy. It’s the habit of treating data and models like production assets: versioned, tested, deployed through a repeatable process and watched after release.

MLOps vs DevOps vs related terms

AIOps is often confused with MLOps, but it’s the reverse relationship: AIOps applies AI to IT operations. Our guide to what AIOps is covers it. For generative AI apps, Microsoft’s architecture guidance describes GenAIOps as adding prompt life cycle, retrieval augmentation, output safety and token cost governance on top of MLOps rather than replacing it. If you’re shipping LLM features, see how to evaluate LLM outputs.

A simple MLOps maturity path

Both Google and Microsoft publish maturity models. Google describes 3 levels, from manual (level 0) to ML pipeline automation (level 1) to full CI/CD pipeline automation (level 2). Microsoft’s Azure model uses 5 levels, from “No MLOps” (level 0) to full automated operations (level 4), and notes that most organizations show traits of more than one level at a time.

Here’s a simplified path that combines the 2:

You don’t need to reach stage 5 for every model. A model that is retrained twice a year for an internal report may be fine at stage 2 or 3. A fraud or pricing model that makes thousands of decisions a day probably needs stage 4 or 5.

Where to start with MLOps

If you have 1 or 2 models in production today, start here:

1. Inventory your models. List each model, its owner, where it runs, what data it uses and what decisions it affects.
2. Put all training code in version control and stop deploying from notebooks.
3. Track experiments with an experiment tracking tool, such as open-source MLflow or a cloud ML platform’s built-in tracking.
4. Create a model registry so every production model has a version, its training data reference and its evaluation results.
5. Define a “good enough” bar in writing, for example a minimum accuracy on a fixed test set, and check every new model against it.
6. Add basic monitoring: input data checks, prediction volume and a periodic accuracy check against real outcomes.
7. Automate the most painful manual step next, usually retraining or deployment.

Good MLOps depends on good data. Our guides on what a data pipeline is and how to improve data quality cover the foundations. Teams that already run an internal developer platform can often extend it for ML; see platform engineering and developer experience.

Common MLOps mistakes

• Buying a platform before defining a process. Tools help, but only once you know what you want to version, test and monitor.
• Monitoring the server but not the predictions. A model can return answers quickly and still be wrong.
• No owner after launch. Every production model needs a named person responsible for its performance.
• Ignoring governance. Models that affect people, such as lending, hiring or pricing, need documentation, bias checks and audit trails.
• Over-automating too early. Automatic retraining without validation gates can push a worse model into production.

Conclusion

MLOps is how machine learning goes from a promising experiment to a dependable part of your business. Version your code, data and models, automate training and testing step by step, and watch both the system and its predictions after launch. Start small with the models you already have, and add automation where manual work hurts most. If you’re hiring for these skills, our guide on how to become a machine learning engineer shows what the role involves.

Sources

• Google Cloud: MLOps: Continuous delivery and automation pipelines in machine learning — MLOps definition, levels 0 to 2, continuous training, data and model validation, metadata store and monitoring
• Microsoft Azure Architecture Center: MLOps maturity model — 5-level maturity model and GenAIOps capabilities
• Sculley et al., “Hidden Technical Debt in Machine Learning Systems,” NeurIPS 2015 — ML-specific maintenance risks in real-world systems