MLOps: Machine Learning Operations Explained

What is MLOps?

MLOps applies DevOps principles—continuous integration, continuous delivery, and continuous monitoring—to the machine learning lifecycle [1]. It addresses a fundamental challenge: building a working model in a notebook is relatively easy; deploying it reliably into production, keeping it accurate as data changes, and governing it at scale is hard.

Google Cloud defines MLOps as “an ML engineering culture and practice that aims at unifying ML system development (Dev) and ML system operation (Ops)” through “automation and monitoring at all steps of ML system construction” [1]. Microsoft Azure frames it as “the application of DevOps principles and practices to the machine learning lifecycle” [2].

The key insight is that ML systems are fundamentally different from traditional software. A software application produces the same output for the same input. A model’s output can degrade over time as real-world data shifts—a phenomenon called model drift. MLOps exists to manage that reality.

The ML lifecycle

MLOps orchestrates the full ML lifecycle, which typically includes:

• Data collection and preparation — gathering, cleaning, and transforming training data
• Feature engineering — creating the variables the model will learn from
• Model training — running algorithms on prepared data to learn patterns
• Model evaluation — testing performance against held-out data and fairness criteria
• Model registration — versioning and storing approved models in a central registry
• Deployment — serving the model for predictions (online or batch inference)
• Monitoring — tracking operational health and ML-specific signals (data drift, concept drift, prediction quality)
• Retraining — automatically or manually updating the model when performance degrades [1][2]

Each stage requires different tooling, different teams, and different quality gates. MLOps connects them into a coherent, reproducible pipeline.

MLOps maturity levels

Google Cloud’s maturity framework describes three levels of MLOps adoption [1]:

Level 0 — Manual process: Data scientists build models in notebooks, hand them off to engineers for deployment, and retrain manually when performance drops. No CI/CD, no automation. This is where most teams start.

Level 1 — ML pipeline automation: The training pipeline is automated and orchestrated—new data or code changes can trigger retraining. Experimentation is faster, but deployment still involves manual steps.

Level 2 — CI/CD pipeline automation: Both training and serving pipelines are fully automated with triggers, model registries, and continuous delivery. Data scientists can explore new features and architectures, and changes automatically build, test, and deploy to production.

Most production teams operate at Level 1. Level 2 is the target for organizations running models at scale.

CI/CD for ML: beyond traditional DevOps

In traditional software, CI/CD tests code and deploys packages. In MLOps, the scope is broader [1][2]:

• Continuous Integration (CI) tests not just code but also data schemas, data quality, and model performance. A model that passes unit tests but performs worse on new data should not ship.
• Continuous Delivery (CD) deploys an entire ML training pipeline—not just a single software artifact—that automatically produces and deploys a model prediction service.
• Continuous Training (CT) is unique to ML: the system automatically retrains and serves models based on new data, without human intervention.

This three-part CI/CD/CT pipeline is the core machinery that makes MLOps work at scale.

Key tools and platforms

The MLOps ecosystem includes both open-source tools and managed platforms:

Open-source:

• MLflow — experiment tracking, model registry, and deployment. A Linux Foundation project with over 18,000 GitHub stars. Widely adopted as the default experiment tracking and model registry layer [3]
• Kubeflow — Kubernetes-native platform for orchestrating ML workflows. CNCF Incubator project. Includes Kubeflow Pipelines (workflow orchestration), Kubeflow Trainer (distributed training), and Kubeflow Hub (model registry) [4]
• DVC (Data Version Control) — version control for ML datasets and models
• Feast — open-source feature store for managing and serving ML features

Managed platforms:

• Google Vertex AI — end-to-end MLOps on Google Cloud
• Amazon SageMaker — AWS’s managed ML platform
• Azure Machine Learning — Microsoft’s MLOps platform integrated with Azure DevOps and GitHub Actions [2]
• Databricks — unified analytics and ML platform with MLflow integration

The tool landscape is fragmented, but the pattern is consistent: model registry + pipeline orchestration + monitoring + governance.

LLMOps: MLOps for language models

The rise of large language models (LLMs) has spawned LLMOps—a specialized subset of MLOps that addresses LLM-specific challenges [5]:

• Prompt engineering and versioning — managing and testing prompts as first-class artifacts
• Token-based cost management — tracking and optimizing usage costs, which replace compute-hour costs
• Non-deterministic outputs — evaluating relevance, coherence, safety, and hallucination rates rather than simple accuracy metrics
• RAG component monitoring — tracking retrieval quality in retrieval-augmented generation systems
• Fine-tuning oversight — managing when and how to fine-tune base models vs. use prompting strategies

AgentOps is an emerging sub-discipline that extends LLMOps to autonomous agents—managing tool-call reliability, multi-step planning evaluation, and multi-turn conversation monitoring [5].

Why MLOps matters for agents

AI agents depend on ML models for perception, reasoning, and decision-making. MLOps provides the operational foundation that makes agents reliable in production:

• Model serving — agents need low-latency access to models for real-time decisions
• Monitoring — agent behavior must be tracked for drift, hallucination, and unexpected outputs
• Versioning — when an agent’s underlying model changes, behavior changes. MLOps provides the governance layer to manage that transition
• Scaling — an agent fleet serving thousands of users needs the same operational rigor as any production ML system

Without MLOps, deploying agents is like running a factory with no quality control—things work until they don’t, and you find out too late.

Limitations and challenges

MLOps is not a silver bullet:

• Complexity — setting up a full MLOps pipeline requires expertise across data engineering, ML, DevOps, and platform engineering. Many teams lack one or more of these skills.
• Tool fragmentation — the ecosystem is crowded and evolving rapidly. No single tool covers everything; teams must assemble toolchains from multiple vendors.
• Organizational alignment — MLOps requires collaboration between data science, engineering, and operations teams. Cultural silos are often harder to break than technical ones.
• Overhead for small projects — a full CI/CD/CT pipeline is overkill for a prototype or research project. The maturity level should match the project’s needs.
• Monitoring gaps — ML-specific monitoring (drift detection, fairness metrics, hallucination rates) is still immature compared to traditional application monitoring.