Azure Machine Learning: Workspaces, Pipelines, and MLOps That Ships

Generative models get the headlines, but the estate still runs on classical ML, the churn model, the demand forecast, the fraud scorer, and those models need a factory, not a notebook. Azure Machine Learning is the factory, and MLOps is the same discipline this series applied to infrastructure, aimed at models.

Workspace and Compute Architecture

The workspace is the governance unit, provisioned by Terraform with the invariants: managed VNet isolation, private endpoints, Entra identities, the attached storage and Key Vault and ACR wired at creation, and diagnostics flowing to the central workspace. Structure follows teams like everything else, workspaces per domain with the registry (below) as the sharing plane, and hub workspace configurations reduce the per team provisioning to the vending pattern. Compute is deliberately boring: compute instances as developer workstations with auto shutdown schedules (the FinOps posts’ first finding in every ML estate is idle GPU instances), compute clusters that scale from zero for training with spot tiers for the interruptible jobs, and serverless compute for teams that should not think about clusters at all. Environments, the Docker plus conda definitions jobs run in, live in the repo and build into ACR through the September registry patterns, because “it trained on my machine” is the same disease as “it works on my machine” with a GPU bill attached.

Pipelines and the Promotion Flow

Training becomes reproducible when it becomes a pipeline: componentized steps (prep, train, evaluate, register) defined in YAML or the SDK, versioned data assets as inputs so every run answers “trained on what”, and MLflow tracking capturing parameters, metrics, and artifacts automatically. The registry is the contract between experimentation and production: models register with their lineage, evaluation gates compare the candidate against the champion on the held out set (the golden set discipline for the third time this week, it generalizes), and promotion is a pipeline stage with the same approvals the DevOps posts put on infrastructure, not a data scientist’s Tuesday afternoon decision. Registries at the tenant level share blessed models and environments across workspaces, which is how the platform team publishes and the product teams consume without copying artifacts around.

Serving and the Second Day

Managed online endpoints serve real time inference with the deployment mechanics this series keeps reusing: multiple deployments behind one endpoint, traffic split by percentage, so the new model takes five percent, metrics judge it, and promotion is a traffic update, blue green for models with instant rollback. Batch endpoints cover the scoring jobs that run nightly against the lake, triggered by the Data Factory and Event Grid machinery from earlier posts. The second day work is monitoring beyond uptime: data drift (are inputs still shaped like training data), prediction drift, and, where ground truth arrives, model quality trends, with the model monitoring feature or your own jobs writing to Log Analytics, alerting when drift crosses thresholds, because models fail silently by design, they keep answering, just increasingly wrongly, and only measurement notices. Close with the retraining loop: drift alert or scheduled cadence triggers the training pipeline, evaluation gates the result, and the endpoint rolls forward, the whole cycle running on the same Git, CI, and approval rails as every deployment in this series, which is the entire thesis of MLOps in one sentence: models are software with data dependencies, and they ship like software.

Cheers
Osama

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.