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 manière 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é de façon régulière et régulière (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, plutôt que de rendre les équipes autonomes et de construire une architecture résiliente à grande échelle. Une architecture monolithique est logique à ce stade, mais unun monolithe bien conçu , avec des limites de composants claires appliquées par les API et un accès aux données encapsulé, 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 tandis 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 qu'il n'y a rien de mal à celasi cela convient à la façon dont votre organisation fonctionne actuellement. Cela posera-t-il des problèmes à la structure de votre 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 prix d'un surcroît de travail et de 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 ce n'est pas la bonne approche pour aujourd'hui. L'astuce consiste à garder un œil dessus et à savoir quand faire l'investissement supplémentaire.