MLOps basics: from notebook to deployed model

What you will build: a trained scikit-learn model wrapped in a small web API (FastAPI) that returns predictions as JSON, tested locally, containerised with Docker, and with simple logging so you can monitor it.

Prerequisites: Python, scikit-learn basics (see *Classification: predicting categories*), and a laptop with Python 3.10 or newer. Docker is optional: the Docker step needs Docker Desktop installed. FastAPI is covered in the Backend Development track.

We use the classic iris flower dataset so the focus stays on deployment, not modelling.

A model in a notebook helps nobody. MLOps is the set of practices that take a model from notebook to something that runs reliably for real users, and keeps it healthy afterwards. Think of it as DevOps plus the extra problems that models bring: data changes, models go stale, and results are hard to reproduce.

The most common deployment bug is saving the model but not the preprocessing. Use a scikit-learn Pipeline so the scaler and the model are saved together as one object.

fastapi
uvicorn
scikit-learn
joblib
pydantic

For a real project, pin exact versions (for example scikit-learn==1.5.2, using the versions you tested with) so the server matches your laptop.

import joblib
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import accuracy_score
from sklearn.model_selection import train_test_split
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler

iris = load_iris()
X_train, X_test, y_train, y_test = train_test_split(
    iris.data, iris.target, test_size=0.2, random_state=42, stratify=iris.target
)

pipeline = Pipeline([
    ("scale", StandardScaler()),
    ("model", LogisticRegression(max_iter=200)),
])
pipeline.fit(X_train, y_train)

acc = accuracy_score(y_test, pipeline.predict(X_test))
print(f"test accuracy: {acc:.3f}")

joblib.dump({"pipeline": pipeline, "classes": list(iris.target_names)}, "model.joblib")
print("saved model.joblib")

Trains, prints the test accuracy (high on this easy dataset) and saves the pipeline and the class names into one file.

The API has two endpoints: /health to check the service is alive, and /predict to get a prediction. Pydantic validates the input, so bad requests are rejected with a clear error instead of crashing the model. We log each prediction so that we can monitor it later.

import logging
import time

import joblib
from fastapi import FastAPI
from pydantic import BaseModel, Field

logging.basicConfig(level=logging.INFO, format="%(asctime)s %(message)s")
logger = logging.getLogger("iris-service")

artifact = joblib.load("model.joblib")
pipeline = artifact["pipeline"]
classes = artifact["classes"]

app = FastAPI(title="Iris classifier")


class Flower(BaseModel):
    sepal_length: float = Field(gt=0, lt=20)
    sepal_width: float = Field(gt=0, lt=20)
    petal_length: float = Field(gt=0, lt=20)
    petal_width: float = Field(gt=0, lt=20)


@app.get("/health")
def health():
    return {"status": "ok"}


@app.post("/predict")
def predict(flower: Flower):
    start = time.perf_counter()
    features = [[flower.sepal_length, flower.sepal_width,
                 flower.petal_length, flower.petal_width]]
    probs = pipeline.predict_proba(features)[0]
    best = int(probs.argmax())
    elapsed_ms = (time.perf_counter() - start) * 1000
    logger.info("input=%s prediction=%s confidence=%.3f latency_ms=%.1f",
                features[0], classes[best], probs[best], elapsed_ms)
    return {"prediction": classes[best], "confidence": round(float(probs[best]), 3)}

The model is loaded once when the server starts, not on every request. That is important for speed.

import requests

r = requests.post(
    "http://127.0.0.1:8000/predict",
    json={"sepal_length": 5.1, "sepal_width": 3.5, "petal_length": 1.4, "petal_width": 0.2},
)
print(r.status_code, r.json())

bad = requests.post("http://127.0.0.1:8000/predict", json={"sepal_length": -1})
print(bad.status_code)

Needs pip install requests. The first call should return a 200 with a prediction (setosa for these measurements). The second returns 422 because fields are missing or invalid.

The confidence value will differ a little on your machine. The 422 shows that input validation works: the model never sees garbage.

Automated tests catch breakages when you retrain or change code. FastAPI ships a test client. (If you get an error about httpx, run pip install httpx pytest.)

from fastapi.testclient import TestClient

from app import app

client = TestClient(app)


def test_health():
    assert client.get("/health").json() == {"status": "ok"}


def test_predict_setosa():
    r = client.post("/predict", json={
        "sepal_length": 5.1, "sepal_width": 3.5,
        "petal_length": 1.4, "petal_width": 0.2,
    })
    assert r.status_code == 200
    assert r.json()["prediction"] == "setosa"


def test_rejects_bad_input():
    r = client.post("/predict", json={"sepal_length": -1})
    assert r.status_code == 422

Run with pytest. These tests check the behaviour you promised users, not the model's accuracy; test accuracy separately in training.

A Docker image packages your code, Python and libraries together, so it runs the same on your laptop, a teammate's machine or a cloud server. This removes "it works on my machine".

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py model.joblib ./

EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

Copying requirements first lets Docker reuse the cached install layer when only your code changes. Use the same scikit-learn version for training and serving, or loading the model may fail or behave differently.

docker build -t iris-service .
docker run -p 8000:8000 iris-service

Then call http://127.0.0.1:8000/predict as before. From here the same image can be deployed to a cloud service that runs containers.

Deploying is the start, not the end. Models fail quietly: the server stays up but predictions get worse. Watch three things.

Our log lines already capture inputs, predictions and latency. Real systems send these to a log or dashboard tool, compare input statistics against the training data, and alert when they shift. Retrain when quality drops or on a schedule, and test the new model against the old one before switching.

When you try many models, a notebook full of overwritten cells is not reproducible. Tools such as MLflow (open source) record the parameters, metrics and model file of every run so that you can compare runs and go back to any of them. At minimum, even without a tool: keep code in Git, set random seeds, write down the data version and save metrics from each run in a file.

You are an experienced ML engineer. Review my model-serving code for production problems: input validation, error handling, model loading, logging, security, versions and reproducibility.

[paste app.py and Dockerfile]

List the top 5 risks in order of importance with a concrete fix for each. Do not rewrite everything.

What to expect: A good review mentions things like validation, pinned versions, handling a missing model file, and not logging sensitive data. Decide yourself which fixes to apply.