# Why and When to Use Kubeflow for MLOps

Ryan Russon, Maven Wave Partners | MLOps Coffee Sessions | Episode 107 | 58:57
Hosted by Mihail Eric

Source: https://www.youtube.com/watch?v=mbwwKf-nz3U
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/why-and-when-to-use-kubeflow-for-mlops
Published: 2022-07-11
Tags: build-vs-buy, model-serving, orchestration, platform-teams

## TL;DR
- Kubeflow is a strong option for teams that already use Kubernetes and want an open, portable MLOps platform.
- Teams without Kubernetes experience should usually start with managed cloud services or simpler tools instead of taking on Kubeflow's operational burden.
- The decision depends on team support, workload demand, desired control, cost, and the engineering effort required to maintain Kubernetes and Kubeflow.

## Summary
Ryan Russon argues that Kubeflow makes sense when a company is already Kubernetes-oriented. It provides notebook-based exploration, pipeline orchestration, and model serving in an open-source environment that can connect to different clouds, storage systems, GPUs, and data services. The trade-off is a difficult operational ramp. Teams need Kubernetes knowledge, platform support, and time to handle networking, security, containers, and upgrades. Mihail Eric and Ryan discuss whether layered abstractions make MLOps easier or hide failures behind too many tools. Ryan sees Kubeflow as one possible long-term direction for larger teams that need control and portability, while managed services and tools such as Metaflow or MLflow may fit smaller or less Kubernetes-focused teams. He also explains why KServe is useful as a separate serving component and why MLflow can complement Kubeflow for tracking and model registration.

## Key ideas
### Kubeflow fits teams that already treat Kubernetes as their platform
[04:43](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=283s)
Ryan says Kubeflow is not the right choice for every team. It works best when a company is already Kubernetes-oriented because Kubeflow was built for Kubernetes and can expose its capabilities to data scientists through tools such as the Python DSL. Small teams that adopt it without understanding Kubernetes can end up with a difficult system they do not know how to operate. The initial question should be whether Kubernetes solves an existing problem for the team, rather than whether Kubeflow is fashionable.

### Kubeflow combines cloud-style MLOps functions with open-source portability
[06:30](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=390s)
Ryan places Kubeflow alongside Vertex AI, SageMaker, and Azure ML in the MLOps ecosystem. It offers exploration, pipeline orchestration, and serving, while allowing teams to avoid committing fully to one cloud vendor. He gives examples of connecting different backends and environments, including S3, GCS, BigQuery, and local GPUs. This flexibility can let a team move between clouds without changing the full experience used by its data scientists. The cost is that the open-source platform is still less mature and requires more of the team to be managed directly.

### Kubeflow's reduced hype reflects both maturity and Google's managed-cloud strategy
[12:23](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=743s)
Ryan agrees with Mihail Eric that Kubeflow received more attention a few years earlier. He links this partly to its origins in Google's work around TensorFlow Extended on Kubernetes and to Google's earlier promotion of the project. He says Vertex AI uses Kubeflow Pipelines under the hood, while the open-source project and Google's managed direction have developed in parallel. As Google puts more emphasis on Vertex AI, other companies and communities have taken a larger role in advancing the open-source side. The lower hype may also mean that larger data organizations are using Kubeflow as a mature product rather than discussing it as a new one.

### The Kubernetes learning curve makes Kubeflow a poor first step for many teams
[15:35](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=935s)
Ryan says a full Kubeflow installation can overwhelm a laptop and that the production path is not straightforward. Teams need someone who understands Kubernetes or a platform group that can support it. Security and networking create practical problems, including restrictions on running sidecar containers as root. Lightweight ways to begin exist, such as local Kubernetes environments and guides for EKS, GKE, or Canonical's MicroK8s, but Ryan does not consider these full production solutions. The benefits become visible after the Kubernetes hurdle, yet smaller teams still have to decide whether they can afford the effort.

### Abstraction layers help adoption until they hide the system underneath
[18:34](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=1114s)
Ryan expects more wrappers around Kubernetes and Kubeflow because abstractions can make infrastructure usable by more teams. Kubeflow Pipelines itself runs on Argo Workflows, which is already an abstraction over Kubernetes. He also warns that too many layers can hide the source of an error and take users too far away from the system they need to control. For experiments and smaller workloads, the layers may be useful. Teams using Kubeflow for production training or KServe for production serving still need to understand the underlying stack.

### Argo can fit platform teams while Kubeflow Pipelines fits the Kubernetes MLOps layer
[23:23](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=1403s)
Ryan explains that Argo Workflows often feels more natural to SRE and DevOps teams, while Kubeflow is aimed more directly at data scientists and machine learning engineers. Kubeflow Pipelines makes it easier to assemble containerized steps, including data processing, Spark, and GPU workloads, in one Kubernetes environment. Argo can require more YAML, but platform teams may prefer it because it matches their existing practices. The choice depends on who operates the platform and whether the organization wants Kubernetes-native control or a simpler interface for practitioners.

