This is the exact script Dev sent to the engineering team — and the exact script that failed on their server.

• import joblib — joblib is the library sklearn uses to serialize (save) trained models to disk. It’s not part of Python’s standard library, so if the server doesn’t have it installed, this line throws ModuleNotFoundError before the script even reaches the model.
• import numpy as np — NumPy is the array library that sklearn models depend on internally. Same problem: if the server has a different NumPy version (or none at all), the model’s internal operations may break or produce different results.
• joblib.load('my_model.pkl') — deserializes the saved model from a binary file. The .pkl file was created on Dev’s laptop with whatever version of joblib and sklearn he had installed. If the server has a different version of either, the load can fail silently or produce a model that behaves differently.
• model.predict(data) — the standard sklearn prediction call. Even if load succeeds, predict may crash if the NumPy version on the server handles array internals differently from Dev’s laptop.

The print("Model loaded successfully!") line at the bottom? That never ran. The script crashed on import joblib — the very first line.

This is a Dockerfile — a plain-text file (no .py extension) that Docker reads top-to-bottom to build an image. Each instruction creates a layer, and Docker caches layers so rebuilds are fast.

• FROM python:3.11-slim — the base image. This pulls a pre-built Linux image with Python 3.11 already installed. The -slim variant strips out compilers and system tools that aren’t needed at runtime, shrinking the image by ~600 MB. Dev’s model only needs Python and pip, so slim is the right starting point.
• WORKDIR /app — sets the working directory inside the container. All subsequent COPY and RUN commands operate relative to /app. If the directory doesn’t exist, Docker creates it.
• COPY requirements.txt . — copies only the requirements file from Dev’s laptop into the container’s /app directory. The . means “the current working directory inside the container” (which is /app because of WORKDIR). Copying just the requirements file before the rest of the code is deliberate — it enables layer caching (see the next instruction).
• RUN pip install --no-cache-dir -r requirements.txt — installs all Python dependencies inside the container. --no-cache-dir tells pip not to store downloaded packages in a cache, which keeps the image smaller. This is the slowest step in the build, so it’s placed before COPY . . — if Dev changes his code but not his dependencies, Docker reuses this cached layer and skips the pip install entirely.
• COPY . . — copies everything else from Dev’s laptop (the app code, the model file) into the container. Because this comes after the RUN pip install layer, changing app.py or model.pkl doesn’t invalidate the pip cache — only changing requirements.txt does.
• CMD ["python", "app.py"] — the command Docker runs when the container starts. The JSON-array syntax (["python", "app.py"]) is the “exec form” — it runs python directly as PID 1, which handles signals (like Ctrl+C) correctly. The alternative shell form (CMD python app.py) wraps it in a shell and can cause signal issues.

This block turns a Python function into a web endpoint that accepts JSON and returns JSON — the bridge between “a model in a script” and “a model that other services can call.”

• from fastapi import FastAPI — imports the web framework. FastAPI is built on top of Starlette (for HTTP handling) and Pydantic (for data validation), which is why the next import matters.
• from pydantic import BaseModel — Pydantic is a data-validation library. By subclassing BaseModel, you declare what the incoming JSON should look like, and FastAPI automatically validates every request against that schema before your code runs.
• class InputData(BaseModel): with feature_1: float and feature_2: float — this tells FastAPI: “Every POST request to this endpoint must include a JSON body with two float fields named feature_1 and feature_2.” If a client sends {"feature_1": "hello"}, FastAPI rejects it with a 422 error before your predict function ever runs — you never have to write manual type checks.
• app = FastAPI() — creates the application instance. All route decorators (@app.post, @app.get) register endpoints on this object.
• @app.post("/predict") — a decorator that registers the predict function as a handler for HTTP POST requests to the URL path /predict. When a client sends POST /predict with a JSON body, FastAPI parses the JSON into an InputData object and passes it as the data parameter.
• features = np.array([[data.feature_1, data.feature_2]]) — converts the two Pydantic-validated floats into a 2-D NumPy array. The double brackets ([[...]]) create a 2-D array (a matrix with one row and two columns), because sklearn’s predict expects a 2-D feature matrix, not a 1-D array.
• prediction = float(features.sum()) — a placeholder. In Dev’s real app, this would be model.predict(features). The float() call converts the NumPy scalar returned by .sum() into a plain Python float so FastAPI can serialize it to JSON.
• return {"prediction": prediction} — FastAPI automatically serializes the returned dict to a JSON response. The client receives {"prediction": 8.6} (or whatever the sum is).

FastAPI also auto-generates an interactive API docs page at /docs (Swagger UI) and a machine-readable schema at /openapi.json — both free, with no extra configuration.

