Lorsque je développe moi-même un système, dois-je utiliser des microservices?
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 de simples scripts 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 implémenter toutes les capacités nécessaires dont nous aurons besoin dans le cadre.
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?
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é. Lorsque 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é.
Considérez également le 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.