Inquadrare la scelta: feature parity, controllo e responsabilità operativa

Ogni decisione relazionale in AZ-305 nasce da un requisito, non da una preferenza tecnologica. La prima domanda da porsi è quanto controllo e quanta feature parity con SQL Server on-premises servono davvero, perché è questo asse che separa le tre famiglie PaaS/IaaS.

  • Azure SQL Database (PaaS, database-scoped): massima astrazione operativa, patching e backup gestiti, ma niente SQL Agent, niente cross-database query native, niente CLR/Service Broker. È la scelta di default per applicazioni cloud-native o green-field.
  • SQL Managed Instance (PaaS, instance-scoped): quasi totale compatibilità con SQL Server (SQL Agent, cross-database query, CLR, Database Mail, Service Broker, linked server). È il target ideale per lift-and-shift di carichi legacy che dipendono da feature instance-level.
  • SQL Server su Azure VM (IaaS): controllo pieno su OS e versione di SQL Server, necessario solo quando servono componenti non supportati in PaaS (es. FileStream, PolyBase, versioni molto vecchie) o accesso al file system.

Il pilastro Operational Excellence del Azure Well-Architected Framework spinge sempre verso il livello PaaS più alto compatibile con i requisiti: meno superficie operativa significa meno errore umano e patching automatico.

Scegliere la topologia di Azure SQL Database

Dentro Azure SQL Database, il modello di deployment va dimensionato sul profilo di carico:

  • Single database: workload isolato con risorse dedicate.
  • Elastic pool: molti database con picchi non correlati (tipico SaaS multi-tenant). Ottimizza il Cost Optimization condividendo un budget di risorse (eDTU o vCore) tra database che raramente picchiano insieme.
  • Hyperscale: service tier per database molto grandi (fino a 128 TB), storage disaccoppiato dal compute, backup basati su snapshot quasi istantanei e restore rapido a prescindere dalle dimensioni. Da raccomandare quando la crescita del dato o la velocità di ripristino sono il vincolo dominante. Nota: Hyperscale storicamente non offriva read replica multiple con lo stesso modello degli altri tier — verifica sempre le repliche e i secondari necessari.

Purchasing model e service tier: DTU vs vCore

Il modello DTU raggruppa CPU, memoria e I/O in un’unica metrica pre-confezionata: semplice, prevedibile, adatto a carichi piccoli/stabili dove non si vuole ragionare sui singoli assi. Il modello vCore disaccoppia compute e storage, è l’unico che permette Azure Hybrid Benefit (riuso licenze SQL Server con Software Assurance), reserved capacity a 1/3 anni e il tier Serverless (auto-pause e auto-scale del compute, ideale per dev/test o carichi intermittenti). Per qualunque scenario di ottimizzazione costi enterprise, vCore è la risposta raccomandata, perché è l’unico che abilita le leve di risparmio contrattuali. Managed Instance esiste solo in vCore.

Alta disponibilità e SLA: attenzione alle assunzioni

Questo è il terreno più insidioso. Lo SLA cambia in funzione della ridondanza scelta, non è una costante del prodotto:

  • Locally redundant (default): repliche nella stessa zona; una zona che cade impatta il database.
  • Zone redundant: repliche distribuite su Availability Zone diverse, SLA più alto (fino al 99,995% sui tier idonei). Va abilitato esplicitamente e richiede una regione con AZ.
  • La Business Critical tier offre un gruppo di repliche Always On con una replica leggibile inclusa e latenza minore (storage locale SSD); General Purpose separa compute e storage remoto, più economico ma con failover leggermente più lento.

Per disaster recovery cross-region si usano failover group / active geo-replication, che coprono anche endpoint e listener. Sul pilastro Reliability, la regola è: dichiara l’RTO/RPO richiesto e mappalo su tier + ridondanza + geo-replica, mai assumere HA implicita.

Trappole tipiche d’esame

  • Requisito: migrazione di un’app che usa SQL Agent job, cross-database query e CLR con minime modifiche → raccomanda SQL Managed Instance, non Azure SQL Database (che è database-scoped e non offre queste feature instance-level).
  • Requisito: SLA 99,99%+ resistente al guasto di una zona, budget vincolato → abilita esplicitamente la zone redundancy su un tier idoneo; non dare per scontato che il tier “premium/Business Critical” sia zone-redundant di default.
  • Requisito: database in forte crescita (decine di TB) con restore rapido → scegli il tier Hyperscale, non aumentare semplicemente lo storage di General Purpose, che ha backup/restore più lenti su grandi volumi.
  • Requisito: molti database SaaS con picchi non simultanei e costo aggregato basso → usa un elastic pool anziché single database sovradimensionati; se i picchi fossero costanti e correlati, l’elastic pool non converrebbe.
  • Requisito: riuso di licenze SQL Server esistenti e impegno pluriennale per ridurre i costi → usa il modello vCore con Azure Hybrid Benefit + reserved capacity; il modello DTU non supporta nessuna delle due leve.
  • Requisito: FileStream, PolyBase o accesso al file system del SO → SQL Server su Azure VM (IaaS), perché queste feature non sono disponibili in Managed Instance né in Azure SQL Database.