Forum Discussion
ML Deployment
Hi nbleonhard,
Thank you for sharing your real-world experience. It's interesting to see how moving from a local laptop-based workflow to Microsoft Fabric has improved your machine learning process.
I particularly liked your point about having a dedicated Lakehouse for each ML project. Separating ML workflows from data ingestion while storing reference tables and prediction history in Delta tables seems like a practical approach that also makes collaboration with BI teams much easier.
I have one question based on your implementation. As the number of ML projects grows, how do you manage shared datasets and reusable features across multiple Lakehouses? Do you maintain a centralized feature repository or rely on OneLake shortcuts to avoid data duplication?
Thanks again for sharing your experience—it's always valuable to learn from production implementations rather than just theoretical best practices.
Hi binitafulpagare,
Thanks for reaching out to the Microsoft Fabric Community forum.
We've started following the MLflow-native workflow that Microsoft recommends for Fabric.
Our typical lifecycle looks like this:
OneLake/Lakehouse → Fabric Notebook (Spark) → MLflow Experiment → ML Model Registry → ML Model Endpoint → Monitoring Hub → Fabric Pipeline (scheduled retraining)
- Development: Train models in Fabric notebooks and track every run with MLflow Experiments, which logs parameters, metrics, artifacts, and code versions.
- Deployment: Register the best model in the ML Model Registry and activate a Machine Learning Model Endpoint for real-time inference.
- Monitoring: We use the Monitoring Hub to track experiment runs and monitor endpoint metrics such as request count, error count, latency, and traffic. For business KPIs (accuracy, drift, etc.), we'd typically implement our own monitoring notebooks or pipelines since Fabric's built-in monitoring focuses on experiment and endpoint operations rather than automated drift detection.
- Retraining: Scheduled Fabric Pipelines rerun training notebooks, log the new run to MLflow, evaluate the results, and register a new model version when it meets our acceptance criteria.
- Production MLOps: For enterprise environments, cross-workspace MLflow logging supports Dev → Test → Prod promotion while maintaining separate workspaces and governance.
Microsoft has done a nice job of integrating experimentation, model management, deployment, and monitoring into a single platform, making it possible to implement an end-to-end MLOps workflow without relying on multiple external services.
For more details, please refer to the below offical documentation:
Machine learning experiment - Microsoft Fabric | Microsoft Learn
Serve real-time predictions with ML model endpoints (Preview) - Microsoft Fabric | Microsoft Learn
Monitor machine learning experiments and models - Microsoft Fabric | Microsoft Learn
I hope this helps. Please feel free to reach out if you have any further questions.
Thank you.
Hi v-abhinavmu,
Thank you for the detailed explanation. I really appreciate how you've outlined the complete MLflow-native MLOps workflow in Microsoft Fabric, from model development through deployment, monitoring, and retraining.
I found the integration of MLflow Experiments, the Model Registry, Model Endpoints, Monitoring Hub, and scheduled Fabric Pipelines particularly valuable, as it provides a clear framework for managing the entire machine learning lifecycle within a single platform.
I have one follow-up question. As organizations manage multiple machine learning models across different business domains, what best practices do you recommend for organizing MLflow experiments, model versioning, and the Model Registry to keep everything scalable and easy to maintain? It would be great to understand how enterprise teams typically structure these assets as the number of models grows.
Thank you again for sharing these insights and the official Microsoft Learn resources. I'm looking forward to learning from the experiences of other community members as well.