### Kubeflow can be a long-term option, but it is not an easy citizen-data-science endpoint
[25:22](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=1522s)
Mihail Eric asks whether Kubeflow is an end state for citizen data scientists, who may not want to inspect pods or use kubectl. Ryan says there may be no final end state, and Kubeflow is not for the faint of heart. He compares it with Metaflow, which lets users add decorators to existing functions and has added Kubernetes support. For a Kubernetes-focused company, Kubeflow can still be the better direction because it offers flexibility across clouds. Smaller or less Kubernetes-oriented teams may be better served by managed offerings or simpler tools.

### KServe is strongest when serving is separated from training and orchestration
[32:31](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=1951s)
Ryan is positive about KServe becoming a standalone project under the Kubeflow umbrella. He argues that model serving should run in a separate environment from model building and training, often on a different cluster. KServe lets teams choose a serving component without adopting every part of Kubeflow. Ryan sees this separation as a sensible architectural direction and says KServe makes it easier to use serving tools that have been built around Kubernetes.

### The Kubeflow decision should include people and operating costs
[36:32](https://www.youtube.com/watch?v=mbwwKf-nz3U&t=2192s)
Ryan says the choice between a managed service and Kubernetes-based Kubeflow depends on team size, workload demand, and the amount of control required. Frequent training or serving and a need for fine-grained scaling can justify more control. Cost also matters, since managed services add service fees while self-managed Kubernetes consumes engineering time. Ryan agrees with Mihail Eric that teams must count the people needed to maintain Kubeflow and Kubernetes. If there is no platform support, someone may become the de facto Kubernetes operator, creating a fragile dependency when that person leaves.

## Notable quotes
- Ryan Russon: "Kubeflow is not the right choice for everybody." (04:43)
- Ryan Russon: "It gives you the tools to be able to get off the ground with exploration, with orchestration, with serving, in an environment that is customizable too." (07:51)
- Ryan Russon: "If your team is not Kubernetes forward, there are better options definitely." (35:54)
- Ryan Russon: "Kubeflow is not for the faint of heart." (26:37)
- Mihail Eric: "Don't forget about the engineer cost and the actual resources you need to pay people to do this." (41:42)

## Tools & references mentioned
- Kubernetes
- Kubeflow
- Vertex AI
- SageMaker
- Azure ML
- S3
- GCS
- BigQuery
- TensorFlow Extended
- KServe
- Argo Workflows
- MicroK8s
- MLflow
- Metaflow
- Airflow
- Prefect
- Databricks
- Maven Wave Partners
- Google

## Who should watch
- Your team already runs Kubernetes and you are deciding whether Kubeflow can provide a portable platform for exploration, orchestration, and serving.
- You are considering Kubeflow for a small team and need a candid account of the Kubernetes, security, networking, and maintenance work involved.
- You are comparing Kubeflow Pipelines, Argo Workflows, MLflow, Metaflow, and managed cloud services for a growing MLOps setup.

## Editor's note

Ryan Russon says Kubeflow works best when a company is already Kubernetes-oriented, since smaller teams can struggle to operate it. ZenML lets teams write ML workflows as Python pipelines and choose the infrastructure stack separately, so the same pipeline can run on a laptop, Kubernetes, Airflow, or a cloud service. That keeps portability from requiring Kubeflow as the operating burden.

Written by the MLOps Talks editors (the ZenML team), not by the speaker.

## Related talks

- [MLflow vs Kubeflow 2022](https://mlopstalks.com/talks/mlflow-vs-kubeflow-2022) (Byron Allen, Contino, 1:05:40)
- [Kubeflow vs MLflow](https://mlopstalks.com/talks/kubeflow-vs-mlflow) (Byron Allen, Servian, 54:57)
- [2 tools = 90% operational ML](https://mlopstalks.com/talks/2-tools-90-operational-ml) (Michael Del Balso, Tecton & Willem Pienaar, Feast & David Aronchick, Kubeflow, 56:39)
- [Packaging MLOps Tech Neatly for Engineers and Non-engineers](https://mlopstalks.com/talks/packaging-mlops-tech-neatly-for-engineers-and-non-engineers) (Jukka Remes, Haaga-Helia University of Applied Sciences, 8wave AI, 55:31)
- [Declarative MLOps: Streamlining Model Serving on Kubernetes](https://mlopstalks.com/talks/declarative-mlops-streamlining-model-serving-on-kubernetes) (Rahul Parundekar, A.I. Hero, Inc., 58:58)