ML in the Enterprise

Knowing the theory is half the exam; the other half is mapping it onto real platforms and operations. For a .NET shop on Azure, two tools dominate the conversation, and one lifecycle governs everything you deploy.

The .NET/Azure toolkit

• ML.NET — Microsoft's open-source ML framework for .NET. You train and consume models in C#, in-process, no Python runtime required. Its AutoML tooling (Model Builder in Visual Studio, the mlnet CLI) tries algorithms and hyperparameters for you and emits a consumable model plus wrapper code. The sweet spot: embedding a classifier or regression model directly inside an ASP.NET Core service — same deployment unit, microsecond scoring, no extra infrastructure. ML.NET can also load ONNX models trained elsewhere.
• Azure Machine Learning — the platform service for the full lifecycle at scale: managed compute for training, a model registry with versioning, managed endpoints for serving, pipelines, and monitoring. Choose Azure ML when you need team-scale MLOps, GPU training, Python-ecosystem models, or governed deployment; choose ML.NET when a .NET app just needs a model inside it. (For vision/speech/language tasks, remember Azure AI services offer pre-trained models via API — often the right answer before training anything.)

Batch vs real-time scoring

Exams and design reviews both test this distinction:

• Batch scoring — score large volumes on a schedule (nightly churn scores for every customer, written back to SQL Server). Cheap, throughput-oriented, latency measured in hours. In Azure ML this is a batch endpoint or pipeline job.
• Real-time scoring — score one item on demand inside a request (fraud check during checkout). Latency-critical, always-on. In Azure ML, a managed online endpoint; with ML.NET, often just an in-process call inside your API.

Default to batch unless the decision genuinely must happen mid-request — it's dramatically cheaper to operate.

The model lifecycle and drift

A model is not a build artifact you ship once; it's a perishable asset. The canonical loop:

1. Train on curated historical data.
2. Register the model with a version, its metrics, and the data it was trained on.
3. Deploy behind an endpoint (or into the app), ideally with staged rollout.
4. Monitor — not just uptime, but prediction quality and input statistics.
5. Retrain when performance decays, and repeat.

Decay is expected, not exceptional, because the world changes under the model — drift. Data drift: input distributions shift (new fraud tactics, post-pandemic demand patterns). Concept drift: the relationship between features and label itself changes. Monitoring compares live input distributions and outcome rates against the training baseline and alerts when they diverge — the trigger for retraining. An architect who deploys a model without a monitoring and retraining plan has shipped a system designed to quietly rot.