What is an MLOps platform and what problems does it solve?

What an MLOps platform actually is and why the problems it solves are structural

Strip away the vendor language and an MLOps platform is a system of record plus a system of execution for machine learning work. The system of record answers "what happened": which code commit, which dataset snapshot, which hyperparameters, which environment, which metrics, which person approved the promotion to production. The system of execution answers "do it again": rerun the pipeline, retrain on fresh data, redeploy the artifact, roll back if the new version underperforms. Traditional software already has both — Git and CI/CD. Machine learning broke them, because in ML the code is only one of three inputs that determine behavior. Data and environment are the other two, and neither one lives comfortably in Git.

That three-input problem is the root cause of nearly everything an MLOps platform is built to solve. A model is a function of code × data × environment. Change any one of the three and the output changes. Git versions code beautifully and data catastrophically — a 40 GB parquet directory in a Git repo is a broken repo. So teams without a platform end up with code in Git, data on somebody's S3 bucket with a filename like training_v3_FINAL_use_this.parquet, and environment captured in a requirements.txt that says scikit-learn with no pin. Six months later the model that made a lending decision cannot be reconstructed. That is not a hypothetical inconvenience; in regulated lending, insurance, and healthcare it is a compliance failure.

The second structural problem is the handoff cliff. A data scientist's deliverable is typically a notebook and a pickled model file. A production system needs a service with a health check, a latency budget, structured logging, autoscaling, versioned rollback, and an on-call owner. Someone has to translate between those two artifacts, and in most organizations that translation is a manual rewrite that takes weeks and introduces training-serving skew — the features computed in the notebook are subtly different from the features computed in the production service. The classic example is a scaling parameter fit on the training set at experiment time and then recomputed on live traffic at serving time. The model looks fine in validation and quietly degrades in production because the inputs no longer resemble what it learned from.

The third problem is decay. Software does not rot on its own; a correct function stays correct. Models rot by default, because the world they were fit to keeps moving. Consumer behavior shifts, a competitor changes pricing, a data provider changes a schema, an upstream ETL job starts emitting nulls in a column that was never null during training. Nothing crashes. The service returns 200s. The predictions just get worse, and the business notices in a lagging metric — conversion, fraud loss, churn — long after the damage started. MLOps platforms attack this with drift detection on input distributions, performance monitoring against delayed ground truth, and automated retraining triggers.

The fourth is scale-of-many. One model in production is a project you can manage with discipline and a spreadsheet. Twenty models, each with its own training cadence, its own feature dependencies, its own owner who may have left the company, is an operations problem. The marginal cost of the twenty-first model should be low, and without a platform it is not — it is another bespoke pipeline. This is the same economics that drove teams from hand-rolled deploy scripts to standardized CI/CD a decade earlier, and the adjacent discipline it most resembles is data engineering's shift from cron-triggered scripts to orchestrated DAGs.

It is worth naming what an MLOps platform is *not*, because the category is muddy. It is not an AutoML tool — AutoML picks the model, MLOps runs it. It is not a feature store, though many platforms include or integrate with one. It is not a data warehouse. And it increasingly overlaps with LLMOps, which shares the monitoring and governance concerns but replaces training with prompt versioning, evaluation suites, and retrieval-index management. If your entire production footprint is API calls to a hosted foundation model, most of the training-side machinery is dead weight and you want the evaluation-and-observability half.

The step-by-step process a platform standardizes

The value of a platform is that it turns an ad hoc sequence into a repeatable one with a checkpoint at every step. Here is the loop it enforces, and what specifically goes wrong at each stage when nothing enforces it.

Step one: version the data. Before any training run, the input dataset gets an immutable identifier — a content hash, a snapshot table, or a pointer file committed alongside the code. Tools in the DVC lineage do this by keeping a small .dvc metadata file in Git while the bytes live in object storage. The checkpoint is that a training run records *which* snapshot it consumed, not just "the customers table."

Step two: run the experiment with tracking on. Every run logs parameters, metrics, the code commit, the environment spec, and output artifacts to a tracking server. This is the cheapest possible discipline to adopt — an experiment tracker can be added to an existing training script in a handful of lines — and it is where most teams should start. The payoff is immediate: you can sort a hundred runs by validation metric and see exactly which configuration won, instead of scrolling a Slack thread.

Step three: register the candidate. A model registry takes the winning artifact and gives it a name, a version number, and a stage — staging, production, archived — with optional approval gates on the transitions. This is the governance seam. In a regulated environment, the registry entry is the evidence that a human reviewed the model card before it went live.

