avons-nous bouclé la boucle avec les microservices, de retour à des approches très old school?

En termes d’architecture et de conception logicielles, comment les microservices s’empilent-ils (jeu de mots) contre le middleware? Je viens de Java, et il semble que lorsque vous vous éloignez du REST direct en tant qu'API, et que vous supprimez différentes couches et paramètres de connexion, au moins en Java, vous avez presque bouclé la boucle avec des idées très anciennes. . Nous sommes revenus à la virtualisation ... alors que la JVM est déjà virtuelle.

De manière agnostique, vous pouvez, et je dirais les avantages de l'abstraction d'une API RESTful à CORBA. Ou, d'une manière plus centrée sur java, JMS ou MDB.

À une époque, EJB était un gros problème à Java, puis il a été reconnu comme un peu d'effet de cluster, mais, maintenant, revenons-nous au début?

Ou, les microservices offrent-ils quelque chose qui manque à CORBA, ou mieux encore, MDB? Quand je lis (TLDR) Martin Fowler expliquant les microservices, cela me semble être une bonne solution à un mauvais problème, si vous voulez. Ou plutôt, une approche fermée qui introduit un niveau de complexité qui ne fait que pousser le problème. Si les services sont vraiment micro et nombreux, alors chacun a un coût en dollars pour le faire fonctionner et le maintenir.

De plus, si un micro- service parmi de nombreux autres change son API, tout dépend de ce service. Il ne semble pas faiblement couplé, il semble l'opposé de l'agile. Ou est-ce que j'utilise mal ces mots?

Bien sûr, il y a une quantité indéterminée de choix entre ces extrêmes.

Requin contre Gorille ... allez-y! (Pour le pédant, c'est censé être ironique, et ce n'est pas du tout mon intention. La question est censée être prise au pied de la lettre. Si la question peut être améliorée, veuillez le faire, ou commenter et je corrigerai. )

Imaginez une multitude de microservices fonctionnant en docker, le tout sur une même machine, parlant entre eux ... folie. Difficile à maintenir ou à administrer, et presque impossible de changer quoi que ce soit car tout changement se répercutera en cascade et provoquera des erreurs imprévisibles. Comment est-il préférable que ces services soient répartis sur différentes machines? Et, s'ils sont distribués, alors certaines techniques très, très anciennes ont résolu, au moins dans une certaine mesure, l'informatique distribuée.

Pourquoi la mise à l'échelle horizontale est-elle si répandue ou du moins souhaitable?

TL; DR. J'ai eu le plaisir de boire beaucoup de Kool-Aid aromatisé Microserver, donc je peux parler un peu des raisons derrière eux.

Avantages:

• Les services savent que leurs dépendances sont stables et ont eu le temps de cuire
• Autoriser les déploiements continus de nouvelles versions
• Permet aux composants d'être inversés sans affecter les couches supérieures.

Les inconvénients:

• Vous ne pouvez pas utiliser les fonctionnalités nouvelles et brillantes de vos dépendances.
• Vous ne pouvez jamais rompre la compatibilité descendante de l'API (ou du moins pas pour de nombreux cycles de développement).

Je pense que vous comprenez fondamentalement comment une architecture de microservices est censée fonctionner. La façon dont il est censé être exécuté est que chaque microservice (appelé à partir de maintenant dans MS) a une API rigide sur laquelle tous ses clients sont d'accord. Le MS est autorisé à apporter les modifications qu'il souhaite tant que l'API est préservée. Le MS peut être jeté et réécrit à partir de zéro, tant que l'API est préservée.

Pour faciliter le couplage lâche, chaque MS dépend de la version n-1 de ses dépendances. Cela permet à la version actuelle du service d'être moins stable et un peu plus risquée. Il permet également aux versions de sortir par vagues. Le premier serveur est mis à niveau, puis la moitié et enfin le reste. Si la version actuelle développe des problèmes graves, le MS peut être restauré à une version précédente sans perte de fonctionnalité dans d'autres couches.

Si l'API doit être modifiée, elle doit être modifiée d'une manière qui est rétrocompatible.

