AI.Cruz
Home/MLOps

Introduction to MLOps

MLOpsBy Updated

Only 5–10% of ML code is the model itself. MLOps is the discipline that keeps the other 90% from collapsing in production.

ML Lifecycle

Status
Normal

ML Project Lifecycle

Maturity Level

Level 0
Manual — ad hoc
Level 1
Auto training (CT)
Level 2
Full CI/CD/CT

Introduction to MLOps

The engineering discipline that takes ML from notebook to reliable production system.

The POC-to-production gap

A data scientist trains a model that achieves 94% accuracy on a held-out test set. The model ships to production and within three months accuracy drops to 71%. No code changed. What happened?

This is the central problem MLOps addresses. ML model code accounts for only about 5–10% of the total code in a production ML system. The remaining 90% is data pipelines, feature engineering, serving infrastructure, monitoring, configuration management, and the glue that connects them. Sculley et al. called this hidden technical debt in ML systems — and unlike software debt, it is invisible until the model fails.

What MLOps is

MLOps, short for Machine Learning Operations, applies DevOps principles — automation, reproducibility, monitoring, and continuous improvement — to the ML system lifecycle. It is not a single tool but a set of practices covering three domains:

  • Data — versioning datasets and feature engineering pipelines so any model can be reproduced from scratch
  • Model — tracking experiments, packaging models, automating retraining triggers, and validating models before they replace live ones
  • Code — CI/CD pipelines that test ML code changes the same way software teams test application code

Why ML systems fail in production

Four failure modes account for most production ML incidents:

  1. Data drift (covariate shift) — the distribution of input features changes over time. A fraud detection model trained on 2022 transaction patterns sees 2025 patterns that look nothing like its training data.
  2. Concept drift — the relationship between features and labels changes. The same features that predicted fraud in 2022 no longer predict it in 2025 because fraud tactics evolved.
  3. Training-serving skew — a mismatch between how features are computed during training versus serving. The most common cause: different code paths for the same feature.
  4. Model staleness — a model trained once and never retrained becomes progressively less accurate as the world drifts away from its training distribution.

The ML project lifecycle

A production ML project moves through six stages, and the arrow from monitoring back to data is what makes it a cycle rather than a pipeline:

  1. Data — collection, labeling, validation, versioning
  2. Feature engineering — transformation, selection, feature store
  3. Training — experiment tracking, hyperparameter search, model selection
  4. Evaluation — offline metrics, slicing, fairness checks, shadow evaluation
  5. Deployment — containerization, canary rollout, A/B testing
  6. Monitoring — drift detection, performance degradation alerts, retraining triggers

The diagram on the left visualises this as a circle because monitoring feeds back into data — detected drift triggers a new data collection or retraining run.

The five MLOps pillars

PillarWhat it means in practice
ReproducibilityGiven the same data + code + config, the same model emerges. Requires versioning all three.
AutomationData validation, training, evaluation and deployment run without human intervention when triggered.
Continuous Training (CT)Models retrain automatically on new data or when drift is detected.
Continuous Delivery (CD)Validated models deploy to production automatically after passing tests.
MonitoringData distributions, prediction distributions, and model performance are tracked in production at all times.

Versioning data vs models

Software version control (Git) tracks code. ML systems also need to version data and models, which are binary artifacts too large for Git:

  • DVC (Data Version Control) — stores data artifacts in object storage (S3, GCS) and tracks them with Git-like pointers. A git commit can reference both code and the exact dataset version it was trained on.
  • MLflow / Weights & Biases — track model versions, hyperparameters, metrics, and artifacts from every training run. The Model Registry manages the promotion from Staging to Production.

The hidden technical debt

Beyond standard software debt, ML systems accumulate debt in ways that are invisible until they fail:

  • Undeclared data dependencies — a model silently depends on an upstream pipeline that changes without warning
  • Feedback loops — model output influences future training data (a recommendation model shapes what users click, which shapes future training labels)
  • Configuration debt — hyperparameters, thresholds, and feature lists scattered across scripts without version control
  • Glue code — the connecting code between off-the-shelf components that dwarfs the model code itself

The diagram from Sculley et al. (2015) shows the ML model as a small box surrounded by vast supporting infrastructure — what engineers actually spend most of their time on.

MLOps maturity levels

Google's MLOps framework defines maturity by how much automation is in place:

  • Level 0 (Manual) — data scientists train and deploy ad hoc. No pipelines, no automation, no monitoring. Common in early ML projects.
  • Level 1 (CT pipeline) — automated ML pipeline triggers retraining when new data arrives or performance drops. Experiment tracking in place. Still manual deployment.
  • Level 2 (Full CI/CD/CT) — automated testing of both models and pipelines, rapid reliable deployment, comprehensive monitoring and automated retraining triggers. The target state for production ML.

Tools landscape

CategoryTools
Experiment trackingMLflow, Weights & Biases, Comet ML, Neptune
Data versioningDVC, LakeFS, Delta Lake
Pipeline orchestrationKubeflow, Airflow, ZenML, Prefect
Model servingSeldon, BentoML, FastAPI, TorchServe
MonitoringEvidently, WhyLabs, Arize, Fiddler
Cloud platformsSageMaker (AWS), Vertex AI (GCP), Azure ML

What to remember

The model is a small fraction of the work. MLOps is the discipline that makes the remaining 90% — data pipelines, feature engineering, serving, monitoring, and retraining — robust, reproducible, and automated. A model that degrades silently in production is not a model problem; it is an MLOps problem.

Recall check

0 of …

Say the answer out loud before you reveal it — recalling it is what makes it stick, and rereading it is not.

  1. What does 'training-serving skew' mean in MLOps?

  2. What are the three MLOps maturity levels?

  3. What is the hidden technical debt specific to ML systems?

  4. Why is continuous training (CT) different from continuous delivery (CD) in MLOps?

Cheat sheet

Introduction to MLOps

ML model code is only 5–10% of a production ML system. MLOps covers the remaining 90%: data pipelines, feature engineering, serving, monitoring, and automated retraining. A model that degrades silently in production is not a model problem — it is an MLOps problem.

MLOPS · AI.Cruz.in/mlops/mlops_introduction.html

More in MLOps

MLOpsConcept and Data DriftMLOpsMLflow Experiment TrackingMLOpsModel Serving and Deployment

About the author

AI.Cruz builds and maintains AI.Cruz. Every module here is written and the visualisation behind it hand-built, so the numbers in a readout come from the same code that draws the picture. Corrections are genuinely welcome and get priority over everything else — if a page states something wrong, or an animation misrepresents what the algorithm does, get in touch.

About AI.CruzContact