This article is based on reporting originally published by devclass.com, including interviews with Databricks representatives at the time of the MLflow 1.0 release in June 2019.
MLflow 1.0 Delivered Docker and Windows Support
When MLflow reached its 1.0 milestone in June 2019, it shipped two significant capabilities: Windows support and an experimental CLI command for building Docker images capable of serving MLflow models. Both had been stated targets for the 1.0 release by Databricks co-founder and chief technologist Matei Zaharia, who had previously identified Kubernetes and Windows support as key goals for that milestone.
Windows support arrived as promised. Kubernetes support, however, was not explicitly included in the 1.0 release — though the new Docker image tooling laid important groundwork for it.
Kubernetes Support: Two Distinct Problems
Speaking to Devclass following the 1.0 release, Clemens Mewald, Databricks Director of Product Management, described Kubernetes support as “a top item for the community” and broke the challenge into two distinct dimensions:
- Model deployment on Kubernetes: The most common pattern at the time was to package a trained model into a Docker container and deploy that container onto a Kubernetes cluster. Mewald noted that the new Docker image build feature added in 1.0 directly addressed this use case: “The feature we added to easily build a Docker container from an MLflow model addresses that request.”
- Hosting MLflow itself on Kubernetes: The second dimension involved deploying the MLflow tracking server, the UI, and its supporting components onto a Kubernetes cluster. This was the more substantial piece of work still in progress at the time of the interview.
Community-Driven Pull Request Under Review
Mewald indicated that Databricks was actively collaborating with community contributors on a significant pull request intended to enable full MLflow-on-Kubernetes hosting. “We’re basically reviewing and deciding that the design decisions are sound,” he said, adding that the work was expected to land within the following quarter. He noted that once a contribution is merged to the GitHub repository it becomes immediately available, but is only formally packaged when included in an official release.
Model Registry: The Next Major Priority
Alongside Kubernetes, Mewald identified a model registry as “the most important and biggest piece” the team was prioritising for the following quarter. The motivation was clear: some Databricks customers were already managing hundreds or thousands of models, creating a real operational challenge.
The planned registry would give teams the ability to:
- Register models with human-readable names
- Version models automatically
- Manage the full lifecycle of a model from experimentation through to production
- Integrate with CI/CD systems and enforce approval gates before promoting a model to a new lifecycle stage
“The model registry allows our users to manage the lifecycle and in some cases we’ve seen companies apply as much rigour to this process” as they would to software releases, Mewald explained, citing the integration of approval workflows with CI/CD pipelines as a concrete example.
Multi-Step Workflows on the Longer-Term Roadmap
Looking further ahead, Mewald described plans for expressing multi-step ML workflows natively in MLflow — a capability the company had recently demonstrated. Real-world ML training pipelines are rarely a single step: they typically involve data transformation, model training, evaluation, and potentially further post-processing stages. Databricks intended to give users a structured way to define and orchestrate these steps within MLflow itself. Mewald described this feature as “farther out” and likely to arrive later in 2019.
Context: Why This Mattered for MLOps Practitioners
At the time of this reporting, Kubernetes had already established itself as the dominant platform for containerised workloads, and machine learning teams were increasingly looking to run inference services alongside their other microservices on shared Kubernetes infrastructure. The gap between MLflow’s experiment-tracking capabilities and the operational requirements of production ML deployment was a live pain point. The combination of Docker image tooling, planned Kubernetes hosting support, and a model registry represented a coherent attempt to close that gap — and to position MLflow as a full MLOps platform rather than purely an experiment-tracking tool.
Note: This article reflects the state of MLflow and Databricks’ roadmap as of June 2019. Features described as planned or in-progress may have since been released, modified, or superseded. Refer to the official MLflow documentation and GitHub repository for current capabilities.