Machine Learning in Production
Take models from a notebook to a reliable service: pipelines, deployment, monitoring, drift and retraining (MLOps).
- 6lessons
- 3.5 hto read and do
- Advancedlevel
- 6podcast episodes
- 6checked exercises
Tools you'll use in this course
The lessons open these with a template ready. They work for your own job too, no course needed.
About this course
Most models never reach production, and many that do quietly get worse. This course covers the engineering around a model: turning a notebook into steps that run the same way every night, data and feature pipelines that survive late data and don't drift apart between training and serving, experiment tracking and a model registry, batch and online serving with time and latency budgets, monitoring for drift with alerts people act on, safe retraining and rollback, and the documents, owners and approvals that let a business rely on a model.
You take the demand forecast from Data Science and Machine Learning and run it for all 320 Mangrove Market stores every night: about 2.5 million store-product pairs, forecast between the till sync at 23:00 and the distribution centres' 02:00 order cut-off. You build the pipeline as a scheduled DAG in Docker, extract incrementally from the warehouse while offline tills upload late, promote models through a gate and a shadow week, serve the Store app's ordering screen from a fast endpoint, tell a festival rush from a broken price feed, and write the model card the supply chain team signs.
The tools are open-source and vendor-neutral (MLflow-style tracking, an Airflow-, Dagster- or Prefect-style scheduler, FastAPI, Redis, PostgreSQL), with notes on the managed equivalents. Every lesson has auto-checked SQL or JavaScript exercises that run in your browser, a podcast episode, flashcards and practice tasks with model answers.
What you will be able to do
- Turn a notebook into idempotent, scheduled pipeline steps with retries, deadlines and pinned environments
- Build data and feature pipelines that handle late data, validate inputs and avoid training/serving skew
- Track experiments and version data, code and models together, and promote models through a gate
- Serve models in batch and online within time, latency and cost budgets, with safe fallbacks
- Monitor pipelines, data drift and model quality, and retrain or roll back safely
- Document models with model cards and agree ownership, approvals and costs with the business
Syllabus
6 stops, about 3.5 h in total. Each stop fills in when you complete the lesson.
From notebook to pipeline
Tomás's demand forecast beats the baseline, but it lives in a notebook that one person runs by hand. This lesson turns it into a pipeline: small steps with clear inputs and outputs, safe to re-run, scheduled as a DAG with retries and a deadline, packaged in Docker and tested before it ships. Then 320 stores get a forecast every night, whoever is on leave.
MLOpsOrchestrationDocker
Data and feature pipelines
A model in production is only as good as the rows it is fed every night. This lesson shows you how to pull new data from the warehouse while offline tills upload late, stop bad data at a gate before it reaches the model, store features so that training sees exactly what the nightly run saw, and keep the training and serving paths from quietly computing the same feature two different ways.
Data pipelinesMLOpsOrchestration
Experiments, versions and the model registry
A model in production is a chain of choices: code, data, settings, libraries and a random seed. This lesson shows you how to record every link of that chain for every training run, rebuild a run months later, keep models in a registry with versions and aliases, and promote a new version only after it passes a written gate, a shadow week and a sign-off.
Experiment trackingMLOps
Serving: batch and online
A forecast helps nobody until its numbers reach the person or system that makes the decision, in time. This lesson shows you how to score about 10 million predictions inside a 90-minute night window, publish them so nobody ever reads half a run, and answer the Store app's ordering screen in milliseconds from those results, keeping live model calls for the few cases that need them.
Model servingDockerMLOps
Monitoring, drift and retraining
A model that passed every test on the backtest can still go wrong on an ordinary Tuesday, because the world and the data that feed it keep changing. This lesson shows you what to watch at four layers, how to measure drift with PSI, how to tell a festival from a broken feed, and how to retrain and roll back without panic.
MonitoringMLOps
Responsible ML in a business
A model that runs every night is also a business decision that runs every night. This lesson shows you how to write down what the model is for, who owns each part, which changes need a person's approval, whether the people who change its numbers are helping, what it costs against what it earns, how to treat customer data, and how to switch a model off.
MLOpsMonitoring
Capstone: Run the demand forecast every night
A realistic project with a rubric and a model answer.
Final exam and certificate
10 questions drawn at random, 70% to pass.
Capstone project
Run the demand forecast every night
Mangrove's supply chain team has approved the demand forecast after a successful pilot. Put it into production as if for all 320 stores: a nightly pipeline that extracts from the warehouse, validates the data, builds features, predicts 4 days ahead and publishes by 01:30; weekly retraining with tracked runs and a promotion gate; a fast endpoint for the Store app's ordering screen with a latency budget; monitoring with alerts that have owners and runbooks; a rollback that takes minutes; and a model card the supply chain team signs off. Use a public retail sales dataset (for example the M5 competition data) or a synthetic Mangrove dataset, scaled down to run on a laptop, and a simple model; the engineering around it is what is assessed.
You will hand in
- A code repository with the pipeline steps, a schedule (DAG or cron), a Dockerfile and tests, runnable end to end on sample data
- A serving endpoint with a latency budget and a fallback, and the batch publish step
- A monitoring plan or dashboard with metrics, thresholds, owners and runbooks, plus the retraining and rollback procedure
- A model card and a one-page ownership and approval summary
Check what you know
Already know some of this? Answer 6 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 3 minutes and nothing is graded.
Questions
Do I need a cloud account or paid tools?
No. Everything in the course runs on a laptop with Docker and open-source tools: an MLflow-style tracking server, a scheduler, PostgreSQL and Redis. Each lesson notes the managed equivalents in the big clouds if your company uses one.
Which MLOps tools does it use?
It teaches the ideas in a vendor-neutral way and shows them with common open-source tools: MLflow-style tracking and a model registry, an Airflow-, Dagster- or Prefect-style scheduler, FastAPI for serving, and plain SQL checks for data validation. The patterns carry over to whatever your platform uses.
Is this for data scientists or engineers?
Both. Data scientists learn what production needs from their code and models; engineers learn what makes ML different from ordinary services, such as skew, drift, delayed labels and promotion gates.
Do I need to take Data Science and Machine Learning first?
It helps, because this course runs that course's demand forecast in production and assumes you know time-based validation and forecast error. If you already build models, you can start here and look back at those lessons when they are linked.
Is it really free?
Yes. Every lesson, podcast episode, exercise, quiz, final exam and certificate is free. The labs and their templates for real work are free too. Plus and Premium add every lab challenge, weekly extras and a mentor on top, and they never lock the tools or the courses.
How long does it take?
Each lesson shows an honest time for reading and doing. Most people finish a course in two to four weeks at three or four hours a week.
How does the final exam work?
You get 15 questions drawn at random from a larger bank. You need 70% to pass. If you do not pass, you can try again after 24 hours. The exam is graded on the server and you never see the answer key.