Architecture logicielle monolithique ou microservices

Résumé

Cette semaine, j'ai pris l'avion pour Göteborg afin de rencontrer les gens d'une grande compagnie maritime internationale et de parler du développement de logiciels d'entreprise. Pendant la réunion, plusieurs experts étaient dans la salle, et l'un d'eux m'a demandé comment choisir la bonne architecture logicielle (pour des applis grandes, complexes, de niveau entreprise). Très bonne question, qui mérite largement un article de blog.

Texte intégral

L'architecture logicielle

Quand tu conçois des applis, tu ne dois pas penser seulement à l'apparence et au ressenti : une bonne conception englobe aussi la façon dont tout fonctionne ensemble. L'architecture logicielle désigne les structures fondamentales d'un système logiciel. Chaque structure comprend des éléments, des relations entre eux, et des propriétés des éléments comme des relations.

C'est comparable à l'architecture d'un bâtiment. Une fois l'architecture définie et mise en œuvre, la modifier coûte cher. C'est donc une bonne idée de choisir la bonne architecture logicielle avant de commencer à construire.

Pour une appli simple, l'architecture peut être évidente, mais quand ton application grandit en taille et en fonctionnalités, le nombre de structures du système peut croître très vite. Ça peut arriver avec le temps, à mesure que les besoins de ton client augmentent. Plus il y a de structures, plus il y a de relations entre elles, et plus ça se complique.

Maîtriser la complexité d'un logiciel

Si tu t'attends à ce que ton logiciel gère beaucoup de choses différentes, tu vas probablement devoir affronter la complexité. D'un point de vue architectural, il existe plusieurs approches pour gérer cette complexité logicielle.

Architecture monolithique

L'architecture monolithique se décrit au mieux comme « un gros bloc ». Ici, tout ce que fait ton appli fait partie de la même base de code.

Dans une « architecture monolithique », le logiciel est souvent organisé en couches, chaque couche étant composée de types de composants différents :

• couche de présentation : responsable de l'interface utilisateur et/ou de l'interface de programmation (UI / API).
• logique métier : c'est là que se définissent les vraies règles métier. C'est le cœur de l'application, très proche des processus métier réels.
• couche d'accès aux données : fournit une interface commune entre l'application en cours d'exécution et les stockages persistants du backend.
• base de données et système de fichiers : c'est là que sont stockées toutes les données et les ressources statiques (fichiers, images, etc.).

Plus l'application grossit, plus chaque couche grossit. Il devient donc plus difficile de faire évoluer une architecture monolithique : à un certain point, tout devient simplement trop gros et trop complexe.

À chaque modification de l'application, c'est toute la base de code qui est touchée. Pour de (très) grosses applications, il est donc plus difficile de maintenir le logiciel, car il faut comprendre l'application dans son ensemble.

Comme toute l'application est interdépendante, un problème dans une partie touche souvent fortement tout le système. La communication entre les différentes parties du système se fait en interne, au niveau du code. Les différentes parties doivent donc être programmées dans le même langage (ou dans des langages compatibles). C'est un frein pour adopter de nouvelles technologies (à l'avenir), puisqu'on ne peut pas facilement changer le langage de programmation d'une seule partie du système.

Architecture microservices

Au lieu de construire une grosse application monolithique, tu peux découper ton application en services plus petits, reliés entre eux. Chaque microservice est une petite application à part entière, avec sa propre architecture (plus petite et plus simple), sa logique métier et ses couches de données.

Les différents services communiquent entre eux via des API définies indépendamment de la technologie utilisée, souvent dans une « structure d'API » courante comme REST, JSON, Redis et XML. C'est ce qui permet à la combinaison des microservices de fonctionner comme « un seul système ».

En décomposant l'application « gros bloc » en services plus petits, il devient plus facile de comprendre les différentes parties du système. La maintenance est plus simple, car chaque microservice peut être développé indépendamment. Cela abaisse aussi le frein à l'adoption de nouvelles technologies, puisque tu es libre de choisir la technologie la mieux adaptée à chaque service. Une partie du système peut être programmée dans un autre langage que les autres. Des équipes différentes (aux compétences différentes) peuvent ainsi travailler ensemble.

L'art et le savoir-faire pour réussir une architecture microservices viennent de la capacité à bien définir un microservice. Trop large ou trop fin, et l'architecture est fichue. Tu peux t'appuyer sur les processus métier, sur une séparation hiérarchique ou par domaine pour définir chaque microservice.

Le défi de l'architecture microservices, c'est qu'elle ajoute de la complexité à l'ensemble du système, puisqu'il faut un mécanisme de communication distribué. Les différentes API qui se connectent entre elles peuvent être délicates à tester et à déboguer. Il devient plus difficile de mettre en œuvre des changements qui touchent plusieurs services.

Définir, concevoir et mettre en œuvre les différentes API entre services demande un accord sur les données échangées. Ce n'est pas simple à obtenir quand tu veux partager des structures de données étendues et non universelles.

Surveiller et déployer une architecture microservices peut être complexe quand les services se multiplient. Il y a simplement plus de choses à gérer, ce qui demande plus de planification et de coordination pour chaque service.

Choisir la bonne architecture

Mon défunt père m'a dit un jour qu'on « gagne le plus avec les choses qu'on ne fait pas ». Construire des applications complexes est difficile par nature : le mieux que tu puisses faire, c'est d'essayer de simplifier en ne faisant tout simplement pas tout. Concentre-toi sur ce qui compte vraiment, et fais-le bien.

Si ton application est simple et légère, une architecture monolithique est la voie à suivre. Le développement, le déploiement, la maintenance : tout est plus facile quand les choses sont petites.

Si tu ne peux pas échapper à la complexité, tu dois sérieusement envisager l'architecture microservices. Pose-toi les questions suivantes :

• Es-tu capable de définir un « langage commun » entre tes microservices ?
• Y a-t-il des processus métier clairement distincts ?
• Dans quelle mesure ces processus métier sont-ils interdépendants ?
• Comment penses-tu que ton application va évoluer avec le temps : va-t-elle grandir ou rétrécir ?
• Combien de technologies de programmation différentes comptes-tu utiliser ? Penses-tu que ça va changer à l'avenir ?
• Qui va construire et maintenir le logiciel, et a-t-il l'expérience de la gestion d'une telle architecture ?

Conclusion

Il n'existe pas de réponse « miracle » à la question de savoir quelle architecture logicielle est la bonne. Les deux approches ont leurs avantages et leurs inconvénients.

Le mieux que tu puisses faire, c'est de prendre une décision consciente, mûrement réfléchie, et de t'y tenir à fond !