This block solves two problems at once: where the model file lives inside the container, and when the model gets loaded into memory.

• model = None — declares a module-level variable initialized to None. This is the “slot” where the loaded model will live. It starts as None so that if load_model hasn’t run yet, any attempt to call model.predict will fail loudly (AttributeError: 'NoneType' object has no attribute 'predict') instead of silently using stale data.
• @app.on_event("startup") — a FastAPI lifecycle hook that runs load_model exactly once, when the application starts up (before it begins accepting requests). This is the key: the model is loaded a single time into memory, not on every request. For Dev’s recommender, loading the model might take a few seconds (deserializing a large sklearn pipeline); doing that on every prediction would make the API unacceptably slow.
• global model — tells Python that the model being assigned inside load_model refers to the module-level model variable, not a new local variable. Without global, the assignment model = joblib.load(...) would create a local variable that disappears when the function returns, and the module-level model would stay None — a silent bug.
• joblib.load("model.pkl") — deserializes the model from the file model.pkl. Inside the container, this file lives at /app/model.pkl (because the Dockerfile’s WORKDIR /app and COPY model.pkl . put it there). The relative path works because the container’s working directory is /app.
• model.predict([list(payload.values())]) — converts the incoming dict’s values to a list, wraps it in another list (to make it 2-D), and calls sklearn’s predict. If the payload is {"feature_1": 5.1, "feature_2": 3.5}, then list(payload.values()) is [5.1, 3.5] and the outer brackets make it [[5.1, 3.5]] — a 1×2 matrix.
• int(prediction[0]) — model.predict returns a NumPy array (even for a single prediction), so prediction[0] extracts the first (and only) element. int() converts the NumPy integer to a plain Python int for JSON serialization.

This is the production-ready Dockerfile — the one Dev’s team uses to ship the recommender. It builds on the first Dockerfile but adds the Uvicorn server and port exposure needed for a live API.

• FROM python:3.11-slim — same slim base image as before. For a model-serving API, this is usually sufficient because the model is already trained — you don’t need compilers or CUDA toolkits at inference time (unless the model framework requires them, e.g., some TensorFlow GPU builds).
• COPY requirements.txt . / RUN pip install -r requirements.txt — same layer-caching pattern as the first Dockerfile. If Dev updates app.py but not requirements.txt, the pip install layer is reused and the rebuild takes seconds instead of minutes.
• COPY model.pkl . / COPY app.py . — copies the serialized model and the FastAPI app into the container separately. Splitting them into two COPY commands (rather than COPY . .) means that if Dev changes app.py but not the model, only the app.py layer is invalidated — the model layer (which could be hundreds of MB) is reused from cache.
• EXPOSE 8000 — documentation, not a security rule. It tells Docker (and anyone reading the Dockerfile) that the container listens on port 8000. It does not actually open the port — that’s what the -p 8000:8000 flag in docker run does. EXPOSE is a hint for orchestration tools (like Docker Compose or Kubernetes) to know which port to forward.
• CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"] — the command that starts the API server:
  • uvicorn — an ASGI server that runs async Python web apps. FastAPI is an ASGI framework, so it needs an ASGI server to run; Uvicorn is the standard choice.
  • app:app — the first app is the module (the file app.py), and the second app is the FastAPI instance (app = FastAPI() inside that file). Uvicorn imports the module and finds the application object.
  • --host 0.0.0.0 — binds to all network interfaces. If you used 127.0.0.1 or localhost, the server would only accept connections from inside the container — Docker’s port forwarding from the host wouldn’t reach it. 0.0.0.0 is the container equivalent of “listen on everything.”
  • --port 8000 — the port Uvicorn listens on inside the container. This matches the EXPOSE 8000 and the -p 8000:8000 in docker run.

This is the client-side test — a script that sends an HTTP request to the containerized API and prints the result. It’s what Dev’s frontend colleagues would run to verify the recommender is working.

