MLOps in 2025: What’s Changed and What Still Hasn’t

When MLOps emerged as a discipline, it was solving a real problem: models trained in notebooks that nobody knew how to deploy, monitor, or retrain. Five years on, the tooling has matured enormously. Some problems are genuinely solved. Others remain as painful as the day the term was coined.

What’s Actually Better Now

Model serving is commoditised. KServe, BentoML, and Ray Serve all provide production-grade model serving with autoscaling, versioning, and monitoring out of the box. You don’t need to build this anymore. The days of wrapping a model in a Flask app and hoping for the best are over.

Experiment tracking is table stakes. MLflow is mature and widely adopted. Weights & Biases has strong enterprise adoption. Most teams now track experiments as a default — the cultural battle here is mostly won.

Feature stores have found their audience. Feast and Tecton have proven their value for teams doing real-time ML. The pattern is established even if adoption outside large organisations is still limited.

CI/CD for models is understood. The pattern of triggering retraining pipelines from data drift alerts, evaluating against a golden dataset, and gating promotion on quality thresholds is well established. Tools like ZenML and Metaflow make this achievable without a large platform team.

What’s Still Hard

Data quality remains the top cause of model failures. The tooling has improved — Great Expectations, Soda, and Monte Carlo all provide data quality monitoring — but the fundamental problem of garbage in, garbage out hasn’t changed. Most production model failures we investigate trace back to a data problem, not a model problem.

Model monitoring in production is still immature. Detecting data drift and concept drift reliably, without generating alert fatigue, is hard. Most teams either have no monitoring or monitors that cry wolf constantly. The tooling exists but calibrating it for specific use cases requires significant effort.

Reproducibility is still not default. Despite better tooling, we still encounter teams that cannot reproduce a model from six months ago. Pinning datasets, environments, random seeds, and model weights consistently requires discipline that many teams don’t have.

The handoff between data science and engineering is still painful. Data scientists write code in one style; engineers expect another. Models arrive for deployment with hard-coded paths, missing requirements files, and undocumented assumptions. This is fundamentally a cultural and process problem, not a tooling problem.

The LLM Effect on MLOps

LLMs have changed what MLOps means for many teams. When your “model” is an API call to a foundation model, most of the traditional MLOps concerns — training pipelines, feature stores, hardware provisioning — disappear or transform.

What emerges instead:

• Prompt versioning and management — prompts are now a core artifact that needs versioning, testing, and governance
• Evaluation pipelines — LLM output evaluation is different from traditional ML metrics and requires new tooling
• Cost and usage tracking — API costs need the same attention as infrastructure costs
• Fine-tuning pipelines — when fine-tuning is needed, it reintroduces many traditional MLOps concerns

The teams doing this well treat their prompts and evaluation datasets with the same rigour they’d apply to training data and model code.

Recommendations for 2025

If you’re building an MLOps practice today:

1. Start with experiment tracking and model registry — high value, low cost, quick to adopt
2. Invest in data quality monitoring before model monitoring — fix the root cause
3. Use managed serving infrastructure — don’t build your own
4. Establish evaluation datasets early — you can’t improve what you can’t measure
5. For LLM-based systems, treat prompts as code — version them, test them, review them

---

Building or maturing an MLOps practice? Get in touch — we help engineering teams implement ML infrastructure that actually works in production.