Every other pitch deck I see this year includes “MLOps” somewhere on the roadmap. Platform teams want to build ML infrastructure. Data science teams want self-service model deployment. VPs want dashboards showing model performance in production.
Almost none of them are ready for any of it.
I say this as someone who has watched ML projects go sideways in multiple organizations. I keep seeing the same pattern. A data science team trains a model in a notebook. It works great in evaluation. Someone manually deploys it. It slowly degrades over months because nobody is monitoring whether the real world still looks like the training data. Eventually a stakeholder notices the predictions are garbage and the team scrambles to retrain.
That’s not an MLOps problem. That’s a “we don’t even have the basics” problem.
What MLOps actually requires
ML systems aren’t just model files. They are data pipelines, training code, feature stores, serving infrastructure, and monitoring – all tightly coupled in ways that traditional software isn’t. A code change might not matter. A data distribution shift always matters. The output is probabilistic. Degradation is silent.
MLOps is the discipline that keeps this entire system reliable. But discipline implies prerequisites.
Can your team reproduce a model from six months ago? Not just the code – the exact dataset, the feature definitions, the hyperparameters, the environment? If no, you’re not ready for MLOps. You’re ready for version control.
Can you answer “what data was this model trained on?” If that question requires someone to check their memory or dig through a shared drive, you’re not ready for automated retraining pipelines. You’re ready for data documentation.
Can you tell when a model’s predictions are getting worse? Not when a stakeholder complains – when the drift actually starts? If you have no monitoring on prediction distributions or feature distributions, you’re not ready for canary deployments of models. You’re ready for basic observability.
The honest starting point
Here is what I tell teams who want MLOps:
Pick your single most important model. The one that actually affects revenue or user experience. Write down its data dependencies. All of them. Where does the training data come from? Who owns those sources? What happens if a schema changes upstream?
Then add three things:
Dataset versioning. When you train, snapshot the data. Tag it. Store it alongside the model artifact. You need to be able to say “model v7 was trained on dataset snapshot X from date Y.”
A release checklist. Before a model goes to production, someone checks it against a known baseline on held-out data. Latency and memory usage are within serving targets. Known edge cases are tested. This is a manual checklist. That’s fine. Manual and consistent beats automated and nonexistent.
One monitoring signal. Pick one metric that reflects whether the model is doing its job in the real world. Not offline accuracy – something tied to a business outcome. Monitor it. Set an alert threshold. When it degrades, retrain.
That’s it. That’s your MLOps v0. It’s not glamorous. It won’t impress anyone at a conference. But it prevents the silent failure mode that kills most ML projects.
When you’re actually ready for more
Once those basics are reliable – and I mean actually reliable, not “we set it up three months ago and haven’t checked since” – then you can start adding automation. Automated retraining triggers. Feature stores. Shadow deployments. A/B testing infrastructure. Model registries with governance controls.
But every layer you add assumes the previous layer works. Automated retraining is useless if your data isn’t versioned. A feature store is overhead if your feature definitions aren’t documented. A/B testing is theater if you can’t measure business outcomes.
The MLOps vendor landscape is exploding right now. Everyone is selling platforms. Most of them solve problems that come after the problems most teams actually have.
Fix the boring stuff first. The tooling can wait.