Step four: package for serving. The artifact gets wrapped into something deployable — a container with an inference server, an API contract, health endpoints, and dependency pinning. Frameworks in this space generate the service and the image from the trained model rather than asking an engineer to hand-write a Flask app. This step is where training-serving skew gets designed out, by shipping the preprocessing code *inside* the served artifact instead of reimplementing it downstream.

Step five: deploy progressively. Not a big-bang cutover. Shadow the new version against live traffic and compare predictions without acting on them; then canary a small traffic slice; then ramp. Serving layers built for Kubernetes support canary, shadow, and multi-armed-bandit routing natively, which is the difference between a model rollout and a model gamble.

Step six: monitor three separate things. Operational health (latency, error rate, saturation) is ordinary SRE work. Data drift — has the input distribution moved away from training? — is ML-specific and detectable immediately. Model performance against ground truth is the one that matters most and arrives last, because labels are delayed: you learn whether a churn prediction was right in ninety days, whether a fraud flag was right in thirty. Design for that lag rather than pretending it away.

Step seven: close the loop. A drift alert or a performance drop triggers retraining on fresh data, which re-enters at step one. The mature version of this is automated and gated: retrain automatically, but require the challenger to beat the champion on a held-out set before promotion, so a bad data day cannot ship itself into production.

Notice that the diagram has one loop, not a straight line, and that the gate before packaging is a human decision. Teams that automate the arrow from training to production without the gate discover the failure mode the hard way: an upstream schema change produces a model that trains cleanly on garbage and deploys itself.

Costs, timelines, and what adoption realistically takes

Cost splits into three buckets that are easy to conflate: licensing, infrastructure, and human operating time. The third is almost always the largest and almost always the one left out of the comparison spreadsheet.

Licensing spans a wide range because the category does. Fully open-source options — the experiment-tracking and data-versioning tools, the Kubernetes-native orchestrators, the open serving frameworks — have zero license cost and nonzero everything else. Hosted SaaS trackers and registries typically price per seat per month, in the tens of dollars per user for team tiers, with free tiers generous enough for individuals and small projects. Managed end-to-end platforms price higher per seat because they are absorbing operational work. Enterprise AutoML-plus-governance suites price per node or per deployment and land in the enterprise-procurement bracket, with a sales cycle to match. The hyperscaler ML services price on consumption — you pay for the training instances, the endpoint hours, and the storage, which makes them cheap to start and unpredictable at scale.

Infrastructure is where the real money hides. GPU training hours dominate for deep learning; always-on inference endpoints dominate for anything real-time. An idle GPU endpoint held warm for latency reasons bills the same whether it serves ten requests or ten thousand, so the single largest cost lever in most ML budgets is scale-to-zero on low-traffic models and batch inference wherever the use case tolerates it. A recommendation model that scores overnight is dramatically cheaper than one that scores on request, and for a lot of use cases the business difference is nil. Ask that question before you ask which platform.

Human operating time is the bucket that decides open-source-versus-managed. A Kubernetes-native platform is free to license and expensive to run: you need cluster administration, ingress configuration, workflow-engine upgrades, and someone who can debug a pod that is pending because of a taint. Organizations that already have a platform-engineering team absorb this cheaply because the team exists anyway. Organizations without one are effectively hiring an infrastructure engineer to save on a SaaS subscription, which rarely pencils out below roughly a dozen models in production.

Timelines, from experience patterns rather than any published benchmark, tend to stage like this. Experiment tracking alone: days. You add a few lines to a training script and stand up a tracking server, and the team gets value in the first week. Data and pipeline versioning: two to four weeks, because it requires agreeing on where data lives and rewriting training entry points to declare inputs and outputs explicitly. A model registry with real approval gates: another few weeks, and the hard part is organizational — who approves, against what checklist. Full CI/CD for models, with automated retraining and progressive delivery: a quarter or more, and it should not be attempted before the earlier layers are habitual.

The sequencing advice that follows from this is blunt: adopt in that order, and stop when the marginal layer costs more than the pain it removes. A three-person team with two models does not need automated canary rollouts. It needs to be able to reproduce last quarter's model. Buying the full platform first is the most common way to end up with an expensive tool that logs nothing because nobody changed how they work.

One more cost worth budgeting: migration. Tracking data, registries, and pipeline definitions are portable in principle and sticky in practice. Prefer tools whose artifacts are open formats — a model directory with a standard descriptor, a container image, a plain YAML pipeline spec — over ones whose value lives entirely in a proprietary UI. The escape hatch is worth paying a small premium for.

Where teams get this wrong

