Azure SQL Database o SQL Server su una VM? Cosa ho imparato

Quando ho fatto il deploy della Sports Betting API su Azure mi serviva un database dietro, e le opzioni ovvie erano due: Azure SQL Database, il managed service, oppure una virtual machine con SQL Server installato. Entrambi eseguono SQL Server. La differenza sta in tutto ciò che circonda il database, non nel database stesso.

Cosa significa davvero l'opzione VM

Una VM con SQL Server è una macchina mia. Scelgo la dimensione, installo SQL Server, lo configuro, e si comporta esattamente come un SQL Server su qualsiasi altra macchina, perché è quello che è.

Questo vuol dire anche che tutto di quella macchina è mio da gestire. Update dell'operating system, patch di SQL Server, backup, configurare l'high availability, evitare che il disco si riempia. Se esce un security patch, applicarlo è il mio lavoro e il downtime è il mio.

Il vantaggio è il controllo totale. Accesso completo all'instance, qualsiasi feature di SQL Server, qualsiasi configurazione, i job di SQL Server Agent, il file system, le cross-database queries. Se mi serve qualcosa di specifico a livello di instance, c'è.

A cosa rinuncia e cosa restituisce Azure SQL Database

Azure SQL Database è il database as a service. Non ottengo una macchina, ottengo un database, e Azure si occupa dell'operating system, delle patch e degli automated backups.

Il compromesso è che alcune cose non sono più mie. Non c'è SQL Server Agent nella stessa forma, non c'è accesso al file system, non c'è configurazione a livello di instance, e cose come le cross-database queries funzionano in modo diverso o non funzionano affatto. È SQL Server, ma in una versione ridotta.

Perché ho scelto quello managed

Per la mia API la decisione è stata semplice, e non riguardava davvero le feature. Riguardava su cosa volevo effettivamente spendere il mio tempo.

Sto costruendo un'API. Non sono un DBA e non voglio diventare la persona responsabile di applicare le patch a un database server in un progetto di studio. Ogni ora passata a mantenere una VM è un'ora non passata sulla cosa che sto cercando di imparare. Azure SQL Database significa che il database è una connection string e nient'altro.

Anche i backup hanno contato. Automated backups che non devo configurare valgono molto rispetto all'alternativa, cioè che io imposti un backup schedule e scopra dopo se funzionava davvero.

Dato che l'intera applicazione gira su Azure Container Apps ed è configurata solo tramite environment variables, il fatto che il database sia un managed endpoint si incastra esattamente in quella forma. Niente nell'app sa o si preoccupa di cosa ci sia all'altro capo della connection string.

Quando sceglierei invece la VM

Ci sono motivi validi, solo che non valevano per me.

Se un'applicazione ha bisogno di una feature di SQL Server che il managed service non supporta, la questione è chiusa. Le applicazioni legacy a volte dipendono da comportamenti a livello di instance, linked server, job specifici dell'agent, o cross-database queries che presuppongono che tutto viva in un'unica instance.

Anche migrare un database on-premise esistente può essere più semplice su una VM, perché è lo stesso ambiente in cui già girava. Spostarlo così com'è senza cambiare niente è meno rischioso che adattarlo ai vincoli di un managed service.

E se un team ha già dei DBA che sanno come vogliono configurato SQL Server, rinunciare a quel controllo non è un risparmio, è una perdita.

La regola generale che ne ho ricavato

Managed è la scelta di default, a meno che ci sia un motivo specifico per cui non può funzionare. La domanda non è quale dei due sia più capace, perché la VM è ovviamente più capace. È se mi serve quella capacità in più abbastanza da prendermi in carico la gestione di un server.

Per la maggior parte delle applicazioni nuove, e certamente per qualsiasi cosa stia costruendo adesso, la risposta è no. Preferisco avere meno cose che tocca a me tenere in piedi.