Pourquoi en avons-nous même besoin?
L'énorme avantage des microservices - et plus largement, SOA - est le niveau élevé d'abstraction des composants internes - non seulement la mise en œuvre, mais aussi les technologies utilisées. Par exemple, si un système est développé sous la forme de cinq microservices par cinq équipes, une équipe peut décider de passer à une pile technologique complètement différente (par exemple de la pile Microsoft à LAMP) sans même demander l'avis des autres équipes.
Regardez Amazon AWS ou Twilio. Savez-vous si leurs services sont implémentés en Java ou Ruby? Utilisent-ils Oracle ou PostgreSQL ou Cassandra ou MongoDB? Combien de machines utilisent-ils? Vous souciez-vous même de cela; en d'autres termes, ces choix technologiques affectent-ils la façon dont vous utilisez ces services? ... Et surtout, s'ils migrent vers une autre base de données, devrez-vous modifier votre application client en conséquence?
Maintenant, que se passe-t-il si deux services utilisent la même base de données? Voici une infime partie des problèmes qui peuvent survenir:
L'équipe de développement du service 1 souhaite passer de SQL Server 2012 à SQL Server 2016. Cependant, l'équipe 2 s'appuie sur une fonctionnalité obsolète qui a été supprimée dans SQL Server 2016.
Le service 1 est un énorme succès. L'hébergement de la base de données sur deux machines (maître et basculement) n'est plus une option. Mais la mise à l'échelle du cluster sur plusieurs machines nécessite des stratégies telles que le partage. Pendant ce temps, l'équipe 2 est satisfaite de l'échelle actuelle et ne voit aucune raison de passer à autre chose.
Le service 1 doit passer à UTF-8 comme codage par défaut. Le service 2, cependant, est content d'utiliser la page de code 1252 Windows Latin 1.
Le service 1 décide d'ajouter un utilisateur avec un nom spécifique. Cependant, cet utilisateur existe déjà, créé il y a quelques mois par la deuxième équipe.
Le service 1 a besoin de nombreuses fonctionnalités différentes. Le service 2 est un composant hautement critique et doit maintenir les fonctionnalités de la base de données au minimum pour réduire le risque d'attaques.
Le service 1 nécessite 15 To d'espace disque; la vitesse n'est pas importante, les disques durs ordinaires conviennent donc parfaitement. Le service 2 nécessite au maximum 50 Go, mais doit y accéder le plus rapidement possible, ce qui signifie que les données doivent être stockées sur un SSD.
...
Chaque petit choix affecte tout le monde. Chaque décision doit être prise en collaboration, par des personnes de chaque équipe. Des compromis doivent être faits. Comparez cela à une totale liberté de faire tout ce que vous voulez dans un contexte SOA.
c'est trop [...] ingérable.
Alors vous vous trompez. Je suppose que vous déployez manuellement .
Ce n'est pas ainsi qu'il faut faire les choses. Vous devez automatiser le déploiement des machines virtuelles (ou conteneurs Docker) qui exécutent la base de données. Une fois que vous les avez automatisés, le déploiement de deux serveurs ou vingt serveurs ou deux mille serveurs n'est pas très différent.
La chose magique à propos des bases de données isolées est qu'elles sont extrêmement gérables . Avez-vous essayé de gérer une énorme base de données utilisée par des dizaines d'équipes? C'est un cauchemar. Chaque équipe a des demandes spécifiques, et dès que vous touchez quelque chose, cela affecte quelqu'un. Avec une base de données associée à une application, la portée devient très étroite, ce qui signifie qu'il y a beaucoup moins de choses à penser.
Si une énorme base de données nécessite des administrateurs système spécialisés, les bases de données qui sont utilisées par une seule équipe peuvent essentiellement être gérées par cette équipe (DevOps est également à ce sujet), ce qui libère du temps pour les administrateurs système.
c'est trop cher
Définissez le coût.
Les coûts de licence dépendent de la base de données. À l'ère du cloud computing, je suis presque sûr que tous les principaux acteurs ont repensé leurs licences pour s'adapter au contexte où, au lieu d'une énorme base de données, il y en a beaucoup de petites. Sinon, vous pouvez envisager de passer à une autre base de données. Soit dit en passant, il y en a beaucoup.
Si vous parlez de puissance de traitement, les machines virtuelles et les conteneurs sont compatibles avec le CPU, et je ne serais pas très affirmatif qu'une énorme base de données consommera moins de CPU que de nombreuses petites faisant le même travail.
Si votre problème est la mémoire, les machines virtuelles ne sont pas un bon choix pour vous. Les conteneurs sont. Vous pourrez en étendre autant que vous le souhaitez, sachant qu'ils ne consommeront pas plus de RAM que nécessaire. Bien que la consommation totale de mémoire soit plus élevée pour de nombreuses petites bases de données par rapport à une seule grande, je suppose que la différence ne sera pas trop importante. YMMV.