MLflow crossed twelve million monthly downloads earlier this year. Kubeflow 1.6 shipped last month with substantial improvements to the pipeline component model. SageMaker, Vertex AI, and Azure Machine Learning have all converged on a recognizable set of MLOps capabilities — feature stores, model registries, monitoring, governance — though the specifics differ across providers. Tecton, Feast, and the open-source feature store ecosystem have continued to mature. Arize, Fiddler, WhyLabs, and a small wave of monitoring specialists have moved from leading-edge to standard-stack components. The 2022 question for ML teams is no longer whether MLOps is worth doing; it’s how aggressively to invest in the platform layer, and what to build versus what to buy.

The honest October 2022 observation is that MLOps as a category has matured into a recognizable enterprise discipline, and the gap between organizations that have a real platform and those that have a collection of one-off scripts is now wide enough to be visible in business outcomes.

What MLOps Is and Isn’t

A useful clarification: MLOps is not just DevOps applied to machine learning. It includes DevOps disciplines (CI/CD, monitoring, automation) but adds concerns that don’t exist in conventional software:

Data and feature management. Models are functions of features; features are derived from data. Both have their own lifecycle (versioning, freshness, lineage) that doesn’t have a clean analog in software engineering.

Experiment tracking. A model isn’t built once and shipped; it’s the result of dozens or hundreds of training runs with different hyperparameters, data slices, and architectures. Tracking which experiment produced what, and being able to reproduce it, is a category of work software engineering doesn’t have.

Model evaluation under shifting conditions. Software either works or it doesn’t, with reasonably stable behavior over time. Models degrade as the world drifts, and detecting that degradation requires evaluation infrastructure that doesn’t exist for software.

Governance and explainability artifacts. Audit trails specific to model decisions — what training data, what features, what version, what was approved by whom — are concerns that don’t apply to software the same way.

The MLOps platform supports these concerns in addition to the conventional software lifecycle.

The 2022 Stack Components

A short tour of the components that have crystallized into recognizable categories:

Experiment tracking and the model registry. MLflow is the de facto open-source default; the cloud platforms have their own (SageMaker, Vertex AI, Azure ML, W&B). Track training runs with their parameters, metrics, and artifacts; promote successful runs to a registered model with versioning.

Feature stores. Tecton (commercial), Feast (open source, maintained by Tecton plus community), Hopsworks, and the cloud-native equivalents (SageMaker Feature Store, Vertex AI Feature Store). Provide a consistent abstraction over feature definitions, online/offline serving, and lineage.

Model serving. SageMaker endpoints, Vertex AI endpoints, KServe (formerly KFServing), Seldon, BentoML, NVIDIA Triton. The category covers real-time, batch, and increasingly serverless serving patterns.

Pipeline orchestration. Airflow (broadly), Kubeflow Pipelines (Kubernetes-native), Metaflow (Netflix-originated, increasingly broadly adopted), Prefect, Dagster. The data and ML pipeline orchestration overlap is real and the choices are converging.

Monitoring and observability. Arize, Fiddler, WhyLabs, Evidently, NannyML. Cover model performance, data drift, prediction drift, fairness, and explainability over time.

Governance and lineage. DataHub, OpenMetadata, Atlan, Collibra. Bring metadata, lineage, and policy together. The overlap with data governance is becoming the normal pattern.

Build vs. Buy in 2022

A few patterns that have emerged for the build/buy decision:

Buy the substrate; build the policy. Most enterprises shouldn’t be building experiment trackers, feature stores, or monitoring backends. They should be choosing them and integrating them. The custom work goes into the policies, conventions, and integrations that make the platform work for the specific organization.

The cloud-native bundles get further every quarter. SageMaker, Vertex AI, and Azure ML have each closed substantial gaps over the past year. For organizations heavily invested in one cloud, the bundled platform plus cloud-native extensions is a defensible default.

Open-source-plus-managed is a real third option. MLflow Tracking + a managed registry, Feast + Tecton’s online store, KServe + a managed Kubernetes platform. Avoids cloud lock-in for the components that benefit from portability, while not requiring the team to operate everything themselves.

Specialized vendors earn their place where they’re better. Monitoring is the clearest example — the specialists (Arize, Fiddler, WhyLabs) currently outperform the bundled offerings on depth and ease of integration. Worth paying for if the use case justifies it.

