MLflow is a lightweight tool for tracking experiments and storing metrics, parameters, models, and other artifacts.
2
Kubeflow is a broader machine learning platform built around Kubernetes, which makes it harder for individual data scientists to install and operate.
3
Managed services such as Vertex AI and SageMaker make Kubeflow-style pipelines more approachable by removing much of the infrastructure work.
Summary
Byron Allen and George Pearse revisit MLflow and Kubeflow two years after their earlier discussion. Allen describes MLflow as a lightweight package focused mainly on experiment tracking and artifact storage. Kubeflow is a broader platform for machine learning pipelines and related services, assembled from several components on Kubernetes. Pearse found MLflow easy to add to a Python research project, while Kubeflow required close work with a DevOps team, access to clusters, templated YAML, and lengthy debugging sessions. They discuss Kubeflow's fit for Kubernetes-first companies, the move from KFServing to KServe, and managed platforms such as Vertex AI. They also cover gaps in MLflow around authentication, visual analysis, and enterprise features. In a bonus discussion, Allen and Pearse consider whether a semantic layer could define shared business logic for BI and batch machine learning features.
MLflow tracks experiments while Kubeflow covers a wider machine learning platform
Byron Allen says MLflow and Kubeflow are often compared even though they address different scopes. MLflow is a lightweight Python package that he mainly uses for model tracking. It stores metrics, parameters, models, and other artifacts, including documentation that may be needed in a regulated environment. Kubeflow was built as an end-to-end platform for machine learning and MLOps. Its core feature is pipeline execution, alongside other components assembled into a larger Kubernetes-based system.
MLflow is easier for an individual data scientist to adopt
George Pearse says he moved from TensorBoard to MLflow because comparing runs felt easier and more intuitive. He liked that MLflow was simple, self-contained, and easy to integrate into a research project. He could replace it with tools such as Weights & Biases or TensorBoard because the tools had distinct functions and compatible integrations. By contrast, Pearse found Kubeflow difficult to set up and described it as work that usually requires a data scientist and the DevOps team to debug together.
Kubeflow's setup burden comes from infrastructure access as well as YAML
Pearse says the difficulty was not only his comfort with YAML. Deploying to clusters depended on permissions, restricted access, deployment manifests, and the tools available through his DevOps team. Templated YAML and configuration mappings created many opportunities for small errors that were hard to find later. He also had not found a lightweight Kubeflow installation that would let a team test a few useful features before committing to the full deployment.
Developer experience changes the cost of trying a platform
Allen says MLflow's documentation has not disappointed him, while Kubeflow's documentation has. He connects this to the larger developer experience. A data scientist who must learn Kubernetes and coordinate with another team is investing a large amount of time before knowing whether Kubeflow will be useful. Allen says that effort can create a sunk-cost effect, where an organization keeps investing in a tool because it has already built so much around it. MLflow gives teams a more flexible path because individual parts can be adopted or replaced.
Kubeflow fits Kubernetes-first companies better than most smaller teams
Allen agrees that Kubeflow makes more sense for a Kubernetes-first company. He points to Spotify as an example of a large organization that could build around Kubeflow's earlier multi-tenancy limitations because it had Kubernetes expertise, a central IT team, and enough resources to support the work. He says most companies do not put many models into production unless machine learning is part of their product or they operate in an area such as finance. For those companies, Kubeflow may not match their business, data, and infrastructure strategies.
Serving choices depend on the operating environment
Allen says MLflow can create model endpoints, but he would usually use the model-serving service provided by a cloud platform for cloud-based work. He has used MLflow serving through its REST API, mainly in on-premises settings. The conversation also covers Kubeflow's serving component, which moved from KFServing into KServe. Allen describes serving, along with Kubeflow Pipelines, as one of the more successful parts of the Kubeflow ecosystem, with contributions from Google, Seldon, and others.
Managed platforms remove the infrastructure barrier around Kubeflow
Allen says a managed Kubeflow-style service is a good starting point for teams that are not Kubernetes-first. Vertex AI removes much of the infrastructure and setup work, allowing data scientists to focus on pipelines and data science. He also places Vertex AI alongside SageMaker and other managed services that provide capabilities beyond the original Kubeflow project. In his view, Google made the Kubeflow approach more accessible by moving much of it into a managed platform.
MLflow still has gaps around enterprise use and analysis
Pearse describes using MLflow with Python Lightning for active learning experiments. He tracked training runs, validation and test performance, and AUC across different dataset sizes. After accumulating many experiments, he found it slower and wanted more flexibility in the visual analysis. He prefers conventional analytics tools for exploring relationships among parameters and performance. He also dislikes open-source projects that leave enterprise features such as authentication incomplete in ways that appear to direct users toward a paid service. Allen agrees that authentication and security are major areas of extra work around MLflow.
A shared semantic layer could connect BI definitions with batch ML features
In the bonus discussion, Allen describes a semantic layer as configuration and business logic that defines dimensions and generates SQL against an underlying database. His example uses satellite imagery data, geohash centroids, and an NDWI value, with the semantic layer also able to attach a URL to a feature. Pearse says shared definitions could prevent BI tools and machine learning pipelines from producing different meanings for the same metric. Allen imagines a thicker semantic layer that could support BI and batch feature generation, while acknowledging that dbt is more naturally placed in the transformation part of a data pipeline.
"If you are founded and died in the wool Kubernetes, I do not really think Kubeflow is going to be hard for you."Byron Allen15:53
Who should watch
You are deciding whether to add MLflow or Kubeflow to an existing machine learning platform and need to understand what each tool actually covers.
Your data science team wants experiment tracking without depending on a DevOps team for every setup change.
You are considering Kubeflow for a smaller organization and want to judge whether a managed platform is a better fit than running Kubernetes infrastructure yourself.
