L'architecture micro services est devenue de plus en plus populaire ces dernières années. Elle consiste à diviser une application en plusieurs petits services indépendants qui communiquent entre eux pour accomplir une tâche spécifique. Chacun de ces services est développé, testé et déployé indépendamment les uns des autres, ce qui permet une plus grande agilité dans le développement de l'application. Par conséquent, elle apporte une meilleure flexibilité, une scalabilité adaptée à un contexte de déploiement dans le nuage, ainsi qu'une plus grande aisance pour la maintenance.
Mais nous pouvons nous posez plusieurs questions :
Est-ce la mort définitive des monolithes ? Jusqu'où devons-nous découper nos applications ? Quelles sont les limites de cette architecture ?
Laissez-moi vous partager mes réponses.
Le monolithe : quel futur pour lui ?
Quand on entend parler de monolithe (ou d'architecture monolithique), certains ont des frayeurs dans le dos. Je comprends ces personnes. Travailler sur un énorme pavé de code, qui prends plusieurs minutes à compiler, puis à démarrer, difficile à débogger, cela ne fait pas rêver.
Mais pour autant devons-nous exclure de suite cette architecture parce que nos expériences passées étaient une souffrance ? Je ne pense pas.
Si les composants de notre application sont très fortement couplés par conception ou notre application est très petite avec un nombre d'usagers restreints, alors devrions-nous foncer vers le micro service ? Ce que je viens de décrire est une application candidate parfaite pour l'architecture monolithique.
De manière général, un bon monolithe est une application indépendante, simple, qui s’intègre facilement et qui peut même côtoyer le nuage sans trop de mal. De part son design et sa facilité, les coûts de développement sont réduits ainsi que ceux de maintenance.
Le réel problème des monolithes se trouve dans son évolution sur le long terme : si d'un coup, le nombre d'usagers augmente, l'intercommunication avec d'autres systèmes explose alors c'est à partir de là qu'il faut réfléchir à la chirurgie pour un passage au micro services.
L'architecture micro services : de l'infiniment grand vers l'infiniment petit
Une fois que nous sommes convaincus de notre besoin de scalabilté ou de réutilisabilité de nos applications, nous arrivons dans le monde des micro services. Bye bye nos gros bouts de code, bonjour la simplicité ! Je ne pense pas que ce soit si simple.
En effet, rien ne nous empêcherait dans un exercice intellectuel (ou de folie) de découper nos applications de manière atomique : une application = une seule action. De ce fait, c'est ultimement parfait : réutilisabilité maximale, performance unitaire de nos micro services optimales, nous pourrions scaler uniquement les actions les plus coûteuses. Incroyable ! Vraiment ?
Quand est-il de la complexité globale, de la communication inter micro services, de l'usage réseautique, de l'évolutivité avec les impacts sur les autres micro services ? Comment faire aussi pour se retrouver dans un dédale colossale de milliers de micro services déployé (avec les CI/CD, les instances cloud...) ? Comment déboguer efficacement ?
L'architecture microservices présente alors des défis tels que la gestion des dépendances et la synchronisation des données. Lorsque plusieurs services communiquent entre eux, il est important de gérer efficacement les dépendances pour éviter les erreurs et les retards dans le traitement des données. De plus, la synchronisation des données entre les services peut devenir complexe lorsque des mises à jour simultanées sont effectuées sur les mêmes données par plusieurs services.
De plus, la multiplicité des micro services impliquent une multiplicité des moyens de gestions de code, d'accès. Et sans une documentation incroyablement explicite et détaillée, un micro service qui ne serait pas maintenu depuis un moment sera difficilement compris et modifié par une nouvelle équipe.
Nous atteignions alors une limite : micro, c'est bien mais il ne faut pas aller plus petit. Il est important de trouver un équilibre intelligent que seuls vous et votre équipe êtes capables de juger.
Comment aller au delà des enjeux des micro services ?
Un bon moyen de palier aux problèmes d'échanges de données : l'architecture événementielle !
Je ne vais pas rentrer dans les détails (mais je vous laisse le lien vers mon article qui parle de cela ici) mais l'architecture événementielle est souvent utilisée en conjonction avec les microservices. Cette architecture utilise un système de messages pour la communication entre les services, permettant ainsi une communication asynchrone et indépendante entre les services. Les messages peuvent être utilisés pour déclencher des actions ou pour transmettre des données, ce qui permet aux services de travailler de manière autonome sans avoir à dépendre les uns des autres.
Un outil couramment utilisé pour mettre en place une architecture événementielle est Apache Kafka. Ce système de messages distribué permet de stocker et de traiter les événements en temps réel, ce qui permet de gérer efficacement les dépendances et la synchronisation des données entre les services. Il offre également des fonctionnalités telles que la réplication des données et la tolérance aux pannes, ce qui améliore la fiabilité de l'application.
Et si vous ne le savez pas, j'adore Apache Kafka !
Conclusion
L'architecture micro services est une très bonne option dans la quasi totalité des cas d'applications créées aujourd'hui : maintenable, facile à développer. Cependant, il ne faut pas tomber dans le piège des micro services à action unique : il est question d'équilibre.
Pour palier aux problèmes d'échange de données, et pour permettre un découplage plus souples entre les applications, l'architecture événementielle peut venir compléter l'architecture micro services.
Il est important de trouver un équilibre approprié entre ces deux architectures en fonction des besoins de l'application pour maximiser les avantages et minimiser les inconvénients.
TL;DR: l'architecture micro services est parfaite pour le maintien et l'évolution des applications, ainsi que pour leur scalabilité dans le cloud. Cependant, à vouloir tout découper de manière atomique, certains défauts apparaissent. C'est alors qu'il faut soit ne pas oublier l'architecture monolithique, soit faire du micro service avec de l'événementiel.