What Is MLOps and What Does It Take to Run ML Models in Production?

MLOps is the set of practices and tooling that carries a machine learning model through its whole life — training, deployment, monitoring, and retraining — instead of stopping when the notebook produces a good score. It matters as soon as a model has real users or real decisions attached to it, because the hard problems at that point are no longer about accuracy but about reproducibility, consistency between training and serving, and keeping the system alive as data drifts. A single analyst shipping one internal model can get by with scripts and a cron job; a team running many models against live traffic needs versioning, a registry, deployment pipelines, and monitoring as first-class infrastructure.

Why production ML breaks without MLOps

Most ML failures in production are operational, not mathematical. The model that scored well offline degrades or misbehaves for reasons that have nothing to do with the algorithm:

• Training-serving skew. Features are computed one way in the training pipeline (often in pandas or Spark) and another way at request time (often in a service). The two definitions drift apart, and the model sees inputs it was never trained on.
• No reproducibility. Nobody can say which data, code, and parameters produced the model currently in production, so a regression can't be traced or rolled back.
• Silent drift. Input distributions and user behavior change. Without monitoring, a model keeps returning confident predictions long after it has stopped being right.
• Manual, fragile deployment. Copying artifacts by hand and restarting services doesn't scale past a handful of models and makes rollback risky.

MLOps exists to make these failure modes visible and recoverable rather than surprising.

The core components of an MLOps stack

The lifecycle is usually described as four stages, each with its own tooling category.

Two things cut across all four stages and are where most teams underestimate the work:

Versioning and lineage. Every model should be traceable to the exact data snapshot, feature definitions, code commit, and hyperparameters that produced it. This is what makes rollback and audit possible.

Training-serving consistency. The features used at inference must be computed by the same logic, from the same source, as the features used at training. This is the single most common source of "it worked in the notebook" bugs.

Where feature stores and real-time serving fit

A feature store is the piece of the MLOps stack that addresses training-serving consistency directly. It acts as a central repository for feature data, so the same feature definition is used to build training sets and to serve live requests. Hopsworks describes its feature store as "the backbone of production ML," with sub-millisecond retrieval powered by RonDB, and notes that features can be reused across models — Meta's top 100 features are reportedly used in over 100 models. That reuse is the practical payoff: teams stop rebuilding the same transformations for every model.

Real-time serving is the other half. If a model makes decisions inside a user request — fraud checks, recommendations, credit decisions — the feature lookup has to complete within the request budget. Hopsworks cites SIGMOD 2024 benchmarks showing 10x lower latency than SageMaker and Vertex, and claims an 80% cost reduction from reusing features and streamlining development. Treat those as vendor-reported figures, but the underlying point holds: feature retrieval latency and feature reuse are the two levers that most affect whether real-time ML is economically viable.

For teams working with open table formats, an AI lakehouse layer lets models read directly from Iceberg, Delta, and Hudi tables without migration. Hopsworks reports 9–45x faster reads than Databricks or SageMaker through a Python-native query engine. Again, vendor benchmarks — verify against your own data volumes and query patterns.

A practical adoption path

You don't need the full stack on day one. A sequence that scales:

1. Start with one model and one owner. Get it deployed behind a real endpoint with logging. The goal is a working feedback loop, not a platform.
2. Add experiment tracking and a model registry. Once more than one person trains models, "which run produced this artifact" becomes a daily question. Version artifacts and record lineage.
3. Introduce a feature store when you have a second model. The moment two models need the same transformation, centralizing it prevents skew and duplicated work. This is the natural trigger point.
4. Add monitoring for drift and prediction quality. Watch inputs, outputs, and latency. Set thresholds that page someone.
5. Automate retraining and deployment. Once monitoring is trustworthy, wire it to a pipeline that retrains and redeploys on a schedule or on drift.
6. Govern at scale. Add access control, audit trails, and quota management for GPUs and compute. Hopsworks supports air-gapped, on-premises, and hybrid deployments for teams that need full data control, and offers GPU scheduling with Ray for training and KServe/vLLM for serving.

Choosing tooling: what to weigh

There is no single correct MLOps stack. Decide based on these dimensions:

• Latency requirement. Batch scoring tolerates minutes; real-time personalization or fraud needs sub-millisecond feature retrieval. This alone eliminates many options.
• Existing data formats. If your data already lives in Delta, Iceberg, or Hudi, a platform that reads those formats natively avoids a migration project.
• Deployment model. Cloud-managed is fastest to start; air-gapped or on-premises is required for some regulated and sovereign AI use cases.
• Framework flexibility. Teams using Spark, Flink, pandas, and DuckDB together need a platform that doesn't force a single engine.
• Scale trajectory. A platform that starts small and scales to petabytes avoids a rewrite later.

Hopsworks positions itself across all of these as an "AI lakehouse" combining a feature store, MLOps lifecycle management, and open-format data access in one platform, with a free tier to start building and a demo option. Whether it fits depends on how many of the dimensions above are hard constraints for you.

The short version

MLOps is what turns a model into a system: versioned artifacts, consistent features, automated deployment, and active monitoring. The minimum viable version is one deployed model with logging and a registry entry. The full version is a governed platform where many models share features, retrain automatically, and can be rolled back safely. Most teams should move along that path incrementally, adding the feature store and monitoring when a second model or a real-time requirement makes them necessary — not before.