• import requests — the requests library is Python’s de-facto HTTP client. It’s not in the standard library, so you’d pip install requests on the machine running this test (not inside the container — the container is the server, this script is the client).
• url = "http://localhost:8000/predict" — the endpoint URL. localhost means “this machine” and 8000 is the host port we mapped with -p 8000:8000. The /predict path matches the @app.post("/predict") decorator in the FastAPI app. From a different machine, you’d replace localhost with the server’s IP or hostname.
• data = {"feature_1": 5.1, "feature_2": 3.5} — a plain Python dict matching the InputData Pydantic model. The keys (feature_1, feature_2) must match the field names in the model; the values must be floats (or float-coercible).
• requests.post(url, json=data) — sends an HTTP POST request. The json=data parameter does two things: (1) serializes the dict to a JSON string ({"feature_1": 5.1, "feature_2": 3.5}), and (2) sets the Content-Type: application/json header so FastAPI knows to parse the body as JSON. Without json=, you’d have to manually serialize and set the header.
• response.json() — parses the JSON response body back into a Python dict. The server returned {"prediction": 8.6}, so response.json() gives {'prediction': 8.6}. If the server returned an error (e.g., 422 for invalid input), response.json() would give you the error detail instead.
• The commented output {'prediction': 8.6} — 5.1 + 3.5 = 8.6, which is what the dummy features.sum() prediction returns. In Dev’s real recommender, this would be a product ID or a ranked list of recommendations.

Docker vs. simpler deployment options — when is a container worth it?

Dev’s engineering team pushed back: “Do we really need Docker for a single model? Can’t we just use a venv or a serverless function?” The answer depends on what you’re optimizing for.

The trap to avoid: reaching for Docker because “that’s what production looks like.” If Dev’s model is a single sklearn model with pure-Python dependencies and the deployment target is one server running the same Linux distribution as his laptop, a venv with a frozen requirements.txt gets him 90% of the way for 5% of the effort. Docker earns its keep when the environment complexity grows — multiple deployment targets, system-level dependencies, or a team that needs to reproduce each other’s setups.

The hybrid most teams land on: start with a venv + frozen requirements for prototyping, add a Dockerfile once the model needs to run on a different machine than the one it was built on, and move to a container registry + orchestration (Kubernetes, ECS, Cloud Run) when you have more than one deployment environment or more than one person deploying.

This is a minimal requirements.txt — the dependency manifest that the Dockerfile’s RUN pip install -r requirements.txt reads. Each line is a package name that pip will install from PyPI.

• fastapi — the web framework that defines the /predict endpoint and auto-generates the /docs testing page.
• uvicorn — the ASGI server that actually runs the FastAPI app. Without this, CMD ["uvicorn", "app:app", ...] in the Dockerfile would fail because the uvicorn executable wouldn’t exist.
• scikit-learn — the ML library used to train and serialize the Iris model. At runtime, it’s needed to deserialize the .pkl file and run model.predict().
• joblib — the serialization library sklearn uses internally. It’s installed automatically as a dependency of scikit-learn, but listing it explicitly documents the dependency and protects against future versions where it might not be auto-installed.
• pandas — used in the predict function to construct a DataFrame from the request inputs, because the model was trained on pandas DataFrames and may expect column names to match.

Note: these are unpinned version specifiers. In a real production setup, Dev would pin exact versions (e.g., scikit-learn==1.3.2) to guarantee reproducibility — the same “works on my machine” guarantee that containers provide at the OS level, pinned requirements provide at the Python-package level.

This is a complete, runnable FastAPI app for the Iris dataset — the same pattern as the recommender, but with real model loading and a simpler input schema.

• model = joblib.load("iris_model.pkl") — loads the model at module level, which means it runs once when the module is imported (i.e., when Uvicorn starts the server). This is simpler than the @app.on_event("startup") approach but has a trade-off: if the model file is missing, the entire app crashes on import, before any request can be handled. The startup event approach at least lets FastAPI start and report a clean error.
• def predict(sepal_l: float, sepal_w: float): — unlike the earlier InputData(BaseModel) approach, this uses FastAPI’s “query parameter” style. FastAPI sees the type hints (float) and automatically parses the incoming request’s query parameters. The client would call something like POST /predict?sepal_l=5.1&sepal_w=3.5. For a production recommender with many features, the Pydantic model approach (JSON body) is cleaner; for a two-parameter demo, this is simpler.
• pd.DataFrame([[sepal_l, sepal_w]], columns=['sepal_length', 'sepal_width']) — constructs a one-row DataFrame with the exact column names the model was trained on. The columns argument is critical: if the model was trained with column names ['sepal_length', 'sepal_width'] and you pass ['sl', 'sw'] instead, some sklearn models will raise a warning or silently fail. This is a form of the same train-serving skew Dev fought in the previous article.
• pred = model.predict(df) — runs sklearn’s predict on the DataFrame. Returns a NumPy array of length 1 (one prediction for one row).
• int(pred[0]) — extracts the single prediction (an integer species code: 0, 1, or 2 for the three Iris species) and converts it from a NumPy integer to a plain Python int for JSON serialization. Without int(), FastAPI might struggle to serialize a NumPy int64 in some configurations.
• return {"species_code": int(pred[0])} — FastAPI wraps this dict as a JSON response: {"species_code": 1}.