Microservices: MonolithFirst?

J'ai fait des recherches sur les architectures de microservices en essayant d'obtenir un aperçu de haut niveau de tous les avantages et inconvénients, pourquoi et pourquoi, etc. Une grande partie des informations que je lis / regarde proviennent de ThoughtWorks (Martin Fowler, Neal Ford, et Al).

La plupart des travaux de Martin Fowler sur le sujet datent de quelques années, lorsque Microservices (en tant que nom connu dans la programmation, sinon en médecine générale) était encore jeune, j'en prends donc une grande partie avec un grain de sel.

Une chose en particulier est la suivante:

En entendant des histoires sur des équipes utilisant une architecture de microservices, j'ai remarqué un schéma commun.

• Presque toutes les histoires de microservices réussies ont commencé avec un monolithe qui est devenu trop grand et a été brisé
• Presque tous les cas où j'ai entendu parler d'un système qui a été conçu comme un système de microservice à partir de zéro, il s'est retrouvé dans de graves problèmes.

Ce modèle a conduit plusieurs de mes collègues à affirmer que vous ne devriez pas démarrer un nouveau projet avec des microservices, même si vous êtes sûr que votre application sera suffisamment volumineuse pour en valoir la peine. .

(ref: https://martinfowler.com/bliki/MonolithFirst.html - mettez l'accent sur le leur)

Maintenant, 3 ans plus tard et avec les microservices un terme plus omniprésent, est-il généralement acceptable qu'un nouveau système soit généralement mieux servi en ayant des blocs de service plus grands (-qui-microservice-mais-plus petits que-monolithiques) pour commencer, et en faisant les rendre plus granulaires dans le cadre d'une mesure évolutive?

Ou, existe-t-il une norme pour commencer un projet à partir de zéro avec une architecture de microservices granulaire, contrairement aux déclarations ci-dessus?

On dirait une approche générale saine, mais curieuse des pensées de la communauté.

Si votre entreprise fait des microservices depuis un certain temps, certaines pièces peuvent déjà être construites et vous devez simplement les intégrer. Des exemples probables peuvent être l'authentification en tant que service ou le stockage de données d'objets blob. Dans ce cas, vous avez déjà défini les limites et vous réutilisez le code dans une nouvelle application. C'est une bonne chose.

Pour un nouveau code où vous n'êtes pas sûr de l'endroit où doit se trouver la limite, créez-le en un seul service. Si vous le gardez modulaire, vous pouvez en séparer les microservices si nécessaire. D'autant plus que vous trouvez des éléments de votre service qui doivent évoluer différemment des autres.

L'avantage des microservices est que vous pouvez ajouter des instances pour adapter le travail effectué à la demande. Si une partie de votre travail se décompose, il peut être judicieux de le séparer dans son propre microservice.

En général:

• Si vous avez déjà construit des microservices, réutilisez-les
• Si vous construisez quelque chose de nouveau, faites d'abord fonctionner l'idée
• Pendant que vous construisez, essayez de garder les choses modulaires afin que certains services puissent facilement être déployés
• Au fur et à mesure que vous construisez, si une partie de votre service doit pouvoir évoluer à la demande à un taux différent, séparez-le en son propre service

Trop souvent, nous entendons des directives utiles de personnes intelligentes ayant une bonne réputation comme Martin Fowler, puis nous en faisons une doctrine difficile qui ne peut en aucun cas être influencée.

Vous devez prendre des déclarations comme ça dans l'esprit de leur signification. Martin Fowler essaie de sauver les gens de la paralysie par l'analyse et leur dit de construire quelque chose qui fonctionne en premier. Vous pouvez toujours le séparer plus tard, lorsque vous en saurez plus sur le fonctionnement réel de votre application.

Les avantages les plus immédiats des microservices peuvent être obtenus par une simple modularisation du code. Vous pouvez isoler des groupes de fonctionnalités en modules en utilisant le système de modules que vous possédez (maven, npm, nuget, peu importe). Chaque module peut servir un seul objectif, s'asseoir sur son propre référentiel, utiliser son propre schéma de base de données, gérer sa propre configuration, avoir son propre backlog de fonctionnalités et calendrier de publication. Ils peuvent toujours être déployés ensemble sur un monolithe. C'est une quantité très gérable de frais généraux et donne de bons avantages. Le plus gros frais généraux provient de la séparation des déploiements, ce qui n'est vraiment utile qu'une fois que vous avez suffisamment d'évolutivité pour le rendre nécessaire. Si votre code est déjà modulaire, la migration sera plus facile le moment venu.

À mon avis, il peut être avantageux de développer d'abord un monolithe (ou mieux: de développer des parties de votre application en tant que monolithe).

Il y a des cas où vous n'êtes pas sûr du domaine et des limites de votre problème (par exemple, je construis un site de gestion de navire, ai-je besoin d'un service de navire ET d'un service de flotte, ou un service de navire est-il suffisant?), Et dans de tels cas, un le monolithe peut être plus facile à développer.

Vous devez arrêter de faire cela si vous devez intégrer différentes technologies dans le mélange (par exemple, vos pièces existantes sont écrites en C #, mais votre nouveau problème nécessite un apprentissage automatique, il est préférable de le faire avec python), avez une bonne compréhension des domaines dans votre projet ou votre monolith traite pour galvaniser, par exemple tout le monde construit ce monolithe et écrase la notion de services séparés.

Je suis presque sûr qu'il y a eu quelques questions sur cet article exact de MF.

Mon point de vue est le suivant:

Un Monolith avec des problèmes de maintenance ou d'évolutivité est amélioré en le décomposant en micro services. Un tel projet sera presque toujours «réussi» car même la décomposition d'une petite section peut entraîner des gains mesurables et vous pouvez tracer une ligne en dessous lorsque vous êtes satisfait.

Que ce soit votre moitié monolithe + une file d' attente de messages et un couple de processus de travail compte comme « Microservice architecture » est un argument d'avoir au pub, mais vous serez certainement appelez ce que lorsque vous parlez du projet.

D'un autre côté, tout nouveau projet, quelle que soit l'architecture choisie, risque de ne pas répondre aux attentes, vous vous attendez donc naturellement à un taux de réussite inférieur. De plus, si vous avez commencé à chercher à faire de l'ensemble une «architecture de microservices de meilleures pratiques», vous vous aventurez peut-être dans les nouvelles technologies et les éléments les plus difficiles des microservices.

Nous devons également nous rappeler que MF écrit dans une grande perspective POO. Il est naturellement sceptique quant à une approche distribuée plus moderne.

De nos jours, je m'attendrais à ce que toute solution de grande entreprise intègre un élément de microservices et seul un imbécile vous recommanderait de créer une application monolithique géante à moins que vous ne distribuiez une seule application de style bureau.

Dans ma (vaste) expérience, j'ai vu beaucoup plus de projets échouer à cause de problèmes humains que de problèmes technologiques. Malheureusement, les gens n'aiment pas échouer et ont donc tendance à dénaturer les raisons de l'échec et à blâmer la technologie.

Dans mon domaine, la finance, la plupart des nouveaux projets suivent de nos jours des architectures de microservices, et il semble que ce soit une architecture gagnante du point de vue du coût total de possession (TCO). Ces projets ne semblent pas échouer aussi souvent, et lorsqu'ils le font, les raisons invoquées ne répertorient pas souvent l'architecture de l'application comme problème.