Buying the platform before the practice. The most expensive failure mode is procurement-led adoption: a large managed platform lands, nobody's daily workflow changes, and a year later the tracking server has four hundred runs from one enthusiastic person and none from anyone else. Tooling encodes a practice; it does not create one. The fix is to start with the cheapest layer that changes behavior — tracking — and make it non-optional for anything that will be shown in a review.

Treating notebooks as the deliverable. Notebooks are excellent for exploration and terrible as production artifacts: hidden state, out-of-order execution, no dependency declaration. Teams that never make the jump from notebook to parameterized script end up rewriting everything at deploy time, which is exactly the handoff cliff the platform was supposed to remove. The practical move is to require that any run headed for the registry executes as a script or a pipeline step, with the notebook kept for analysis.

Monitoring only the endpoint. Uptime dashboards make a decaying model look perfectly healthy. If the only thing being watched is latency and error rate, the platform is functioning as an expensive load balancer. Input drift monitoring should be on from day one because it needs no labels; performance monitoring gets wired up as soon as a ground-truth join is possible, even if the join lands weeks later.

Automating retraining without a champion-challenger gate. Automatic retraining sounds like maturity and is a liability without an acceptance test. A broken upstream job or a seasonal anomaly produces a model that trains successfully and performs badly, and an ungated pipeline promotes it. Every automated retrain needs a held-out evaluation and a rule: the challenger ships only if it beats the incumbent by a defined margin, otherwise it alerts a human and the incumbent stays.

Ignoring the feature layer. A surprising share of "model problems" are feature problems. If training features are computed in a SQL script and serving features are computed in application code, they will diverge, and no amount of model governance catches it. Either serve the exact preprocessing that trained the model, or adopt a feature store so both paths read one definition. This is the single highest-leverage fix for training-serving skew.

Over-indexing on the training half of the lifecycle. The bulk of the total cost of ownership sits after deployment — monitoring, retraining, incident response, and the long tail of models nobody owns anymore. Evaluations that focus entirely on training ergonomics pick tools that make month one pleasant and year two miserable. Ask how the tool handles a model whose author has left the company.

Building a bespoke internal platform too early. Every sufficiently large engineering org contains someone who wants to write the orchestrator. Sometimes that is right — at genuine scale, with genuine constraints, an internal platform assembled from open components is the correct answer. Below that threshold it is a permanent maintenance tax on the two people who understand it. A useful test: if you cannot name three concrete requirements no existing tool satisfies, do not build it.

Skipping the boring governance artifacts. Model cards, data sheets, approval records, and lineage look like bureaucracy right up until an auditor, a customer security review, or an incident post-mortem asks for them. The platform should make producing them a side effect of normal work rather than a separate documentation project, which is the whole argument for gates living in the registry instead of in a wiki.

A decision framework for choosing what to adopt

The right question is never "which platform is best" but "which layer do I need next, and what is my constraint." Three constraints dominate: team size, existing infrastructure, and regulatory exposure.

If your constraint is team size and you are small — under ten practitioners, a handful of models — bias hard toward the lightweight, framework-agnostic layer. A tracking server plus a registry plus a serving framework that containerizes models is enough, costs little, and does not require anyone to become a cluster administrator. Add data versioning when you first fail to reproduce something, which will happen sooner than you expect.

If your constraint is existing infrastructure and you already run Kubernetes, the Kubernetes-native orchestrators become genuinely attractive, because the expensive prerequisite is already paid for. Pipelines-as-DAGs of containers with per-step resource requests is the correct abstraction for heterogeneous workloads — a CPU-bound feature job followed by a GPU training step followed by a light evaluation step — and it composes with the serving layers built for the same substrate. If you do not run Kubernetes, do not adopt it *for* MLOps.

If your constraint is regulatory exposure, invert the usual order: registry and lineage first, convenience second. What matters is that every production prediction can be traced to a model version, that model version to a training run, and that run to a dataset snapshot and an approver. Pick whichever tools make that chain unbreakable and auditable, even if the developer experience is worse than an alternative that cannot produce the chain.

If your constraint is cloud commitment, the hyperscaler ML services are the path of least resistance for infrastructure and the weakest on cross-project governance. The common and reasonable pattern is to use the cloud service for training compute and endpoints while running an independent tracker and registry on top, so the system of record survives a change in cloud strategy.

And if your production surface is foundation-model API calls rather than trained models, most of this reduces to evaluation and observability: versioned prompts, a regression suite of test cases with graded outputs, logging of inputs and outputs, and cost-per-request tracking. The lifecycle shape is the same — version, evaluate, gate, deploy, monitor, iterate — but the training and packaging steps mostly vanish.