Chaque technique de développement logiciel que nous ayons jamais inventée concerne la gestion de la complexité d'une manière ou d'une autre. Une grande partie d'entre eux concernait et continue de concerner l'abstraction, l'encapsulation et le couplage lâche. Les microservices sont encore une autre façon de faire ces choses, c'est probablement pourquoi cela ressemble à beaucoup de techniques plus anciennes à un niveau théorique élevé, mais cela ne le rend pas moins utile ou pertinent.

En ce qui concerne le couplage lâche, je pense que vous avez un peu mal compris l'objectif. Si la tâche A doit appeler la tâche B, il n'y aura jamais moyen de découpler A et B à 100%. Ça n'arrivera jamais. Ce que vous pouvez faire est de vous assurer que, si la tâche B appelle la tâche C, alors la tâche C ne devrait jamais avoir à se soucier des modifications apportées à A. Si ces trois tâches sont toutes liées ensemble dans un gros blob, en se transmettant des structures, alors il y a un une chance importante qu'ils devront tous changer si l'un d'eux le fait. Mais si les trois sont des microservices, alors vous êtes essentiellement assuré qu'un changement vers A ne forcera que B à mettre à jour (à moins que ce soit un changement si énorme dans la fonctionnalité de base de A que vous auriez probablement dû en faire un tout nouveau service). Cela est particulièrement vrai si toutes les mises à jour de microservices sont effectuées d'une manière rétrocompatible, ce qu'elles devraient être.

En ce qui concerne le commentaire agile, je peux vous dire par expérience personnelle que notre code de microservice-y joue beaucoup mieux avec agile que notre code "lié dans un gros blob". Dans ce dernier, chaque fois que quelqu'un corrige un bogue dans une fonction de bas niveau, il doit littéralement envoyer à tout le département R&D un e-mail disant "veuillez relier vos tâches ou elles planteront toutes vendredi". Nous en recevons deux chaque semaine . Si son code était dans un microservice, nous bénéficierions tous automatiquement du correctif dès qu'il déploierait une nouvelle version.

Je ne comprends pas complètement le commentaire sur COBRA et MDB, car ils ne semblent pas être des architectures logicielles mais plutôt des composants d'une seule; à ma connaissance, ce sont des moyens potentiels de définir les protocoles de messagerie de vos microservices et / ou de mettre en œuvre lesdits microservices, et non en soi des alternatives aux microservices.

Comment est-il préférable que ces services soient répartis sur différentes machines?

À cause du cloud.

Vous avez encore ri? Sérieusement, pour de nombreuses entreprises, le plus gros coût du logiciel n'est plus le logiciel. C'est la bande passante, le matériel, les coûts CDN, etc. Maintenant que tout le monde a un appareil mobile, il y a juste beaucoup plus de trafic. Et cela ne fera qu'empirer lorsque votre grille-pain obtient sa propre connectivité Internet.

Les entreprises cherchent donc à gérer ces coûts. Plus précisément, ils essaient de gérer le problème commercial de "si cette chose explose, comment puis-je servir des millions de personnes obtenant / utilisant mon logiciel - sans payer à l'avance pour que les serveurs servent des millions de personnes obtenant / utilisant mon logiciel ? ".

Pourquoi la mise à l'échelle horizontale est-elle si répandue ou du moins souhaitable?

Parce qu'il répond à ce problème commercial (énorme et croissant).

Lorsque vous avez une douzaine d'utilisateurs, vous pouvez lancer tous les services sur une seule boîte. C'est bien, car vous ne voulez payer qu'une seule boîte. Et vous ne voulez pas non plus payer les modifications apportées à l'application pour diviser les différents services lorsque votre entreprise évolue. De nos jours, vous n'avez pas le temps de le faire avant que la foule de clients n'allume vos serveurs de toute façon.

C'est aussi bien car cela vous permet de jongler avec les allocations de serveur afin de pouvoir:

1. utilisez la plupart des serveurs dont vous disposez, ne laissant que peu de «déchets».
2. mesurer les performances des éléments individuels de votre logiciel.
3. réduire le déploiement / les temps d'arrêt causés par les versions.

Avoir des déploiements très granulaires rend ces deux choses plus faciles / meilleures (en plus d'aider à imposer une meilleure séparation des préoccupations).