MLOps in 8 Slides

This is the framing post for the whole day, so it stays at the level of definitions and mental models before any pipeline or tool appears. The single most useful idea to internalize is that MLOps is not a product you install — it's the operational discipline that turns a model from a notebook experiment into a system you can run, monitor, retrain, and trust.

Getting this clear early prevents the most common beginner mistake: believing the job ends when the model scores well. The score is the start of the work, not the finish. Once you see operating the model as the real project, the rest of the day's stages become obvious necessities rather than optional extras.

The core definition: MLOps is the set of practices for taking a machine learning model from a notebook to reliable production and keeping it healthy there over time. It deliberately borrows the proven ideas of DevOps — version control, automation, CI/CD, and monitoring — because those solve the same operational problems. What it adds is everything unique to ML: managing data as a versioned artifact, managing trained models, and confronting the fact that model performance decays as the world changes.

This framing matters because it tells you where MLOps sits. It's not machine learning research and it's not generic infrastructure — it's the bridge between them. The teams that ship reliable ML are usually strong here, not because their models are cleverer, but because their operations are disciplined.

This slide drives home that the notebook is roughly 10% of the real job. A model that scores 0.94 on a validation set is an interesting result, not a product. The remaining 90% is the operational work: packaging the model so it can be served, running it under real load, monitoring its live predictions, retraining it when it drifts, and being able to roll back when a new version turns out worse.

The reframing is important because it resets expectations about where effort goes. Beginners over-invest in squeezing another point of accuracy and under-invest in everything that keeps that accuracy usable in production. MLOps is the name for that under-invested 90%, and it's usually where ML projects actually succeed or fail.

This names the three artifacts you must version, which is the conceptual heart of MLOps: code, data, and the trained model. Code is the training and serving logic. Data is the exact dataset the model saw — not just any dataset, but the specific snapshot. The model is the resulting weights together with the metrics it earned. Lose track of any one of these and you lose the ability to reproduce, debug, or audit your system.

The checklist framing is deliberate. When something goes wrong in production, the question is always 'what produced this?' — and you can only answer it if all three artifacts are pinned. Versioning only the code, the habit carried over from traditional software, is the single most common reason ML results can't be reproduced.

This compare slide is the crux of why ML needs its own ops discipline. In traditional software, behavior is determined by code: the same input yields the same output, failures are loud exceptions, and you can reproduce any state from git alone. In ML, behavior is determined by code AND data AND the trained model, outputs are probabilistic, failures are silent degradation rather than exceptions, and reproducing a result requires the data and model versions too.

Understanding this contrast explains every practice that follows. Data and model versioning exist because behavior depends on them. Monitoring exists because failures are silent. Pipelines and registries exist because reproducibility needs more than git. The whole field is a response to these specific differences from normal software.

This expands the key insight: in ML, behavior lives in the data, not only in the code. A traditional program is fully specified by its source — reproduce the code and you reproduce the behavior. A model's behavior emerges from the data it trained on and the weights that produced, so two runs of identical code on different data snapshots give different models. Version only the code and you've captured a fraction of what determines behavior.

The practical implication is sharp: reproducibility, debugging, and auditing all require the data and model versions alongside the code. This extra coupling between code, data, and model is the fundamental reason MLOps exists as a separate discipline rather than just 'DevOps, but for the ML team.'

The cycle diagram lays out the MLOps lifecycle as a loop, not a line: collect and validate data, train while tracking experiments, package and version the resulting model, deploy it to serve predictions, monitor for drift and performance, and retrain to close the loop back to data. The arrow from monitor back to retrain is the whole point — ML operations are circular because models decay and must be refreshed.

Seeing it as a cycle reframes the goal. You're not building a one-time path to deployment; you're building a loop that can run again and again with minimal human intervention. Every stage in the rest of the day maps onto one node here, and the maturity of an ML team is largely measured by how automated and reliable this loop is.

The code makes reproducibility concrete by showing what a single reproducible run actually is: a tuple of versions. The git SHA pins the code, a data version string pins the exact dataset snapshot, a model version pins the trained weights, and the metrics record how it performed. Reproducibility means capturing all of these together, not just the git SHA.

The load-bearing comment is the last line: reproducibility is the whole tuple. This is the runnable embodiment of the three-artifacts idea. In practice this metadata is what a tracking server or model registry stores for every run, and it's what lets you walk backward from a production prediction to the exact, rebuildable conditions that produced it — the foundation everything else in MLOps depends on.

This compare slide draws a hard line between what MLOps is and the misconceptions it gets confused with. On the real side: versioning code, data, and models; automating retraining and deployment; monitoring drift and quality; and building reproducible pipelines. On the myth side: thinking MLOps is one specific tool or vendor, that a bigger model removes the need for it, that a notebook in production counts, or that deployment is a one-time event.

The distinction matters because each myth leads teams astray. Chasing a single 'MLOps platform' misses that it's a set of practices. Believing a bigger model helps ignores that decay and reproducibility are operational, not modeling, problems. Naming the myths explicitly inoculates you against the most expensive wrong turns.

The closing mental model is the most portable takeaway: a trained model is a perishable artifact, not a finished deliverable. Like food, it has a shelf life — it's freshest at launch and degrades as the world moves. That reframing drives the other rules: ship the pipeline that can produce and refresh the model, not just the weights; if you can't reproduce it you can't trust it; treat monitoring as part of the model rather than an afterthought; and plan for retraining from day one.

Internalizing 'perishable, not permanent' changes how you design from the start. You stop building toward a single deployment and start building the loop that keeps the model fresh. Day 97 picks up exactly here, examining why skipping this discipline quietly costs accuracy, money, and trust.

This wraps the conceptual groundwork for the day. You now have the vocabulary — MLOps, drift, the three artifacts, the lifecycle loop — and the central mental model that a model is perishable and that its behavior lives in code, data, and weights together. That foundation is what makes the next four posts legible rather than a blur of tools.

Day 97 builds directly on this by examining the stakes: why models decay, why ML fails silently, and why reproducibility, automation, and rollback are not nice-to-haves but the difference between an ML system you can trust and one that quietly costs you.