- "Monolith > apps > services > microservices"
- D’abord, ce n’est pas une règle, c’est simplement mon avis. Ceux qui ont déjà construit de grands systèmes distribués savent qu’en pratique, cela ne fonctionne pas exactement ainsi et qu’il faut s’adapter
- Ensuite, les étapes sont importantes
- Pour une entreprise de 5 à 50 personnes, faites simplement un Monolith
- Pour une entreprise de 10 000 personnes, vous aurez probablement déjà tout ce qui précède. Mais si je devais parler de ce qui a changé dans ma façon de voir les choses…
Commençons par les définitions
- monolith - xyz.com
- apps - abc.xyz.com
- services - prennent en charge les apps/le monolithe, l’infrastructure de base, les fonctions de conformité essentielles, et peuvent ne pas être écrits par les équipes applicatives (maintenance assurée par l’infra)
- microservices - quelques centaines de lignes de code, le plus souvent à usage unique, qui pourraient/devraient être une bibliothèque ou un SDK
Why ? : essentiellement à cause de la "vitesse & du risque"
- #1 Il est plus simple pour toute l’équipe de développement de travailler sur une seule grosse app (imaginez que tout le site soit une app Rails)
- #2 Le système distribué dont vous finirez forcément par avoir besoin à mesure que vous grandissez est déjà difficile à raisonner, même sans des centaines de microservices risqués en plus
- #3 Si vous allez jusqu’au bout du microservice, vous devez introduire de nouveaux concepts pour gérer une expansion incontrôlée
- #4 Les services d’infrastructure sur mesure (bespoke) ou les microservices sont une forme extrême de dette. Le code est déjà une dette, mais un service en est une version extrême. Réfléchissez à ce que cela implique. Faites-en un point de levier
- Les ingénieurs en systèmes distribués n’aiment pas les doublons, donc si quelque chose est fait à plusieurs endroits, ils pensent : « sortons-le et faisons-en un microservice »
- En théorie, c’est juste, et jusqu’à dix ou vingt, cela va. Mais au-delà de plusieurs dizaines, ou quand c’est utilisé à l’échelle d’une grande entreprise, le problème n’est plus technique, il devient organisationnel
- Ce que je dis peut sembler être une mauvaise dichotomie, mais en réalité il existe des défis techniques autour des microservices, et encore davantage de problèmes organisationnels
Ce qui m’inquiète
- #1 (sauf cas particulier où l’entreprise est dirigée par un CEO issu de l’IT) l’infrastructure passe toujours après le reste dans les priorités
- #2 Quand il y a trop de services, on finit généralement par avoir des problèmes de propriété et de frontières
- #3 On introduit encore plus d’outils pour gérer l’énorme quantité de microservices
- #4 Plus important encore, chaque microservice qui aurait dû être une bibliothèque ou un SDK introduit un risque en production
Ce que je recommande généralement
- #1 Garder le Monolith aussi longtemps que possible
- #2 Pour les services, commencer par ce dont l’infrastructure a besoin, pas par le développement applicatif
- #3 Si vous devez découper le Mono, décomposez-le en grosses apps, pas en petits services
- #4 Considérez chaque nouvelle app comme un mur virtuel à l’intérieur de l’entreprise
- #5 Si possible, préférez les bibliothèques aux microservices
13 commentaires
La dernière partie, sur les inquiétudes et les recommandations, m’a vraiment parlé.
Au fond, c’est un contexte assez similaire en termes de taille d’entreprise comme de taille de service, et j’ai eu le sentiment qu’il faudra un jugement particulièrement fin pour s’y préparer à l’avance, puisqu’un moment viendra forcément où il deviendra impossible de ne pas découper davantage.
Ne devrait-on pas plutôt raisonner en fonction de la taille du système plutôt que de celle de l’entreprise ? Ou bien ai-je mal compris le MSA ?
Je suis d'abord d'accord avec l'avis, dans les commentaires ci-dessus, disant :
« Le problème n'est-il pas moins les microservices eux-mêmes que l'expansion incontrôlée des services ? »
Et à mesure que l'entreprise grandit, les inconvénients propres au monolithe, comme les problèmes de déploiement et de gestion des branches, deviennent trop évidents ; il faut donc bien choisir le compromis entre coûts et productivité.
C'est un excellent article. Merci.
On dirait que c’est similaire à la polémique sur l’importance des design patterns.
Les design patterns sont des modèles de code issus du processus de résolution de divers problèmes, mais...
ils doivent être adaptés et appliqués selon les besoins, en fonction du contexte.
Pourtant, il y a souvent des gens qui s’y accrochent comme s’il s’agissait d’une réponse modèle incontournable...
Ces jours-ci, avec le MSA aussi, on voit un phénomène similaire : de plus en plus de gens semblent penser que c’est forcément du MAS...
On dirait un débat du type « l’œuf ou la poule ».
Le problème n’est-il pas moins les microservices eux-mêmes que l’expansion incontrôlée des services ?
Je pense qu’il est important de trouver le bon équilibre.
Avec les microservices, on peut facilement en arriver à ce que chaque nouvelle fonctionnalité = un nouveau microservice,
ce qui risque de rendre la gestion de plus en plus difficile.
Cela me rappelle l’article « Goodbye Microservices » précédemment publié sur le blog technique de Segment.
Segment aussi, bien qu’il traite en temps réel une très grande quantité de données en tant que CDP, est passé d’une architecture microservices à un monolithe et a expliqué les raisons de ce choix dans son blog. J’ai l’impression que cela recoupe aussi en partie ce que dit cet article :)
https://segment.com/blog/goodbye-microservices/
Je suis globalement d’accord avec cette idée.
Dans notre entreprise, nous sommes 5 développeurs, donc je pense qu’il est encore pertinent de privilégier un monolithe (
RubyOnRails).Comme dans l’article ci-dessus, si cela devient un projet sur lequel plus de 50 personnes développent en même temps, je pense qu’à ce moment-là nous construirons un deuxième monolithe.
S’il s’agit d’une entreprise de 5 à 50 personnes, partez simplement sur un monolithe << Cela veut dire le nombre total de collaborateurs, pas le nombre de développeurs, n’est-ce pas ?
On dirait qu’il parle de la taille de l’entreprise~
Si possible, conserver un monolithe le plus longtemps possible < je compatis totalement. En séparant, l’augmentation des coûts de maintenance est importante.
Je pense que c’est un article qui s’inscrit comme une réaction au fait que la MSA devient de plus en plus dogmatique, et qu’en ce sens, il a sa pertinence.