Parlons positifs et négatifs de l'approche microservice.
Premiers négatifs. Lorsque vous créez des microservices, vous ajoutez une complexité inhérente à votre code. Vous ajoutez des frais généraux. Vous compliquez la réplication de l'environnement (par exemple pour les développeurs). Vous rendez plus difficile le débogage de problèmes intermittents.
Permettez-moi d'illustrer un véritable inconvénient. Considérons hypothétiquement le cas où vous avez 100 microservices appelés lors de la génération d'une page, dont chacun fait la bonne chose 99,9% du temps. Mais 0,05% du temps, ils produisent des résultats erronés. Et 0,05% du temps, il y a une demande de connexion lente où, par exemple, un délai d'expiration TCP / IP est nécessaire pour se connecter et cela prend 5 secondes. Environ 90,5% du temps, votre demande fonctionne parfaitement. Mais environ 5% du temps, vous obtenez de mauvais résultats et environ 5% du temps, votre page est lente. Et chaque défaillance non reproductible a une cause différente.
À moins que vous ne réfléchissiez beaucoup aux outils de surveillance, de reproduction, etc., cela va devenir un gâchis. En particulier lorsqu'un microservice en appelle un autre qui en appelle un autre à quelques couches de profondeur. Et une fois que vous avez des problèmes, cela ne fera qu'empirer avec le temps.
OK, cela ressemble à un cauchemar (et plus d'une entreprise s'est créée d'énormes problèmes en s'engageant dans cette voie). Le succès n'est possible que si vous êtes clairement conscient des inconvénients potentiels et travaillez constamment pour y remédier.
Alors qu'en est-il de cette approche monolithique?
Il s'avère qu'une application monolithique est tout aussi facile à modulariser que les microservices. Et un appel de fonction est à la fois moins cher et plus fiable en pratique qu'un appel RPC. Vous pouvez donc développer la même chose, sauf qu'elle est plus fiable, s'exécute plus rapidement et implique moins de code.
OK, alors pourquoi les entreprises adoptent-elles l'approche des microservices?
La réponse est que lorsque vous évoluez, il y a une limite à ce que vous pouvez faire avec une application monolithique. Après tant d'utilisateurs, tant de demandes, etc., vous atteignez un point où les bases de données ne s'adaptent pas, les serveurs Web ne peuvent pas conserver votre code en mémoire, etc. De plus, les approches de microservices permettent des mises à niveau indépendantes et incrémentielles de votre application. Par conséquent, une architecture de microservices est une solution pour faire évoluer votre application.
Ma règle d'or personnelle est que le passage du code dans un langage de script (par exemple Python) au C ++ optimisé peut généralement améliorer 1-2 ordres de grandeur sur les performances et l'utilisation de la mémoire. Dans l'autre sens, une architecture distribuée ajoute de l'ampleur aux besoins en ressources mais vous permet de vous adapter indéfiniment. Vous pouvez faire fonctionner une architecture distribuée, mais cela est plus difficile.
Je dirais donc que si vous démarrez un projet personnel, optez pour le monolithique. Apprenez à bien le faire. Ne soyez pas distribué car (Google | eBay | Amazon | etc) le sont. Si vous atterrissez dans une grande entreprise qui est distribuée, portez une attention particulière à la façon dont cela fonctionne et ne le gâchez pas. Et si vous finissez par devoir faire la transition, soyez très, très prudent parce que vous faites quelque chose de difficile qui est facile à très, très mal.
Divulgation, j'ai près de 20 ans d'expérience dans des entreprises de toutes tailles. Et oui, j'ai vu des architectures monolithiques et distribuées de près et personnelles. C'est sur la base de cette expérience que je vous dis qu'une architecture de microservices distribués est vraiment quelque chose que vous faites parce que vous en avez besoin, et non pas parce qu'elle est en quelque sorte plus propre et meilleure.