Where MLOps Is Genuinely Working

A few categories where the discipline has translated into measurable outcomes:

Model deployment time. The time from “trained model” to “in production” used to be weeks or months for most enterprises; mature MLOps programs are getting it to days, sometimes hours. The compounding effect on iteration speed is real.

Reproducibility. A model produced six months ago can actually be reproduced. Audit and regulatory questions get answers. Investigation of past decisions becomes tractable.

Drift detection and response. Models that have started to underperform are detected before customers complain. The retraining or rollback decisions happen with data, not anecdotes.

Cross-team consistency. Multiple teams using the same platform with the same conventions produce models that interoperate, share components, and benefit from shared improvements.

Where It’s Still Hard

Honest accounting of where MLOps disciplines run into friction:

Data freshness and feature consistency. Online/offline feature parity sounds simple and is operationally non-trivial. Skew between training and serving features is a frequent source of subtle production issues.

Drift response is harder than drift detection. Detecting that a model has drifted is a solved problem; deciding what to do about it (retrain, roll back, investigate the underlying data, modify the feature engineering) is a workflow that requires human judgment and explicit playbooks.

Deep learning model lifecycle. The MLOps tooling matured around tabular and classical ML use cases. Deep learning workflows — long training runs, large checkpoints, GPU resource management, distributed training — fit unevenly. The category is closing the gap but it’s not yet uniform.

Cross-functional organization. MLOps platforms span data engineering, ML engineering, product engineering, and operations. The organizational design question — who owns what, with what accountability — is harder than the technical question and frequently underestimated.

Cost visibility. ML platforms accumulate cost in places that aren’t obvious — idle endpoints, oversized training instances, feature stores with redundant data, monitoring at high cardinality. FinOps practices for ML are immature relative to general cloud FinOps.

Practical Recommendations for 2022

A few patterns the more successful programs are converging on:

Decide on the platform architecture deliberately. Bundled cloud-native, open-source-plus-managed, or best-of-breed. The choice affects the next several years; making it implicitly through tactical decisions is the wrong shape.

Treat the model registry as load-bearing. Models in production must be traceable to the run that produced them, the data that was used, and the approvals that gated promotion. Skipping this leaves the team unable to answer questions that auditors and incident responders are going to ask.

Build evaluation as a first-class capability. Test sets that reflect production conditions, with metrics tied to business outcomes, evaluated automatically on every candidate model. Without this, “the new model is better” is a claim with no evidence.

Instrument for drift before deployment. Adding monitoring after a model is in production is the wrong shape. Adding it at deployment time, with clear thresholds and runbooks, is the right shape.

Standardize the deployment pipeline across teams. Multiple ML teams each with their own deployment approach produces operational chaos and an inability to share learnings. A single pipeline pattern, with extension points for legitimate variation, scales better.

What’s Worth Watching Through Year-End 2022

A few directions visible from this vantage point:

Feature stores will continue to consolidate. The category had a wave of vendors; the survivors will compose well with the warehouse-centric data stacks most enterprises are running.

Vector databases (Pinecone, Weaviate, Milvus, Chroma) are emerging as a related category, particularly relevant for embedding-based ML applications. The MLOps stack will need to absorb them.

Monitoring will deepen on the LLM and embedding side. The current generation of monitoring tools is strongest on classical ML metrics; LLM-specific monitoring (token usage, output quality, prompt drift) is an emerging requirement.

Open-source pipeline frameworks (Metaflow, Prefect, Dagster) will keep gaining ground against Airflow for ML-specific workflows. The opinionated abstractions fit ML patterns better than Airflow’s general-purpose model.

Conclusion

MLOps in 2022 has matured into a recognizable enterprise discipline with a recognizable stack. For most organizations operating models in production, the right pattern is to invest deliberately in a platform — bundled, composed, or some hybrid — and build the team practices around it consistently. The technology is no longer the bottleneck; the discipline of using it well is. The organizations getting this right are shipping more models, with better quality, with better evidence trails, than they were two years ago, and the gap is widening each quarter.

References

MLflow (2022). MLflow 2.0 Documentation.

Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems.

Treveil, M. et al. (2020). Introducing MLOps. O’Reilly.

Google Cloud (2022). MLOps: Continuous Delivery and Automation Pipelines in Machine Learning.

Tecton (2022). Feature Store Architecture.