Azure
Azure SQL Database ou SQL Server sur une VM ? Ce que j'ai appris
Les deux font tourner SQL Server. La différence, c'est qui applique les patches, qui gère les backups, et combien de contrôle il vous faut vraiment. Pour mon API, confier tout ça à Azure était le choix évident.
Quand j'ai fait le deploy de la Sports Betting API sur Azure, il me fallait un database derrière, et il y avait deux options évidentes : Azure SQL Database, le managed service, ou une virtual machine avec SQL Server installé dessus. Les deux font tourner SQL Server. La différence porte sur tout ce qui entoure le database, pas sur le database lui-même.
Ce que l'option VM implique vraiment
Une VM avec SQL Server dessus, c'est une machine qui m'appartient. Je choisis la taille, j'installe SQL Server, je le configure, et il se comporte exactement comme un SQL Server sur n'importe quelle autre machine, parce que c'est ce qu'il est.
Ça veut aussi dire que tout ce qui concerne cette machine est à moi de gérer. Les updates de l'operating system, les patches SQL Server, les backups, la configuration de la high availability, veiller à ce que le disque ne se remplisse pas. Si un security patch sort, c'est à moi de l'appliquer et le downtime est le mien.
L'avantage, c'est le contrôle total. Accès complet à l'instance, n'importe quelle feature de SQL Server, n'importe quelle configuration, les jobs de SQL Server Agent, le file system, les cross-database queries. Si j'ai besoin de quelque chose de précis au niveau de l'instance, c'est disponible.
Ce qu'Azure SQL Database abandonne et ce qu'il rend
Azure SQL Database, c'est le database as a service. Je n'obtiens pas une machine, j'obtiens un database, et Azure prend en charge l'operating system, les patches et les automated backups.
En échange, certaines choses ne sont plus à moi. Pas de SQL Server Agent sous la même forme, pas d'accès au file system, pas de configuration au niveau de l'instance, et des choses comme les cross-database queries fonctionnent autrement ou pas du tout. C'est SQL Server, mais une version restreinte.
Pourquoi j'ai choisi le managed
Pour mon API, la décision était simple, et ce n'était pas vraiment une question de features. C'était une question de ce à quoi je voulais réellement consacrer mon temps.
Je construis une API. Je ne suis pas DBA, et je n'ai pas envie de devenir la personne chargée d'appliquer les patches d'un database server sur un projet d'apprentissage. Chaque heure passée à maintenir une VM est une heure qui ne va pas à ce que j'essaie d'apprendre. Avec Azure SQL Database, le database est une connection string et rien d'autre.
Les backups ont compté aussi. Des automated backups que je n'ai pas à configurer valent beaucoup face à l'alternative : mettre en place un backup schedule moi-même, puis découvrir plus tard s'il marchait vraiment.
Comme toute l'application tourne sur Azure Container Apps et se configure uniquement par environment variables, un database qui n'est qu'un managed endpoint colle exactement à cette forme. Rien dans l'app ne sait ni ne se soucie de ce qu'il y a à l'autre bout de la connection string.
Quand je prendrais la VM à la place
Il y a de vraies raisons, elles ne s'appliquaient simplement pas à moi.
Si une application a besoin d'une feature de SQL Server que le managed service ne prend pas en charge, la question est réglée. Les applications legacy dépendent parfois de comportements au niveau de l'instance, de linked servers, de jobs d'agent précis, ou de cross-database queries qui supposent que tout vit dans une seule instance.
Migrer un database on-premises existant peut aussi être plus simple vers une VM, parce que c'est le même environnement que celui dans lequel il tournait déjà. Le déplacer tel quel sans rien changer est moins risqué que de l'adapter aux contraintes d'un managed service.
Et si une équipe a déjà des DBA qui savent comment ils veulent configurer SQL Server, abandonner ce contrôle n'est pas une économie, c'est une perte.
La règle générale que j'en retire
Le managed par défaut, sauf raison précise de ne pas pouvoir. La question n'est pas de savoir lequel est le plus capable, parce que la VM l'est manifestement. C'est de savoir si j'ai assez besoin de cette capacité en plus pour accepter d'exploiter un serveur en échange.
Pour la plupart des applications récentes, et certainement pour tout ce que je construis en ce moment, la réponse est non. Je préfère avoir moins de choses que je dois maintenir en état de marche.