If you work with machine learning, chances are you've lived through this scene: a model with excellent metrics in the notebook, celebrated at the results meeting... that six months later still isn't being used by any real system. It's not bad luck, and it's not an isolated case: it's the fate of most models trained in industry. In this lesson we'll look at what MLOps is, why it exists as a discipline, what it adds on top of classic DevOps, and why the leap from notebook to production is so hard. We'll also meet CineClick, the fictional streaming platform that will accompany us throughout the course as its running example.

1. The crime scene: a model that never made it to production
2. Defining MLOps
3. What MLOps adds on top of classic DevOps
4. The notebook → production gap
5. The hidden technical debt of ML systems
6. Benefits of adopting MLOps
7. CineClick: our motivating example

Picture the data team at CineClick, a subscription streaming platform. A data scientist has trained a model that predicts which subscribers are about to cancel (churn). The model works well in her notebook: good metrics, convincing charts, applause at the demo.

And then the awkward questions begin:

• How do we actually use it? The retention team wants a daily list of at-risk customers. The model lives in a .ipynb on the data scientist's laptop.
• Can you retrain it with this month's data? The original CSV no longer exists; it got overwritten. Nobody knows exactly what data it was trained on.
• Why does it give different results today than yesterday? Nobody pinned random seeds or library versions.
• Who maintains it when the data scientist is on vacation? Silence.

None of these questions is about machine learning. They are all about engineering, process, and operations. That is exactly the gap MLOps exists to fill.

MLOps (Machine Learning Operations) is the set of practices, processes, and tools that get machine learning models into production and keep them running reliably, reproducibly, and auditably over time.

Put another way: MLOps is the discipline that turns an ML experiment into a software product with all the guarantees that implies. It combines three worlds:

• Machine learning: training and evaluating models.
• Software engineering: code that is versioned, tested, packaged, and deployable.
• Operations (Ops): automation, monitoring, incident response.

It's worth stressing what MLOps is not:

• It's not a specific tool (although we'll use several in this course).
• It's not "put the model on a server" and forget about it.
• It's not a one-person role: it's a way of working for the whole team.

A working definition we'll use throughout the course: a model is "in production" when other systems or people depend on its predictions, and the team can retrain it, redeploy it, and keep an eye on it without heroics.

If you come from the software world, you might be thinking: "this already exists, and it's called DevOps". That's a good instinct — in fact MLOps inherits almost everything from DevOps: continuous integration, continuous deployment, infrastructure as code, monitoring. But there is one fundamental difference.

In classic software there is one changing artifact: the code. If the code doesn't change, the system behaves the same tomorrow as it does today.

In an ML system there are three changing, interdependent artifacts:

1. The code (preprocessing, training, serving).
2. The data (constantly changing, and with it the model's behavior).
3. The model (a binary generated from the previous two, with its own version and lifecycle).

This table summarizes the key differences:

The most counterintuitive point for someone coming from software is the third one: an ML system can break without anyone having deployed anything. If CineClick changes its pricing plans, the churn model trained on the old plans will start failing silently, even though its code hasn't been touched in months. This forces continuous monitoring and retraining, something with no direct equivalent in classic DevOps (we'll cover it in depth in module 6).

The figures circulating in the industry vary by study, but they all point in the same direction: a large majority of the models that get trained never reach production, or take months to get there. Why?

The notebook is a wonderful tool for exploring: iterating fast, visualizing, trying out ideas. But everything that makes it good for exploring makes it bad for producing:

• Out-of-order execution: cells can run in any order, so the final state depends on the history of clicks, not on the code as written. Two people with the same notebook can get different results.
• Hidden state: variables defined in cells that were later deleted stay alive in memory. The notebook "works" until you restart the kernel.
• No tests, no modularity: everything is one long script; there are no reusable functions and no automated checks.
• Implicit dependencies: absolute paths to the local disk, libraries installed by hand with no record of versions.
• Unversioned data: the CSV you used may have changed or disappeared.

The result is the so-called notebook → production gap: the work needed to go from "works on my machine" to "works reliably for the business" is usually far greater than the work of training the model. Teams without MLOps practices cross that gap by hand, once, painfully... and can't repeat it.

Important: the answer is not to ban notebooks. They are the right tool for the exploration phase. The problem is staying in them. In module 2 we'll see precisely how to extract the work out of the notebook into structured, reproducible code.

In 2015, a group of Google engineers published a highly influential paper, "Hidden Technical Debt in Machine Learning Systems", whose central idea can be summed up in one sentence: in a real ML system, the model code is a tiny fraction of the total system. Around that small core sits a huge infrastructure for data collection, verification, resource management, serving, monitoring... and that's where the debt piles up.

Explained in our own words, the paper identifies forms of technical debt that only exist in ML systems (or that are far worse in ML):

• Boundary erosion (entanglement): in classic software you can change one module without touching the others if you respect the interfaces. In ML, everything affects everything: changing a feature, adding a column, or tweaking the preprocessing changes the behavior of the whole model. They sum it up as "CACE": Changing Anything Changes Everything.
• Data dependencies: more dangerous than code dependencies because there is no compiler or linter to catch them. If CineClick's billing team renames the payment_method column or changes its possible values, the churn model degrades without a single error being raised.
• Hidden feedback loops: the model influences the world that later generates its data. If CineClick's churn model prompts the retention team to call at-risk customers and many of them stay, the future data will say that "those profiles don't churn"... precisely because the model acted. The model ends up learning from its own consequences.
• Glue code and "pipeline jungles": real ML systems accumulate loose scripts connecting data sources, transformations, and outputs — fragile, with no clear owner.
• Configuration as a second-class citizen: thresholds, feature lists, hyperparameters... often live in notebook cells or in someone's head, unversioned, when they should be treated with the same rigor as code.
• Zombie experiments: code branches with conditionals for old experiments that nobody dares to delete.

