There is a persistent myth that doing MLOps properly requires buying a large, expensive platform. It does not. The core discipline — knowing which model is live, noticing when it degrades, and being able to retrain and redeploy safely — can be built from light, mostly open-source components. What matters is the practice, not the price tag.
What MLOps actually needs to do
Strip away the marketing and MLOps has a small set of jobs. You need to know exactly which version of a model is in production and be able to roll back. You need to track how the model is performing against reality, not just its training scores. You need to notice when incoming data drifts away from what the model learned. And you need a repeatable, tested way to retrain and redeploy. Every one of these can be done with modest tooling.
Versioning: the non-negotiable start
The first thing to get right is a model registry — a record of every model version, how it was trained, and which one is currently serving traffic. Without this, you cannot answer the most basic operational question: what is actually running right now. A lightweight registry, even one built on a simple database and object storage, is enough to make rollbacks safe and audits possible. Fancy tooling adds convenience, not capability.
Monitoring is mostly about asking the right questions
Effective monitoring does not require a specialised platform. It requires deciding what to watch: the distribution of incoming features, the distribution of predictions, and — where you can get it — the actual outcomes to compare against. When any of these shifts meaningfully from the training baseline, something has changed and a human should look. This can be built with the same observability tools your engineering team already uses for software.
The trap teams fall into is watching only system metrics — latency, error rates — and missing that the model is confidently wrong. Model monitoring is about the quality of predictions, not just whether the service is up.
Drift detection without the mystique
Drift detection sounds sophisticated but the core idea is simple: compare the data the model is seeing now to the data it was trained on, and alert when they diverge. There are statistical tests for this, and lightweight libraries that implement them, but the concept is accessible. The value is not in an exotic algorithm; it is in having any alarm at all, because most teams have none and discover drift only when an outcome goes wrong.
Retraining as a controlled pipeline
Retraining should be a deliberate, tested pipeline, not a manual scramble. When drift is detected or on a set schedule, the pipeline pulls fresh data, retrains, evaluates the new model against a fixed test set, and only promotes it if it genuinely improves. Crucially, a new model should never go live just because it is new — it must beat the current one on the evaluation set first. This gate is what keeps automated retraining from quietly making things worse.
The role of CI/CD
Model changes deserve the same discipline as software changes: version control, automated tests, and a deployment pipeline. Much of this can reuse the CI/CD infrastructure your team already runs. Treating a model deployment like a code deployment — reviewed, tested, reversible — removes most of the operational risk without any specialised MLOps product.
When a platform does make sense
To be fair, heavyweight platforms earn their place at scale: many models, many teams, strict compliance needs, or a volume of experiments that lightweight tooling cannot organise. If you are running dozens of models across several teams, the coordination a platform provides is worth paying for. The mistake is buying that complexity before you need it, when a handful of open-source components and good discipline would serve you better and cost far less.
Documentation is part of the system
One thing lightweight setups often neglect is documentation, and it matters more than it seems. A model card that records what the model does, what data it was trained on, its known limitations and how to operate it turns tribal knowledge into something the whole team can rely on. When the person who built the model is on holiday and it starts misbehaving, that record is the difference between a calm fix and a scramble. Good documentation costs little to maintain if written as you go, and it is what makes an MLOps practice survive staff changes.
The minimum that matters
Start with versioning so you know what is live. Add monitoring of prediction quality, not just uptime. Put in a simple drift alarm so degradation is caught early. Make retraining a tested pipeline with a promotion gate. Document each model so the knowledge does not live in one person's head. Wrap it in the CI/CD you already have. That is real MLOps, and none of it requires a large platform — only the decision to treat models as production systems that need care after launch, not artifacts you ship and forget.