MLOps is the practice of getting machine learning models into production and keeping them working. It covers reproducible training, versioning of data and models, deployment, monitoring, retraining and governance. It exists as a separate discipline because a model's behaviour depends on data as well as code, and data changes without anyone editing anything.

Why do so many machine learning projects never reach production?

Rarely because the model was not accurate enough. The usual causes are that no decision was going to change based on the output, that the data available at prediction time differs from the data used in training, that nobody owned the system after the pilot, or that the integration work was larger than the modelling work and was never scoped.

Data drift is a change in the distribution of inputs a model receives compared with what it was trained on: a new customer segment, a changed supplier, a different camera, a modified upstream form. The model still runs and still returns confident predictions, and its accuracy silently degrades because the world it was trained on no longer matches the world it is deployed in.

How often should a model be retrained?

There is no universal interval, and choosing one by calendar is a poor substitute for monitoring. Retrain when monitoring shows drift or degradation, when new labelled data materially improves the training set, or when the business process the model supports changes. Some models need weekly retraining, others run for years unchanged.

What is training-serving skew?

It is the mismatch that occurs when features are computed differently during training and during serving — a different library, a different default for missing values, a subtly different definition. It is one of the most common causes of a model that scored well in testing performing poorly in production, and it is what feature stores exist to prevent.

Do I need Kubernetes to deploy a model?

Usually not, and reaching for it early is a common source of unnecessary complexity. A model behind a small web service on a single machine, or a scheduled batch job writing predictions to a table, serves a large share of real use cases. Add orchestration when scale or reliability requirements genuinely demand it.

MLOps: why models fail after the notebook, and what to do about it

Training a model is the part that gets taught. Getting it to work reliably for years, on data that keeps changing, in a system other people depend on, is the part that decides whether any of it mattered.

What this course sets out to do: show you where machine learning projects actually fail, which is almost never in the modelling, and what practices address each failure.

What this course does not do: set up pipelines. The premium catalogue covers MLflow, Docker, CI/CD for models, feature stores and monitoring hands-on.

What you are about to discover

Course contents

#	Lesson	Main goal	Time
1	Why models never ship	The real failure causes, none of them accuracy	8 min
2	Reproducibility	Versioning data, models and experiments	9 min
3	Deployment patterns	Batch, real-time, edge, and releasing safely	9 min
4	Monitoring	Data quality, drift, delayed labels, retraining	9 min
5	Teams, cost and governance	Who owns what, what it costs, what to document	8 min
6	Recap and FAQ	Synthesis, a maturity checklist, and 12 questions	6 min
7	Quiz and attestation	Validate what you learned with 5 corrected questions	3 min

Is this course for you?

You have a model working in a notebook and no idea what happens next.
You are a software engineer asked to deploy something a data scientist built.
You manage a team and want to know why the pilot never became a product.
You keep hearing "drift", "feature store" and "model registry" and want them precise.

Recommended first: Machine Learning.

What you will be able to do at the end

Name the real reasons projects fail and check for them before starting.
Say what must be versioned for a result to be reproducible six months later.
Choose between batch, real-time and edge serving on evidence.
Release a model without betting the process on it, using shadow and canary patterns.
Design monitoring that catches degradation before users report it.
Explain training-serving skew and why it silently ruins good models.

Estimated time

Around 45 to 55 minutes of reading.

Prerequisites and next steps

Prerequisites: Machine Learning. Any experience of shipping software helps.

Natural continuation:

Cloud AI — the managed platforms that implement much of this
Large Language Models — where the monitoring problem is harder still
Ethics of AI — auditability and accountability

Frequent questions, answered in one line

Is MLOps just DevOps for machine learning?

It borrows heavily and adds a genuine difference: in ordinary software, behaviour changes when someone edits code, whereas a model's behaviour changes when the world changes, with no commit and no deployment. That single difference is why data versioning, drift monitoring and retraining pipelines exist as distinct concerns.

Do I need a platform, or can I do this with scripts?

Scripts and a scheduler take you a remarkably long way, and many production models run exactly that way. Platforms earn their cost when you have many models, many people, or compliance requirements — and adopting one to run a single model is a common way to spend six months building infrastructure instead of value.

Who is supposed to do this work?

In small teams, whoever built the model, which is why it often does not get done. In larger ones the responsibilities split between data scientists, machine learning engineers and platform engineers. The failure mode to avoid is a model handed over with nobody owning it afterwards.

How much does running a model cost?

Less than people fear for batch prediction, and more than they expect for real-time serving at scale, where you pay for capacity you are not always using. The larger hidden cost is usually human: monitoring, investigation and retraining.

Want to build these pipelines rather than read about them?

The premium catalogue covers MLflow, Docker, CI/CD for models, feature stores and production monitoring, with a verifiable certificate after a 40-question examination. Included in every paid plan.

Ready? Start with lesson 1 →

What you are about to discover​

Course contents​

Is this course for you?​

What you will be able to do at the end​

Estimated time​

Prerequisites and next steps​

Frequent questions, answered in one line​