The practical lesson: ML debt is invisible in the notebook. It shows up months later, when something needs to change and nobody can predict the consequences. MLOps is, to a large extent, a set of practices for paying down that debt systematically instead of accumulating it.

Adopting MLOps has an upfront cost (tools, processes, learning), so it pays to be clear about what you get in return:

There is one less tangible but equally real benefit: team morale. Data scientists who see their models used in production, generating measurable value, are more motivated than those who pile up notebooks in a drawer.

Throughout the course we'll work with CineClick, a fictional subscription streaming platform (think of a movies-and-series service with monthly plans). Its starting position is deliberately typical:

• The data team has trained a churn prediction model: given a subscriber, estimate the probability that they will cancel soon, using fictional data such as tenure, viewing hours, or support tickets.
• The model lives in a notebook on a data scientist's laptop, with all the problems described in this lesson.
• The business wants to use it for real: retention campaigns targeted at at-risk customers.

Over the six modules we'll turn that notebook into a complete MLOps platform: a reproducible project, tracked experiments, a deployed prediction service, CI/CD automation, and production monitoring. In lesson 01-04 we'll present the project in detail, including the dataset and the initial notebook; for now, keep the big picture: CineClick is at exactly the point where most models die, and our job will be to get it out of there.

• Mistake: thinking MLOps means buying a tool. Tools help, but MLOps is above all process and culture. A team with Git, discipline, and well-organized scripts does better MLOps than one with a very expensive platform and chaotic notebooks.
• Mistake: demonizing notebooks. The notebook is the right tool for exploring. The antipattern is using it as a production environment, not using it at all.
• Mistake: leaving the "move to production" for the end of the project. The notebook → production gap is easier to cross if you think about it from day one: relative paths, pinned seeds, recorded dependencies. Small habits save weeks.
• Mistake: believing a stable ML system needs no maintenance. Unlike classic software, a model degrades even if nobody touches the code, because the world's data changes. Budget for continuous maintenance from the start.
• Tip: when assessing the health of an ML project, don't ask "what metrics does the model have?" — ask "could you retrain and redeploy it tomorrow if needed?". The answer to that question is the most honest MLOps metric there is.

Classify each of these problems as (a) a machine learning problem, (b) a problem that would also exist in classic software (DevOps), or (c) a problem specific to ML systems that MLOps must solve:

1. The model's recall is too low on the minority class.
2. Nobody knows which version of the code is deployed on the server.
3. The model worked well in January, but by June its predictions are much worse, even though nobody changed anything.
4. The prediction service crashes when it receives many simultaneous requests.
5. It's impossible to reproduce the model trained three months ago because the original CSV was overwritten.

In the lesson we saw the CACE concept (Changing Anything Changes Everything) from the ML technical debt paper. Describe a concrete scenario at CineClick where changing something apparently harmless in the input data degrades the churn model without producing any visible error.

Think of a model (real or hypothetical) from your own work that lives in a notebook. Write a list of at least five "what would happen if...?" questions that would expose its operational fragility (use the awkward questions from the first section as inspiration).

Solution 1:

1. (a) — It's a modeling problem: choice of algorithm, class balancing, decision threshold. MLOps doesn't solve it (although it does help detect it and iterate faster).
2. (b) — A classic DevOps problem: lack of deployment traceability. It exists equally in any web application.
3. (c) — Data drift or concept drift: the world changed and the model didn't. This is the quintessential ML-specific problem; it has no equivalent in deterministic software. We'll cover it in module 6.
4. (b) — Service scalability: a classic operations problem, although in ML it has some nuances of its own (we'll see them in module 4).
5. (c) — Missing data versioning: in classic software, versioning the code is enough; in ML, without the exact data you can't reproduce the artifact. We'll solve this with DVC in module 2.

Solution 2 (sample answer):

CineClick's product team decides that the support_tickets field should stop counting tickets resolved automatically by the chatbot and only count those handled by humans. It's a reasonable business change and breaks no schema: the column still exists and is still an integer. But its distribution shifts (values drop sharply), and the churn model — which learned that "lots of tickets" signaled churn risk — starts underestimating the risk of dissatisfied customers. No error, no exception, no alert: just increasingly worse predictions. This illustrates both CACE and the fragility of data dependencies.

Solution 3 (sample answer; yours will depend on your case):

1. What would happen if I had to retrain the model today with new data? Would I know exactly which steps to follow?
2. What would happen if my laptop broke? Would the model and its history survive?
3. What would happen if a colleague ran my notebook top to bottom on their machine? Would they get the same model?
4. What would happen if someone asked me exactly which data the version currently in use was trained on?
5. What would happen if the data source changed a column tomorrow? How would I find out?
6. What would happen if the model started predicting badly? Who would notice first: my team or the business?

If several answers are "I don't know" or "it would be a disaster", you have a perfect candidate for applying what you'll learn in this course.

In this lesson we defined MLOps as the set of practices that turn ML experiments into reliable software products, and we saw why it's necessary: unlike classic software, an ML system has three changing artifacts (code, data, and model), can degrade with nobody touching anything, and accumulates its own forms of technical debt — from CACE entanglement to hidden feedback loops — which Google's hidden debt paper described masterfully. The notebook → production gap isn't crossed with one-off heroics but with repeatable processes, and that is exactly what we'll build for CineClick.

Now that we know why MLOps exists, the next step is understanding what needs to be managed: in the next lesson we'll walk through the complete lifecycle of an ML model in production, from defining the business problem to monitoring and retraining, and we'll see how the three versionable artifacts evolve at different paces along that cycle.