# mlctl and Hydrosphere Open Source MLOps Libraries Demo

Alex Chung, Intuit | Social Good Tech Working Group 2021 | 36:24

Source: https://www.youtube.com/watch?v=muk5NkyGtSQ
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/mlctl-and-hydrosphere-open-source-mlops-libraries-demo
Published: 2021-08-24
Tags: model-serving, monitoring, orchestration, platform-teams

## TL;DR
- mlctl packages data science code into universal containers while provider configuration determines where each job runs.
- mlctl can orchestrate process, training, and deployment stages through Kubeflow Pipelines or Airflow without changing the user's code.
- Hydrosphere combines model deployment, serving, versioning, monitoring, and explainability, with monitoring based on training-data ranges and categories.

## Summary
Alex Chung demonstrates mlctl, a library that gives data scientists and ML engineers templates for processing, training, and deployment code. The code is packaged into universal containers, while platform teams define provider YAML files for infrastructure such as SageMaker, Kubernetes, Azure ML, and Vertex AI. The same workflow can run through Kubeflow Pipelines or Airflow, with metadata, logs, job status, and infrastructure details exposed through the orchestration experience. Andre then presents Hydrosphere from Provectus. Users upload a model, its dependencies, serving script, training data, and metadata through a CLI. Hydrosphere versions models, serves them through HTTP and gRPC, collects inference data, monitors input health and drift, and provides bias analysis and model explainability. The discussion is candid about product focus. Alex recommends concentrating on monitoring and integrating with existing serving tools rather than trying to own the full stack.

## Key ideas
### mlctl separates user code from infrastructure bindings
[00:16](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=16s)
Alex describes a base template with a main function and an adapter module. The adapter handles bindings to the underlying infrastructure for data processing, model training, and deployment jobs. A training example retrieves a data frame, selects columns, trains a scikit-learn decision tree, and saves or logs the resulting model artifact. The build process packages the code into a universal container. The runtime then handles infrastructure-specific requirements, such as the location and format expected by SageMaker, and can also save the artifact to MLflow when that integration is available.

### Provider YAML lets platform teams change engines without changing job code
[02:41](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=161s)
The job template is intended to be universal, while provider YAML files choose the execution engine. A team can use SageMaker for deployment and a Kubernetes job for training. Platform teams provide those infrastructure configurations, and data scientists or ML engineers edit the job YAML with hyperparameters, inputs, outputs, and project information. Alex's example uses a train YAML and a command that starts the job with a selected provider. He says this keeps the user's code separate from the infrastructure where it runs.

### Kubeflow Pipelines turns the mlctl stages into an ordered workflow
[04:22](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=262s)
Alex shows a wrapper around the Kubeflow Pipelines SDK. The workflow loads YAML and input data, then defines process, train, and deploy stages in series. The pipeline DSL compiles to Argo, which runs Kubeflow Pipelines, while each individual step is wrapped in an mlctl universal container. The resulting interface includes visualizations, metadata, and logs. A completed run displays infrastructure details such as the SageMaker instance count, estimated cost, AWS job details, parameters, outputs, and final status.

### The same mlctl workflow runs through Airflow
[08:23](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=503s)
The Airflow example loads the provider YAML so Airflow can synchronize the DAGs, sets default arguments, and uses an mlctl operator that wraps the standard Python operator. The DAG references the process and training code, passes the provider, and defines the same stage ordering as the Kubeflow example. Triggering a DAG creates a job, emits its specification, retrieves status, and outputs the final result. Alex says the user's code remains unchanged while the underlying runtime adapts to the selected infrastructure.

### Hydrosphere packages model production work around an uploaded artifact
[17:27](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=1047s)
Andre describes Hydrosphere as a platform for model deployment, serving, versioning, monitoring, and interpretation. To upload a model, a user supplies the model file, dependency requirements, serving script, training data, and metadata. A CLI command registers the model, and the interface can show multiple versions trained with different data or parameters. Hydrosphere has an SDK as well, although Andre says the CLI is the more common upload path. At this stage, training remains outside the platform, so automatic hooks from training code are not yet available.

### Hydrosphere learns input-health checks from training data
[21:56](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=1316s)
Hydrosphere collects inference data and checks whether inputs remain within the ranges seen during training. For categorical values, it checks whether a category was present in the training data. The interface shows request health and can display individual requests within a group. Users can also add custom monitoring functions that calculate metrics from inputs and outputs. Andre distinguishes the display grouping from batch processing: requests are still processed individually, while the group is used to summarize data health.

### Hydrosphere combines drift, bias, and explainability reports
[25:27](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=1527s)
The drift report compares training and production data through statistics such as mean, median, and variance, alongside visual profiles and statistical tests. Users can inspect drift feature by feature. Bias analysis splits outputs by feature values or numeric buckets, such as age ranges, so teams can compare outcomes across groups. Hydrosphere also includes a UMAP-based projection for examining high-dimensional data and is working on root-cause analysis based on the Anchors algorithm, which explains predictions through predicates and data ranges.

### The product discussion points toward monitoring integrations
[32:47](https://www.youtube.com/watch?v=muk5NkyGtSQ&t=1967s)
Hydrosphere serves models through HTTP and gRPC, provides an SDK, collects inference data, and monitors that data. Alex argues that serving is already crowded and suggests concentrating on model monitoring, especially comparing training baselines with inference data. He recommends integrating with existing tools rather than trying to own the whole stack. Andre says the team is preparing a major release and plans to gather user feedback before deciding where the product should go.

## Notable quotes
- "The infrastructure and where things run should be agnostic and independent from the code." (07:55)
- "The user's code doesn't change but the underlying infrastructure runtimes can be adapted to run anywhere." (10:47)
- "We collect all the inference data, the data that comes for the model in production, and we check it for any anomalies." (21:56)
- "I would look towards integration with existing tools." (32:21)

## Tools & references mentioned
- mlctl
- Hydrosphere
- Intuit
- Provectus
- Kubeflow Pipelines
- Kubeflow
- Airflow
- SageMaker
- Kubernetes
- Azure ML
- Vertex AI
- Spark
- MLflow
- scikit-learn
- Argo
- UMAP
- Anchors

## Who should watch
- You are building an internal ML platform and want data scientists to use one job template across different infrastructure providers.
- Your workflows run in Airflow or Kubeflow Pipelines and you want infrastructure details, logs, metadata, and job status connected to the model stages.
- You are evaluating open-source model monitoring and need input-health, drift, bias, or explainability features alongside model serving.

## Editor's note

Alex Chung shows how mlctl keeps job code unchanged while provider YAML selects whether stages run on SageMaker, Kubernetes, Kubeflow Pipelines, or Airflow. ZenML uses pipelines of Python steps on a configurable stack, so the same pipeline code can run across infrastructure choices. Each run records its steps, inputs, outputs, and code version, which gives teams a trace of what ran.

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

## Related talks

- [SGT Model Deployment Working Group](https://mlopstalks.com/talks/sgt-model-deployment-working-group) (Srivathasan Canchi, Intuit, 46:51)
- [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)
- [Creating MLOps Standards](https://mlopstalks.com/talks/creating-mlops-standards) (Alex Chung, Social Good Technologies & Srivathsan Canchi, Intuit, 47:45)
- [Iceberg, MCP, and MLOps: Bridging the Gaps for Enterprise](https://mlopstalks.com/talks/iceberg-mcp-and-mlops-bridging-the-gaps-for-enterprise) (Caleb Baechtold, Snowflake & Hamza Tahir, ZenML & Simba Khadder, Featureform, 1:02:19)
- [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)