Skip to main content

Module 1 — What MLOps solves that classic software development ignores

A trained model that works on Monday can be silently wrong on Friday, without a single line of code having changed. That single sentence is the reason MLOps exists as a distinct discipline. In this course, we will take the same starting point everyone reaches sooner or later — a Jupyter notebook that predicts churn — and rebuild around it the machinery that turns it into a system.

The running project: telecom churn​

You inherit a notebook, churn.ipynb, from a data scientist who left the team. It loads a CSV of subscribers, engineers a few features, fits a gradient boosting classifier, prints a ROC AUC of 0.87, and pickles the model to disk. The business wants to serve predictions to a customer-retention team by the end of the quarter. The notebook is where every ML project starts. It is not where any of them ends, and this module names what it silently assumes.

Three things ML systems have that classic systems do not​

Data is a dependency. A regular application depends on code and libraries. A machine learning system depends on the exact rows it was trained on. Refit the same notebook next week on the same query and the ROC AUC will move — because a new billing cycle added rows, because a schema migration renamed a column, because someone backfilled contract types. In classical software, the input is a runtime concern; in ML, it is a build-time artifact that must be versioned like code.

Models degrade without being touched. A REST endpoint that returned the right JSON yesterday will return the same JSON tomorrow. A churn model whose training data ended in March 2025 may still return well-formed probabilities in September 2026, but those probabilities can be wrong: promotions changed, competitors launched, seasonality shifted. This is called model degradation — the outputs stay legal, the answers stop being true. Detecting it requires monitoring the world, not just the process.

Experimentation is a first-class activity. Software engineers write code that works. Machine learning engineers try dozens of variants and pick the one that generalizes best. The state of a project is not "the code" — it is a portfolio of runs, each with its parameters, its data slice, its metrics, its artifacts. Without a system to compare them, the team relies on memory and screenshots.

What the notebook is silently missing​

Open churn.ipynb and list what would break if you tried to reproduce its result six months from now on a colleague's laptop:

  • No pinned dependencies. pip install scikit-learn in September 2026 gives a different version than in March, and the boosting library may have changed defaults.
  • No random seed. Every rerun gives a slightly different AUC; you cannot tell a real gain from noise.
  • No record of which CSV was used. The file was overwritten twice since.
  • The model is a pickle on someone's Downloads folder. There is no registry, no version, no way to know if the deployed model matches this file.
  • No way to detect that the training data distribution has already shifted since the notebook was last run.

Each item is one of the next nine modules.

MLOps maturity levels, briefly​

Google's widely cited maturity model describes three levels. Level 0 is the notebook above: manual, ad-hoc, discoveries happen once and cannot be repeated. Level 1 automates the training pipeline: given the same code and data, the same model comes out. Level 2 automates the CI/CD pipeline: a code change triggers retraining, validation, and progressive deployment, without a human on the critical path. Most teams that claim to "do MLOps" sit between 0 and 1. This course brings the churn project to a solid Level 2.

Why not just deploy the notebook​

Because deploying the notebook does not solve any of the problems above — it only hides them. The moment the deployed model returns bad predictions, you have no way to reproduce the training, no way to know what data went in, no way to compare with alternatives, and no way to roll back. MLOps is the practice of making those five actions cheap and routine. The rest of the course does exactly that, one module at a time, on the same churn project.

Summary​

  • ML systems differ from classic software along three axes: data as a dependency, degradation without change, and experimentation as a first-class activity.
  • The starting notebook silently assumes reproducibility, versioning, tracking, deployability and monitoring that it does not provide.
  • MLOps maturity ranges from ad-hoc notebooks (Level 0) to a fully automated CI/CD pipeline for models (Level 2).
  • Every subsequent module in this course adds one brick to the same running churn project.

Next module: reproducibility — pinning every source of randomness and every version so a run today can be replayed six months from now.