The Model Works on My Machine: DevOps and MLOps

Who should read it?

data scientists moving to production work, team leads, and IT partners who wonder why ML is not "just software"

Works on my machine

Somewhere right now, a data science team is presenting a model that predicts churn beautifully on their laptops. A slide shows the accuracy. The executives nod. Six months later the model is still not serving a single real customer, and nobody wants to talk about it.

This is the "works on my machine" problem, and it is the most predictable failure in applied machine learning. The demo proves the math works. Production asks a different question entirely: "Does it work for every user, on any day, under attack, after the world changes?"

DevOps for software, and MLOps for everything that makes machine learning harder than software.

Version control: the boring technology that makes everything else possible

Software teams learned, expensively, that emailing code files around (final_v2_REAL_final.py) ends badly. The solution is a version control system, and the standard is Git. Every developer holds a complete local copy of the codebase, saves changes as commits, and shares them through a server. Parallel lines of development live in branches, and when two people change the same code, Git provides the tools to find and resolve the conflict.

On top of Git, platforms like GitHub, GitLab, and Bitbucket add issue trackers, boards, and access management. Teams should treat these as standard equipment, not luxuries: model code, training scripts, and data pipeline definitions belong under version control exactly like any other software.

One numbering scheme is worth knowing even if you never configure it. Semantic versioning writes versions as MAJOR.MINOR.PATCH (e.g. "1.3.5"). A patch means bug fixes, a minor means new compatible features, and a major bump means breaking changes. The number exists so you know when updating is safe.

CI/CD: from "works on my machine" to "works everywhere"

Continuous integration (CI) automates the moment code lands in the shared main branch: every merge triggers automatic tests. Developers merge often, so the team is always working on a current, tested base, and integration pain is paid in small installments instead of one catastrophic merge week.

Continuous delivery (CD) extends the automation into a functional staging environment where the product can be tried before release; the final step to production stays manual. Continuous deployment automates even that last step: merged, tested code goes live without a human in the loop.

Which level fits depends on risk appetite and product type. For SaaS applications, where users get the newest version by reloading a page, continuous deployment is common and the entire safety burden shifts onto automated tests. For teams that find full automation uncomfortable: human quality gates remain available as configuration, not compromise. Pull requests can require review before merge, so a person, not a pipeline, decides what reaches the main branch.

APIs: how a model becomes part of a product

A trained model sitting in a notebook has the business value of a good idea. It creates value only when the product can call it, and the standard mechanism is an API.

Example

A webshop needs product recommendations. The data science team builds a recommender system and exposes it as an API endpoint: the shop's software sends the customer's last ten purchases, the endpoint returns a ranked recommendation list. In Python, a framework like Flask turns a model into an HTTP service in an afternoon.

The architectural pattern that makes this manageable is the microservice: small, independent services that communicate over defined interfaces. The strategic benefit for a data team is insulation. Your recommender can be written in Python while the webshop is written in Java; neither side needs to know how the other works internally, only what the interface is. When the model needs retraining or replacement, the shop does not change.

For leaders, this is the practical answer to "How does ML get into our product?": as a service behind an interface, owned by the data team, wired into the product like any other component.

Testing: the pyramid and its ML cousin

Software testing is layered, and the layers differ in cost and coverage. At the base: many small unit tests covering individual functions, ideally the whole codebase. Above them: component tests, integration tests, and UI or API tests. At the tip: manual and exploratory tests, which should be needed rarely when the automated layers do their job. The shape is a pyramid, cheap tests at the bottom in large numbers, expensive human testing at the top in small numbers.

Machine learning adds its own test layer: train-test splits. Holding out part of the data exists precisely to catch the two failure modes of a model, underfitting (too simple to capture the pattern) and overfitting (memorizing the training data). A model that passes the notebook test but fails on new data is the ML version of code that compiled but never ran.

Monitoring: the world changes under your model

Tests happen before deployment; monitoring is what happens after, and for ML it is not optional. Three forces degrade a running system:

1. Changed conditions
   1. New products, shifting customer behavior, a new competitor. When the world the model was trained on no longer matches the world it serves, accuracy decays quietly. This is model drift, and it is a when, not an if.
2. Technical failure
   1. Bugs that slipped through testing, infrastructure problems nobody predicted, a data center outage.
3. Attackers
   1. Intrusion attempts and denial-of-service attacks, plus a threat specific to ML. Models have blind spots, and adversaries actively hunt for them, because a discovered blind spot is an exploitable one.

The response is two kinds of monitoring:

1. Technical monitoring
   1. The mature software practice watches whether the system runs: uptime, errors, latency.
2. Model monitoring
   1. The ML addition watches whether the system is still right: prediction quality, data distributions, drift indicators. A model in production is not a finished artifact, it is a hypothesis the world keeps testing, and the team must be ready to re-evaluate and retrain continuously.

MLOps: DevOps plus a first step

DevOps itself is a portmanteau of development and operations: tools, methods, and a culture that closes the historical gap between the people who build software and the people who run it. The goal is faster delivery, better quality, and uneventful operation. Its practical ingredients are the ones above: automated tests feeding CI/CD pipelines, containers that make development and production environments identical, and agile practices that keep the whole lifecycle visible on one board.

MLOps applies this to machine learning (ML). There are 3 steps:

1. Model development:
   1. The familiar process models (the lifecycle, the analytics continuum, CRISP-DM) extended with engineering tooling: version control (Git), automated tests (PyTest), and experiment management (MLflow, which tracks the whole ML lifecycle).
2. App integration:
   1. Wiring the model into its application, typically as an API inside a container.
3. Operations:
   1. Running everything stably in production, with monitoring on both the systems and the models.

The insight

The last two steps are DevOps. The difference is the first step, model development, and the way it changes everything downstream, because a model is never "done" the way a feature is done. Data arrives shifted, accuracy decays, retraining becomes a routine task rather than a project. Organizations that budget for the model but not for its operation have planned for the demo, not for the product.

Key Takeaway

For data team moving a model to production:

1. Put everything (code, training scripts, pipeline definitions) under Git before anything else; nothing else works without it.
2. Add a minimal CI pipeline: automatic tests on every merge, staging before production.
3. Ship the model as an API in a container, and budget monitoring as a permanent role, not a launch task: someone owns drift.

For managers:

• The budgeting question is the operational one. A model costs once to build and forever to run.
• If the second number is missing from the plan, the plan is the demo again.