Partire dal requisito, non dal prodotto

Le domande di scenario del DP-300 si risolvono quasi sempre allo stesso modo: si isola il requisito vincolante e si sceglie la piattaforma che lo soddisfa con il minor carico gestionale. L’ordine di preferenza è dall’alto verso il basso — prima Azure SQL Database, poi Azure SQL Managed Instance, e SQL Server su macchina virtuale Azure solo quando serve davvero. Il passing score è 700/1000, e attribuire a una piattaforma una capacità che non possiede è l’errore che l’esame punisce di più.

Azure SQL Database: PaaS a livello di database

È un servizio gestito che espone un database, non un’istanza: nessun sistema operativo, nessun oggetto a livello di istanza e soprattutto nessun SQL Server Agent; mancano anche le query cross-database native e i linked server. La conseguenza operativa è immediata: i task pianificati si fanno con gli elastic job (elastic job agent, target group, credenziali di esecuzione) oppure con Azure Automation o Azure Functions. La scalabilità si governa con il purchasing model (DTU o vCore) e il service tier: General Purpose per il carico ordinario, Business Critical per latenza bassa e repliche locali con una secondaria leggibile, Hyperscale per i volumi di dati grandi.

Quando il carico non sta più in un solo database entra in gioco lo sharding: si partiziona orizzontalmente il dato su più database, tipicamente uno per tenant o per intervallo di chiave, con una shard map che instrada la connessione. È il modello di scale-out del multi-tenant SaaS, e qui l’assenza di query cross-database native pesa, perché l’aggregazione si sposta nell’applicazione. Gli elastic pool sono la risposta complementare sul costo: molti database con picchi non correlati condividono le stesse risorse.

Managed Instance e VM: istanza e sistema operativo

Azure SQL Managed Instance è PaaS a livello di istanza e conserva quasi tutta la superficie di SQL Server: SQL Server Agent, query cross-database, Service Broker, CLR, linked server, Resource Governor. Si distribuisce in una subnet dedicata della VNet ed è la risposta tipica al lift-and-shift di un’applicazione che dipende da queste funzionalità, con backup, patching e alta disponibilità a carico della piattaforma. Le vie di migrazione da conoscere sono Azure Database Migration Service, il Managed Instance link, la replica transazionale e backup/restore.

SQL Server su macchina virtuale Azure è IaaS: è l’unico posto dove si controlla il sistema operativo, si installa software di terze parti e si decide quando applicare le patch. È la scelta obbligata quando il requisito nomina una versione o una edition specifica, oppure un componente che il PaaS non espone. In cambio, backup e recovery model tornano responsabilità del DBA e l’alta disponibilità si costruisce a mano con Always On availability group, Failover Cluster Instance o log shipping.

Arc e Fabric: i due bordi del perimetro

I servizi SQL abilitati per Azure Arc proiettano nel piano di controllo di Azure i SQL Server che vivono altrove: on-premises, in altri cloud, su hardware fisico. Non spostano i dati: portano inventario, gestione centralizzata, valutazione delle configurazioni e integrazione con i servizi di sicurezza e governance di Azure su macchine che restano dove sono. Sono la risposta quando lo scenario chiede visibilità e sicurezza uniformi senza migrazione.

Azure SQL Database in Microsoft Fabric colloca invece un database operazionale dentro Fabric, dove il dato transazionale è disponibile all’analitica senza costruire una pipeline di esportazione. Risolve il divario fra OLTP e analitica; non sostituisce la gestione classica di un database di produzione.

Trappole tipiche d’esame

  • Job notturno pianificato su Azure SQL Database → elastic job (o Azure Automation / Functions): ogni opzione che nomina SQL Server Agent è sbagliata, perché in quel servizio l’Agent non esiste.
  • Applicazione legacy con linked server, CLR o Service Broker → Azure SQL Managed Instance: è il lift-and-shift tipico; Azure SQL Database imporrebbe di riscrivere l’applicazione.
  • Serve una versione o edition specifica, o va installato software sull’host → SQL Server su VM Azure: solo lì si controllano sistema operativo e patching, al prezzo di gestire backup e HA/DR in proprio.
  • Migliaia di database tenant con picchi non correlati → elastic pool, e sharding per crescere: la trappola è proporre una VM più grande o un singolo database sovradimensionato.
  • SQL Server on-premises da inventariare e mettere in sicurezza senza migrarlo → servizi SQL abilitati per Azure Arc: la risposta non è una migrazione né una VM Azure.
  • Query cross-database fra due database dello stesso server logico → non sono native su Azure SQL Database: su Managed Instance lo sono; è la distinzione che l’esame nasconde dietro la parola “server”.