MLOPS FOR ENGINEERS

MLOps for Engineers: From Notebook to a Monitored Model in Production

The habits that turn a notebook into a service you can run, watch and roll back, in order, with the extra rules that apply when the model sits beside a PLC.

By EDWartens engineering team 22 November 2025 Updated 5 October 2026 8 min
MLOps for Engineers: From Notebook to a Monitored Model in Production

MLOps model deployment is the set of habits that turns a model in a notebook into a service that runs, is monitored and can be rolled back: a pinned environment, tracked experiments, a model registry, a repeatable pipeline, a container, drift monitoring and tested releases. On a plant, add one rule: the PLC stays in charge.

“MLOps Zoomcamp 4.1 - Three ways of deploying a model” by DataTalksClub ⬛, 13 min. Played from the creator's own YouTube channel; the video belongs to them.

First decide the deployment shape

In this lesson by DataTalksClub, the three ways of deploying a model are compared: batch, online web service and streaming. It is the right place to start, because the shape you choose decides most of what you build afterwards. Follow along, then check your work against these steps:

  1. Ask one question. How soon after the event does someone need the prediction? Tomorrow morning, within a second of a request, or as each event arrives?
  2. Batch if tomorrow is fine: a scheduled job reads yesterday's data, scores it and writes the results to a table. A daily health score for every pump is a batch job.
  3. Web service if a person or system asks and waits: a small HTTP endpoint takes JSON in and returns a prediction. A quality check an operator requests for one batch is a service.
  4. Streaming if the model must react to each event without being asked: it reads from a message stream and publishes results. Scoring every cycle of a press as it happens is a stream.
  5. Write the sentence down. For three prediction problems in your own organisation, write which shape each needs and the one sentence about timing that decides it. That is the practice task in the free course module this lesson belongs to.

MLOps model deployment, stage by stage

From notebook to a monitored model
From notebook to a monitored model

Pin the environment. A model trained with one version of a library and served with another can give different answers. Record exact package versions in a requirements file, and rebuild the environment from it rather than from memory.

Track every experiment. Log the parameters, metrics, data version and resulting model files of every training run. MLflow is the common open-source choice. The point is that "which model is in production, and why" is answered by a record, not by someone's recollection.

Register the chosen model. The MLflow documentation describes its Model Registry as a centralised model store, set of APIs and UI for managing a model's lifecycle. In practice that means each model has numbered versions, one is marked for production, and rolling back means pointing at the previous version.

Turn the notebook into a pipeline. A notebook run top to bottom by hand is not repeatable. Move the steps into a parameterised script: load, clean, build features, train, evaluate, register. Keep feature engineering in one module that both training and serving import, so the model is never fed features computed a different way in production. That mismatch, called training-serving skew, is one of the commonest reasons a good model disappoints live. Building those inputs from plant signals is covered in data engineering for industrial AI.

Package it in a container. A Docker image holds the code, the pinned libraries and the start command, so it runs the same on your laptop, a test server and a plant machine. The container becomes the unit you version and deploy.

Deploy in the shape you chose. Load the model from the registry at start-up rather than copying a file by hand. For batch jobs, save the inputs beside each prediction, because you will need them for monitoring.

Monitor. Four things, in rising order of difficulty: data quality (missing values, out-of-range readings, stuck sensors), input drift (the distributions the model sees have moved), prediction drift (its outputs have moved), and model quality (its accuracy against real outcomes, once labels arrive). Tools such as Evidently compute these, and a Grafana dashboard makes them visible.

Test and release automatically. Unit tests for feature code, an integration test that sends a real request to the container, linting, and a CI/CD pipeline that builds and releases without a manual copy step.

What changes when the model is on a plant

Most MLOps material assumes a web company. A plant adds constraints that are not optional.

Control stays with the control system. A model's output is advisory unless a formal change says otherwise. If a model is allowed to adjust a setpoint, the PLC enforces the limits and the interlocks are untouched. Safety functions never depend on a model.

The network is segmented. Plants increasingly follow ISA/IEC 62443 (see OT cybersecurity explained), which separates control networks into zones connected by controlled conduits. The model usually runs on an edge server in a zone the site approves, with outbound-only connections, and may have no internet access at all. Plan how images and updates reach it. Edge AI in industrial automation covers the choice between plant-floor and cloud hosting.

Drift has physical causes. A recalibrated transmitter, a new supplier's raw material, a replaced bearing, a change of season or a new product recipe all move the data. Connect monitoring alerts to the plant's own events so an engineer can tell a real fault from a maintenance record.

Labels arrive late and rarely. A failure model may wait months for its next confirmed failure. Monitor inputs and predictions continuously and treat measured accuracy as a slow, periodic check.

Change is managed. A new model version is a change to how the plant is operated, so it goes through the site's management of change procedure like any logic change.

Before a plant model goes live
Before a plant model goes live

A free route to learn it

  1. Machine Learning with Python gives you a model worth deploying, and ends by serving one as an API.
  2. Docker and Containers for Automation Engineers is a beginner course: images, Dockerfiles, registries, Compose stacks and volumes, with plant examples.
  3. MLOps Model Deployment and Monitoring covers the whole pipeline above: MLflow tracking and registry, a pipeline script, batch and web-service deployment in Docker, monitoring with Evidently, PostgreSQL and Grafana, and testing with a GitHub Actions pipeline. Every tool it uses is free.
  4. Industrial Data with Python supplies the plant side: reading Modbus and OPC UA, publishing over MQTT and serving a model to a Node-RED flow.

For where a model fits once it is live, predictive maintenance in Google Colab walks through building one end to end.

Start the courses

All four courses are free in full, with lessons from independent creators credited on each course page, EDWartens notes, a practice task per module and one final assessment of 15 questions. Create a free account to save progress.

The optional EDWartens Certificate of Completion is a small one-off fee, US$8.99 for a beginner course such as Docker and a little more for an intermediate one such as MLOps. Anyone can check it at edwartens.com/verification. It is not a cloud-vendor or tool-vendor certification, and not an accredited qualification.

Take the free course

Questions

What is MLOps in simple terms?

MLOps is the set of practices that gets a machine learning model into use and keeps it working: reproducible environments, tracked experiments, a model registry, automated pipelines, deployment in containers, monitoring and tested releases.

What are the three ways to deploy a model?

Batch scoring on a schedule, an online web service that answers requests, and streaming, where the model reacts to events as they arrive. Which one you need depends on how soon after the event the prediction is required.

What is model drift?

Drift is when the data a live model sees, or the relationship it learnt, moves away from what it was trained on. On a plant it follows recalibrated sensors, new raw materials, seasons and maintenance, so it has to be monitored rather than assumed away.

Do I need Kubernetes to deploy a model?

Not usually on a plant. One container, or a small Docker Compose stack on an industrial PC or server, is often the simpler and safer answer. Orchestration earns its complexity when you run many services across many machines.

Should a machine learning model write to a PLC?

Treat that as a control change. Most plant models start as advisory outputs on SCADA or a dashboard. If a model later adjusts a setpoint, it should do so within limits the PLC enforces, with interlocks untouched and the change approved through management of change.

Sources

Written by the EDWartens engineering team for general education. Product names are trademarks of their owners; mentioning them does not imply endorsement. Prices and terms of other providers were checked on the date shown and can change.