Machine learning is not a one-shot task — it is a continuous cycle. Data changes, user behaviour shifts, the world evolves. A model that was accurate at deployment degrades over time unless the full lifecycle is managed as a system, not a project.

MLOps = Machine Learning + DevOps + Data Engineering. It is the set of practices, tools, and cultural norms for deploying and maintaining ML models in production reliably. The name is modelled on DevOps — but the challenges are fundamentally different because the artefact is not just code, it is code + data + model.

Google (2021) defined three maturity levels for MLOps. Most organisations are at Level 0. The progression is not about buying tools — it is about automating the feedback loop.

Data pipelines come in two fundamental paradigms: batch (scheduled, high-throughput, process data in chunks) and streaming (real-time, event-driven, process data as it arrives). Most production systems use both — the “lambda architecture” runs batch for training and streaming for inference.

A feature store is a centralised repository of curated, versioned features that are shared between training and serving. Without it, data scientists recompute the same features ad hoc in every experiment, and serving code re-implements training logic — the most common source of training/serving skew.

# Feast feature definition (Python SDK)
from feast import Entity, Feature, FeatureView, ValueType
from feast.data_source import BigQuerySource
user = Entity(name="user_id", value_type=ValueType.INT64)
user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    ttl=timedelta(days=1),
    features=[
        Feature(name="avg_order_value", dtype=ValueType.FLOAT),
        Feature(name="total_orders_30d", dtype=ValueType.INT64),
        Feature(name="days_since_last_order", dtype=ValueType.INT64),
    ],
    online=True,
    source=BigQuerySource(
        table="project.dataset.user_features",
        timestamp_field="event_timestamp",
    ),
)
# Training: get historical features (point-in-time join)
training_df = store.get_historical_features(entity_df, ["user_features:avg_order_value"])
# Serving: get latest features (online store lookup, ~5ms)
features = store.get_online_features(entity_rows=[{"user_id": 42}], features=["user_features:avg_order_value"])

Data is the most common failure mode in production ML. Great Expectations lets you define expectations about your data (schema, ranges, distributions) and test them automatically. DVC (Data Version Control) tracks data files alongside code in Git, storing the actual data in remote storage.

# Great Expectations — validate a dataframe
import great_expectations as gx
context = gx.get_context()
ds = context.sources.add_pandas("my_ds")
asset = ds.add_dataframe_asset("training_data")
batch = asset.build_batch_request(dataframe=df)
# Define expectations
validator = context.get_validator(batch_request=batch)
validator.expect_column_values_to_not_be_null("user_id")
validator.expect_column_values_to_be_between("age", min_value=0, max_value=150)
validator.expect_column_mean_to_be_between("income", min_value=20000, max_value=200000)
results = validator.validate()  # Returns success/failure + details

# DVC — version data alongside code
$ dvc init                          # Initialise DVC in git repo
$ dvc add data/training.parquet     # Track data file (creates .dvc pointer)
$ git add data/training.parquet.dvc # Commit pointer to git
$ git commit -m "Add training data v1"
$ dvc push                          # Push actual data to remote (S3, GCS)
# Later: reproduce exact training data
$ git checkout v1.0                 # Checkout code + DVC pointers
$ dvc pull                          # Pull matching data from remote

An ML experiment produces multiple artefacts: code, data reference, hyperparameters, metrics, trained model weights, and environment configuration. Without structured tracking, reproducing a result from three months ago is nearly impossible. Experiment trackers log all of these automatically and make them searchable, comparable, and shareable.

# MLflow — experiment tracking in 10 lines
import mlflow
mlflow.set_experiment("fraud-detection")
with mlflow.start_run():
    mlflow.log_param("learning_rate", 0.001)
    mlflow.log_param("epochs", 50)
    mlflow.log_param("model_type", "XGBoost")
    # ... train model ...
    mlflow.log_metric("accuracy", 0.943)
    mlflow.log_metric("f1_score", 0.891)
    mlflow.log_metric("auc_roc", 0.967)
    mlflow.sklearn.log_model(model, "model")  # Save model artefact
    mlflow.log_artifact("confusion_matrix.png")  # Save any file

# Weights & Biases — experiment tracking
import wandb
wandb.init(project="fraud-detection", config={
    "learning_rate": 0.001,
    "epochs": 50,
    "model_type": "XGBoost"
})
# ... train model, log metrics per step ...
wandb.log({"accuracy": 0.943, "f1": 0.891, "loss": 0.12})
wandb.finish()

A model registry is a versioned catalogue of trained models with metadata, lineage, and lifecycle stages (Staging → Production → Archived). It answers: “What model is in production right now, who approved it, and what data trained it?”

# FastAPI — simplest model serving API
from fastapi import FastAPI
import joblib
app = FastAPI()
model = joblib.load("model.pkl")
@app.post("/predict")
async def predict(features: dict):
    X = [[features["age"], features["income"], features["credit_score"]]]
    prediction = model.predict(X)[0]
    probability = model.predict_proba(X)[0].tolist()
    return {"prediction": int(prediction), "probability": probability}
# Run: uvicorn app:app --host 0.0.0.0 --port 8000

# Evidently — drift detection in 5 lines
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset
report = Report(metrics=[DataDriftPreset()])
report.run(reference_data=train_df, current_data=prod_df)
report.save_html("drift_report.html")   # Visual drift report
# Programmatic access to results
drift_results = report.as_dict()
if drift_results["metrics"][0]["result"]["dataset_drift"]:
    trigger_retraining_pipeline()  # Auto-retrain on drift

A vector database stores high-dimensional embedding vectors and supports approximate nearest neighbour (ANN) search — finding the k most similar vectors to a query vector. This is the retrieval engine behind RAG, semantic search, and recommendation systems.

# LiteLLM — unified LLM API gateway
from litellm import completion
# Same interface for any provider
response = completion(
    model="gpt-4o",        # or "claude-3-sonnet" or "ollama/llama3"
    messages=[{"role": "user", "content": "Explain MLOps"}],
    max_tokens=500,
    temperature=0.7
)
print(response.choices[0].message.content)
# Fallback: try GPT-4o, fall back to Claude if it fails
response = completion(
    model="gpt-4o",
    messages=messages,
    fallbacks=["claude-3-5-sonnet-20241022"]  # auto-retry with fallback
)

Docker containers package code, dependencies, and model weights into a single reproducible unit. “It works on my machine” becomes “it works in the container.” Multi-stage builds keep images small; GPU access via NVIDIA Container Toolkit.

# Dockerfile for ML model serving (multi-stage)
FROM python:3.11-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.11 /usr/local/lib/python3.11
COPY model/ ./model/         # Model weights
COPY app.py .               # FastAPI app
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]
# Build & run:
# docker build -t fraud-model:v1 .
# docker run -p 8000:8000 fraud-model:v1
# GPU: docker run --gpus all -p 8000:8000 fraud-model:v1