Il primo oggetto che un MLOps engineer crea su Azure Machine Learning è il workspace, e il primo errore tipico è trattarlo come una cartella dentro cui buttare esperimenti. È la risorsa di primo livello del servizio: contiene job, asset e configurazioni, ma soprattutto si porta dietro altre risorse di Azure che qualcuno deve possedere, pagare, mettere in sicurezza e saper ricreare. Datastore e compute target si definiscono subito dopo, e insieme rispondono alle due domande operative di ogni progetto: dove stanno i dati e dove gira il codice.

Il workspace e le risorse che si porta dietro

Creando un workspace devi portare con te altre risorse di Azure; se non gliele fornisci, il servizio le crea. Sono quattro: un Azure Storage account, che ospita artefatti dei job, log e notebook delle compute instance ed è lo storage di default per gli upload; un Azure Key Vault, dove finiscono i segreti che i compute target usano; Azure Application Insights, che raccoglie la diagnostica degli endpoint di inferenza; e un Azure Container Registry, che mette in cache le immagini Docker degli environment personalizzati. Il container registry è l’unico dei quattro a non essere una dipendenza rigida: viene provisionato automaticamente la prima volta che costruisci un’immagine custom, e un workspace che legge solo da registry esterni può esistere senza. Lo storage account, al contrario, ha vincoli: non puoi riusarne uno di tipo BlobStorage, premium o con namespace gerarchico, che restano però collegabili come storage aggiuntivo tramite un datastore.

Non è trivia da manuale: sono le risorse da descrivere nell’infrastruttura come codice, quelle su cui assegnare i ruoli, quelle che decidono se un workspace cancellato è recuperabile. Il workspace ha il soft delete: la cancellazione predefinita avviene in due passi, con una retention di 14 giorni durante i quali puoi recuperare oppure eliminare definitivamente. Attenzione a cosa non sopravvive: run history, modelli, dati, environment, componenti e datastore sono soft-deleted; compute instance, compute cluster, endpoint di inferenza e job in coda sono cancellati sul serio. Il nome non è riutilizzabile finché la retention non scade o non fai il purge, e il flag permanently_delete di SDK e CLI salta la fase intermedia: comodo in dev, rischioso altrove. Un workspace non si sposta fra sottoscrizioni né fra tenant: se serve, si ricrea — ed è il motivo per cui deve nascere da un template. Vale infine la regola un workspace per progetto, il livello a cui si fanno reporting dei costi e isolamento dei dati, mentre le risorse associate si condividono fra workspace.

Datastore: un puntatore allo storage, non lo storage

Un datastore non crea nulla: registra un collegamento a uno storage account già esistente. I tipi supportati in v2 sono Azure Blob, Azure Data Lake Storage Gen2, Azure Files e OneLake di Microsoft Fabric; alcuni datastore di default nascono col workspace, a partire da workspaceblobstore.

La scelta vera è come si autentica, e le famiglie sono due. Identity-based, o credential-less: non si salva alcun segreto e l’accesso avviene con l’identità di chi esegue l’operazione. Credential-based: il datastore conserva una account key, un token SAS o le credenziali di un service principal.

# blob-ds.yml — datastore identity-based: nessun segreto nel repository
$schema: https://azuremlschemas.azureedge.net/latest/azureBlob.schema.json
name: gold_layer
type: azure_blob
account_name: mystorageaccount
container_name: gold
az ml datastore create --file blob-ds.yml

Per un progetto MLOps l’identity-based è il default, per tre ragioni. Un segreto salvato nel datastore va ruotato: se rigeneri le access key dello storage account devi aggiornare ogni datastore che le usava. Il ruolo Reader del workspace può elencare le credenziali dei datastore, quindi un ruolo che sembrava innocuo diventa una via d’accesso ai dati. E l’identity-based è il presupposto per disabilitare del tutto l’accesso con shared key sullo storage account.

Compute: gestito, non gestito, e chi scala a zero

I compute target si dividono in due mondi che gli obiettivi tengono separati: training e inferenza. Sul lato training, il compute gestito da Azure Machine Learning è solo di tre tipi: compute cluster, serverless compute e compute instance. Tutto il resto — VM remote, HDInsight, Databricks, Data Lake Analytics, Kubernetes — è compute unmanaged: lo crei fuori e poi lo attacchi al workspace, con manutenzione e tuning a tuo carico.

La compute instance è una macchina singola per lo sviluppo interattivo, con strumenti già installati: può fare da target per i job, ma non scala. Il suo controllo di costo è l’idle shutdown: fermandola smetti di pagare le ore di calcolo, ma continui a pagare disco, IP pubblico e load balancer. Il compute cluster è singolo o multi-nodo e scala a ogni job sottomesso; qui la regola è secca, min_instances: 0, altrimenti quei nodi restano accesi e fatturati anche a vuoto, e con tier: low_priority usi capacità inutilizzata a costo minore, accettando che il job possa essere interrotto. Il serverless compute, infine, non si crea affatto: il ciclo di vita del calcolo passa ad Azure Machine Learning, ed è l’opzione che la documentazione raccomanda esplicitamente al posto di creare un cluster.

# cluster.yml
$schema: https://azuremlschemas.azureedge.net/latest/amlCompute.schema.json
name: cpu-cluster
type: amlcompute
size: STANDARD_DS3_v2
min_instances: 0
max_instances: 4
idle_time_before_scale_down: 120

Sul lato inferenza i target sono due: gli endpoint di Azure Machine Learning — online gestiti per il tempo reale, batch per lo scoring asincrono, entrambi su compute serverless — e Kubernetes, per carichi on-premises, cloud o edge. Un dettaglio che sfugge: un cluster sceso a zero continua a consumare quota, e per liberarla va eliminato.

Da ricordare per l esame

  • Le risorse associate sono Storage account, Key Vault, Application Insights e Container Registry; solo il container registry è opzionale e nasce quando serve un’immagine custom.
  • Il soft delete del workspace ha una retention di 14 giorni; compute e endpoint di inferenza vengono cancellati subito e non si recuperano.
  • Il datastore collega uno storage esistente, non lo crea: identity-based non salva segreti, credential-based salva account key, SAS o service principal.
  • Il ruolo Reader può leggere le credenziali dei datastore: non trattarlo come una sola lettura innocua.
  • Compute gestito significa cluster, serverless e compute instance; solo il cluster scala a zero, e solo con min_instances: 0. La compute instance si governa con l’idle shutdown.