Lorsque je développe moi-même un système, dois-je utiliser des microservices?


30

Je commence un nouveau projet au travail, et je serai probablement le seul développeur du projet, bien qu'un ou deux autres développeurs devront intégrer des applications existantes ou des scripts simples dans le projet principal. Le projet doit gérer l'acquisition / le traitement de données en masse et en continu à petite échelle, ainsi que l'exécution de code à la demande et sur événement. Certaines parties du cadre seront fortement liées au processeur, et certaines parties pourraient être fortement liées aux E / S; la plupart des données doivent vivre sur une seule machine, mais nous pouvons créer un cluster et connecter des machines virtuelles pour augmenter la puissance de calcul disponible. Il y aura probablement une ou plusieurs petites applications Web qui dépendent des services fournis par ce cadre principal. Le langage principal sera Python pour à peu près tout.

Ma question est de savoir si je dois ou non adopter une approche de microservices pour un effort comme celui-ci ou m'en tenir à une application monolithique, étant donné que je ferai la plupart du développement par moi-même. Ma pensée est que les microservices (en utilisant Nameko) fournissent une séparation naturelle entre les éléments du cadre qui ont différents modèles d'exécution (pipelines de données, lancés par les événements, à la demande, applications Web, etc.) et une façon claire de répartir la charge de travail et communication entre plusieurs processus. Ma préoccupation est que je me retrouverais probablement avec un cluster Kubernetes pour gérer (je connais Docker, mais encore assez nouveau pour Kubernetes), plusieurs services (rabbitmq, redis, etc.) nécessaires juste pour faciliter le fonctionnement du système, et potentiellement beaucoup de petits morceaux de code pour mettre en œuvre toutes les capacités nécessaires que nous '

Pour un projet avec un peu plus qu'un seul développeur, les microservices simplifient-ils toujours le développement et la maintenance d'un système compliqué comme celui-ci? Y a-t-il des méthodes / systèmes / cadres que je devrais envisager d'utiliser à la place, ou pour réduire les frais généraux impliqués dans la conception du système de cette façon?


10
Vous utilisez des microservices lorsque vous avez besoin des avantages fournis par les microservices, et ces avantages l'emportent sur les coûts. Personnellement, je ne vois pas pourquoi vous auriez besoin de microservices dans une application individuelle rédigée par une seule personne, à moins que vous ne vous enseigniez vous-même ou que vous n'ayez une perspective à long terme pour une application plus importante.
Robert Harvey

Réponses:


49

Les microservices sont généralement indésirables car ils transforment votre logiciel en un système distribué - et les systèmes distribués rendent tout beaucoup plus difficile. Mais une architecture orientée services présente des avantages importants:

  • différents services peuvent être développés et déployés indépendamment par différentes équipes
  • différents services peuvent être mis à l'échelle indépendamment

Comme vous serez le seul développeur, vous n'avez pas besoin de la flexibilité pour développer les services de manière indépendante.

Mais vous notez que certaines parties peuvent être liées au processeur. Il peut donc être souhaitable de les mettre à l'échelle indépendamment du reste de l'application. Si tel est le cas, cela ne signifie pas que vous devez transformer l'ensemble du projet en une architecture de microservice. Il vous suffit de déplacer cette partie gourmande en CPU dans son propre service et de conserver le reste dans un monolithe pratique. Le long de quelles lignes le système devrait être divisé est difficile à dire, mais en général l'idée DDD de «contextes délimités» est une bonne ligne directrice.

Notez que les monolithes ne sont pas mauvais. Les monolithes n'équivalent pas à un énorme projet mal entretenu et désordonné. Là où vous pouvez diviser le système en différents microservices, vous pouvez également diviser le système en différents composants au sein d'un monolithe. La séparation entre ces composants est juste plus visible et plus clairement appliquée dans une architecture orientée services. Cela signifie également que pour un système bien conçu, il devrait être assez facile de transformer un composant en service ultérieurement. Vous n'avez donc pas à vous décider dès maintenant, vous pouvez passer aux microservices si et quand un monolithe s'est révélé inadapté.

Pensez également au concept de Martin Fowler du Microservice Premium (2015): les microservices introduisent une complexité substantielle qui leur est propre, en plus de la complexité de base de votre système. Vous devez payer cette «prime» en termes de productivité réduite. Cela signifie que pour les projets simples, les microservices vous rendent moins productif. Cela change pour les projets plus complexes: alors qu'une solution monolithique peut devenir de plus en plus difficile à travailler, une architecture de microservices évolue beaucoup mieux et nécessite un effort à peu près constant. Vous devez savoir si l'effort initial supplémentaire des microservices en vaut la peine compte tenu de votre système logiciel. Puisque vous posez cette question, la réponse est probablement «non». Fowler poursuit:

Donc, ma principale directive serait de ne même pas considérer les microservices à moins d'avoir un système trop complexe à gérer comme un monolithe. La majorité des systèmes logiciels doivent être construits comme une seule application monolithique. Faites attention à une bonne modularité au sein de ce monolithe, mais n'essayez pas de le séparer en services distincts.


31
Version TL; DR: Ajoutez de la complexité uniquement lorsque cela résout les problèmes que vous avez réellement.
jpmc26

1
L'architecturer de manière à pouvoir migrer plus facilement vers une architecture de microservice plus tard. Par exemple, la séparation des préoccupations par rapport à une grosse boule de boue, et il sera plus facile de maintenir maintenant et plus facile de déplacer des portions vers des services séparés plus tard. Vous pouvez toujours avoir la division des tâches / domaines inspirée par le microservice sans passer d'appels / envoyer des messages à d'autres services.
ps2goat

1
Fowler's First Law of Distributed Objects: Don't
K. Alan Bates

1
Il y a un troisième avantage, bien qu'il soit également inutile à l'OP: si vous devez de toute façon construire un système distribué, et si vous avez déjà ou prévoyez de construire de bons outils pour votre système distribué, un microservice s'intégrera plus facilement avec ces outils et permettre un contrôle plus fin sous de nombreux aspects. Cela peut simplifier le dépannage, le profilage, les tests d'intégration, le traçage, etc. Mais cela dépend évidemment des outils existants et prenant en charge votre architecture de microservice. Sans cet écosystème de support, les microservices ne sont qu'une complexité supplémentaire.
Kevin

2
Oui, bonne réponse. Les gens semblent oublier que les microservices ajoutent en fait de la complexité - donc à moins qu'ils n'enlèvent plus de complexité, cela n'en vaut pas la peine. Et dans presque tous les cas, un seul développeur n'aura pas assez d'avantages de faire du MSA.
enderland
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.