Microservices dans la mise en œuvre de Docker
Nous écrivons nos premiers microservices à l'aide de conteneurs Docker utilisant Amazon Fargate. Nous avons de nombreux doutes sur le niveau d'implémentation à l'aide de Spring Boot
Nous aurons plusieurs micro-services dans le projet, est-ce une bonne pratique que nous écrivons tous les micro-services dans un seul conteneur ou je dois créer un conteneur Docker séparé pour des micro-services séparés. De manière rentable, nous utilisons un seul conteneur, mais cela posera-t-il des problèmes pour la structure de notre projet à l'avenir?
Nous prévoyons de déployer l'application dans AWS fargate et notre application aura une grande possibilité d'extension à l'avenir et attend environ 100 à 150 micro-services différents. Dans ce cas, est-il rentable de télécharger tous ces microservices dans des conteneurs différents?
La chose la plus importante à retenir avec les microservices est qu'ils ne visent pas principalement à résoudre des problèmes techniques mais des problèmes d'organisation. Ainsi, lorsque nous examinons si une organisation doit utiliser des microservices et comment ces services sont déployés, nous devons examiner si l'organisation a les problèmes que le style de microservices résout.
La réponse à votre question sur votre architecture dépendra donc principalement de la taille de votre équipe technologique, de la structure organisationnelle, de l'âge de votre produit, de vos pratiques de déploiement actuelles et de la façon dont celles-ci sont susceptibles de changer à moyen terme.
Par exemple, si votre organisation:
- compte moins de 25 techniciens,
- organisé en 1 ou 2 équipes,
- dont chacun fonctionne sur n'importe quelle partie du produit,
- qui a moins de 12 mois,
- et est déployé en une seule fois régulièrement (par exemple, quotidiennement, hebdomadairement, mensuellement),
- et l'organisation n'est pas sur le point de croître rapidement,
alors vous voulez presque définitivement oublier les microservices pour l'instant. Dans une situation comme celle-ci, l'équipe est encore nouvelle dans l'apprentissage du domaine, donc ne sait probablement pas tout ce qu'elle devrait savoir pour vraiment comprendre ce qui serait un excellent moyen de diviser le système en une architecture distribuée. Cela signifie que s'ils le divisent maintenant, ils voudront probablement changer les limites plus tard, et cela devient très coûteux lorsque vous avez déjà un système distribué, tout en étant beaucoup plus simple dans un monolithe. De plus, avec seulement une petite équipe qui peut tous travailler (et soutenir) n'importe quelle partie du système, il n'y a pas de raison d'investir dans la construction d'une plate-forme où les équipes individuelles peuvent déployer et maintenir des services individuels. À ce stade, une organisation sera généralement beaucoup plus soucieuse de trouver des clients et d'itérer le produit rapidement, peut-être même de faire pivoter le produit, au lieu de rendre les équipes autonomes et de construire une architecture résiliente à grande échelle. Une architecture monolithique est logique à ce stade, mais un bien conç monolithe, avec des limites de composants claires imposées par les API et un accès aux données encapsulées, ce qui facilite le retrait ultérieur des services dans des processus séparés.
Regardons un peu plus loin et considérons une organisation qui est ...
- plus de 50 techniciens,
- organisé en 7 équipes,
- dont chacun ne fonctionne que sur des zones spécifiques du produit,
- qui a 3 ans,
- et a des équipes qui souhaitent déployer leur travail indépendamment de ce que font les autres équipes.
Une telle organisation devrait certainement construire une architecture distribuée. S'ils ne le font pas, et que toutes ces équipes travaillent dans un monolithe à la place, ils rencontreront toutes sortes de problèmes d'organisation, les équipes ayant besoin de coordonner leur travail, les versions étant retardées pendant que l'équipe finit l'AQ sur sa nouvelle fonctionnalité, le patch déploie étant un gros tracas pour le personnel et les clients. De plus, avec un produit mature, l'organisation devrait en savoir suffisamment sur le domaine pour pouvoir diviser sensiblement le domaine et les équipes (dans cet ordre; voir la loi de Conway) en unités sensibles et autonomes qui peuvent progresser tout en minimisant la coordination.
Vous semblez avoir déjà choisi les microservices. Selon l'endroit où vous vous situez sur les échelles ci-dessus, vous voudrez peut-être revoir cette décision.
Si vous souhaitez continuer à développer avec des microservices tout en les déployant dans un seul conteneur, sachez que il n'y a rien de mal à cela si cela convient à la façon dont votre organisation fonctionne en ce moment. Cela posera-t-il des problèmes à votre structure de projet à l'avenir? Eh bien, si vous réussissez et que votre organisation se développe, il arrivera probablement un moment où ce déploiement de conteneur unique ne sera plus le mieux adapté, en particulier lorsque les équipes commencent à posséder des services et souhaitent déployer uniquement leur service sans déployer l'ensemble de l'application. . Mais cette autonomie se fera au détriment du travail supplémentaire et de la complexité, et elle peut ne vous apporter aucun avantage à ce stade. Ce n'est pas parce que ce ne sera pas la bonne approche pour votre système à l'avenir que cela n'est pas la bonne approche pour aujourd'hui. L'astuce consiste à garder un œil dessus et à savoir quand faire l'investissement supplémentaire.
Aucun problème si vous utilisez un seul conteneur pour vos microservices, mais l'objectif principal des microservices est de maintenir séparément chaque service, chaque service doit être couplé de manière lâche et chaque service doit avoir une base de données distincte (si vous souhaitez obtenir une base de données par architecture de service). Essayez donc de réaliser cette chose, exécutez vos services dans un conteneur séparé et orchestrez ces services avec docker swarm ou Kubernetes. Je sais que les coûts sont importants, mais si vous le faites correctement, vous verrez alors la puissance de l'architecture des microservices.