Whatever the branch, run the evaluation on your actual workload rather than a demo dataset. Reproducibility problems and cost surprises surface at real data sizes and real traffic shapes, and almost never in a tutorial. Give any candidate a two-week trial with one real model, end to end, and see what breaks.

Related questions

How is MLOps different from DevOps?

DevOps versions code; MLOps versions code, data, and environment together, because all three determine model behavior. MLOps also adds concerns DevOps has no equivalent for: statistical drift monitoring, delayed ground-truth evaluation, and retraining loops. The CI/CD machinery is shared; the failure modes are not.

Do I still need an MLOps platform if I use a cloud ML service?

Usually yes, at least partially. Cloud ML services handle infrastructure — training jobs, endpoints, autoscaling — but are weaker on cross-project experiment tracking, a portable model registry, and governance that spans clouds. Many teams run an independent tracker and registry on top of the cloud's compute.

What is a feature store and do I need one?

A feature store is a shared definition layer so training and serving compute features identically, eliminating training-serving skew. You need one when multiple models reuse the same features or when serving features are computed in a different codebase than training features. One model with self-contained preprocessing does not need it.

How do I monitor a model when labels arrive months later?

Monitor in two tiers. Immediately, track input drift and prediction-distribution shift — both are label-free early warnings. Later, when ground truth lands, join it back and compute true performance. Design the logging so that join is possible: store prediction IDs, inputs, and model version at inference time.

Does any of this apply to LLM applications?

The lifecycle does; the training half mostly does not. Prompts become the versioned artifact, evaluation suites replace validation metrics, retrieval indexes need freshness monitoring, and cost-per-request joins latency as a first-class operational metric. Governance, gating, and progressive rollout carry over unchanged.

FAQ

What is the single biggest problem an MLOps platform solves?

Reproducibility. Everything else — deployment speed, governance, drift response — depends on being able to state exactly what produced a given model and rebuild it on demand. Without a captured link between code commit, dataset snapshot, environment spec, and resulting artifact, every other guarantee is a claim rather than a fact. It is also the cheapest problem to fix, which is why experiment tracking is the near-universal first adoption step.

Should we start with open-source tools or a managed platform?

Start open-source for tracking and versioning, because the adoption cost is near zero and the lock-in is minimal. Move to managed when operational load becomes the bottleneck — typically when you are running enough models that someone is spending meaningful time babysitting infrastructure rather than improving models. The decision is about where your scarce engineering time should go, not about license cost.

How many models in production justify a real platform?

There is no clean threshold, but the inflection usually shows up somewhere between the third and the tenth production model. Below that, discipline plus a tracker covers most of the need. Above it, the per-model marginal cost of bespoke pipelines starts compounding and the platform pays for itself in avoided duplication and faster incident response.

Can an MLOps platform prevent a model from failing in production?

No — it shortens the time to detect and to recover. Drift monitoring surfaces input shift early, progressive rollout limits blast radius, a registry makes rollback a one-command operation, and lineage makes root-cause analysis tractable. Those are meaningful reductions in failure cost, not a guarantee against failure.

What is the most common mistake when adopting one?

Buying capability the team's practice does not yet support. A full end-to-end platform adopted before anyone consistently tracks experiments becomes shelfware. Adopt in lifecycle order — track, version, register, deploy, monitor, automate — and let each layer become habitual before adding the next.

Do these platforms work on-premise?

Many do. The open-source tracking, versioning, packaging, and Kubernetes-native serving components are designed to run wherever you can run containers, including air-gapped environments, which is precisely why regulated industries favor them. Managed SaaS options vary; some offer self-hosted or hybrid deployments, others do not, and that constraint should be checked early rather than after selection.

Sources

• MLflow documentation
• Kubeflow documentation
• DVC documentation
• Seldon Core repository
• BentoML documentation
• Google Cloud: MLOps — continuous delivery and automation pipelines in machine learning
• AWS SageMaker MLOps documentation
• Microsoft Azure Machine Learning MLOps documentation
• Feast feature store documentation
• Evidently AI open-source documentation

Related on PULSE

• [What is LLMOps and how does it differ from MLOps?](/knowledge/ai365)
• [The 10 Best MLOps Platforms in 2027](/knowledge/ai344)
• [What is a feature store and when do you need one?](/knowledge/ai366)
• [How do you detect and respond to model drift in production?](/knowledge/ai367)
• [What does a model registry do and why does governance need one?](/knowledge/ai368)