Monolithe, microservices et serverless

Un monolithe est une application déployée d'un seul bloc : tout son code tourne dans un même programme et partage une même base. Une architecture en microservices découpe au contraire l'application en petits services indépendants, chacun avec ses données, qui communiquent par le réseau. Le serverless confie l'exécution de fonctions à un fournisseur de cloud, qui les lance à la demande. Ce chapitre est un chapitre de culture : il explique ces styles, ce qu'ils apportent et ce qu'ils coûtent, pour que tu saches en parler en veille technologique et justifier pourquoi ton projet de BTS n'en a pas besoin.

Le monolithe

Toutes les versions de ResaSalles de ce cours sont des monolithes : une seule API Express (ou une seule application PHP, ou un seul exécutable WinForms) qui contient la gestion des salles, des réservations, des employés et des notifications, avec une seule base MySQL. On la construit, on la teste et on la déploie d'un coup.

« Monolithe » n'est pas une insulte. C'est l'architecture de la grande majorité des applications de gestion, et souvent la bonne.

Le défaut principal d'un monolithe n'est pas d'être d'un seul bloc ; c'est de devenir un plat de spaghettis quand personne ne tient l'architecture. D'où l'intérêt d'un intermédiaire.

Le monolithe modulaire

Un monolithe modulaire reste déployé d'un bloc, mais son code est découpé en modules aux frontières nettes : salles, reservations, employes, notifications. Chaque module expose quelques fonctions publiques et cache le reste ; un module n'accède jamais aux tables d'un autre, il passe par ses fonctions. C'est le rangement par fonctionnalité du chapitre 6, poussé jusqu'au bout.

On garde la simplicité de déploiement du monolithe, et on se prépare à extraire un module en service séparé le jour où ce sera vraiment utile.

Les microservices

Dans une architecture en microservices, chaque fonction métier devient un service autonome :

• il a son propre code, souvent dans son propre dépôt, et peut être écrit dans un autre langage que les autres ;
• il a ses propres données : aucun autre service ne lit sa base directement ;
• il est déployé indépendamment : on peut mettre à jour le service des notifications sans toucher aux réservations ;
• il communique avec les autres par le réseau, en appels HTTP (API REST, gRPC) ou en messages asynchrones.

Autour des services, il faut des pièces d'infrastructure :

• une passerelle d'API (API gateway), point d'entrée unique des clients, qui transmet chaque requête au bon service, vérifie l'authentification et limite le débit ;
• un bus de messages (message broker, comme RabbitMQ ou Kafka) : un service publie un événement (« réservation créée »), les services intéressés s'y abonnent. C'est l'architecture orientée événements (event-driven) ;
• des conteneurs (Docker) et un orchestrateur (Kubernetes) pour lancer, redémarrer et multiplier les services (Docker) ;
• une supervision centralisée : journaux, métriques et traces qui suivent une requête à travers tous les services.

Ce que coûtent les microservices

Les microservices résolvent des problèmes de grandes organisations : des dizaines d'équipes, des millions d'utilisateurs, des parties de l'application qui ne subissent pas la même charge. Ils en créent d'autres :

• Le réseau peut échouer. Un appel de fonction ne tombe pas en panne ; un appel HTTP, si. Chaque service doit gérer les délais, les nouvelles tentatives, l'indisponibilité des autres.
• Plus de jointure ni de transaction globale. Pour afficher « les réservations avec le nom de l'employé », il faut appeler deux services. Pour garder des données cohérentes entre deux services, on renonce à la transaction SQL et on accepte une cohérence à terme (eventual consistency), avec des mécanismes de compensation.
• Déboguer devient une enquête. Une erreur peut venir de n'importe lequel des services traversés.
• L'exploitation coûte cher. Dix services, c'est dix pipelines de déploiement, dix configurations, dix choses à superviser et à mettre à jour.

Beaucoup d'architectes recommandent de commencer par un monolithe (Martin Fowler l'a résumé en 2015 dans un article intitulé MonolithFirst) et de n'extraire un service que lorsqu'un besoin précis le justifie : une partie qui doit tenir une charge très différente, une équipe qui doit livrer indépendamment.

Le serverless

Serverless (« sans serveur ») ne veut pas dire qu'il n'y a pas de serveur, mais que tu ne t'en occupes plus. Tu écris des fonctions ; le fournisseur de cloud (AWS Lambda, Azure Functions, Google Cloud Functions, les fonctions des plateformes d'hébergement web) les exécute quand un événement les déclenche : une requête HTTP, un fichier déposé, un message, une heure programmée. On parle aussi de FaaS (Function as a Service).

Pour ResaSalles, une fonction serverless conviendrait bien à l'envoi des rappels de la veille, déclenché chaque soir à 18 h, pendant que l'application principale reste un monolithe. On parle d'architecture hybride.

Comparer et choisir

Ces styles décrivent le découpage en programmes déployables. Ils se combinent avec ceux des chapitres précédents : chaque microservice est souvent organisé en couches à l'intérieur, et un monolithe peut être hexagonal.

Exercices

Exercice 1 sur 3 Monolithe ou microservices ? Réussi À revoir

Pour chaque situation, recommande une architecture et justifie en deux phrases.

1. Une mutuelle de 40 salariés veut une application interne de gestion des congés, développée par un prestataire de deux personnes.
2. Une plateforme nationale de billetterie de concerts : 200 développeurs en 15 équipes ; le module de vente subit des pics de charge énormes à l'ouverture des ventes, pas le reste.
3. Ton projet E6 : la gestion des interventions d'une société de maintenance, développée en binôme.

Voir la réponseMasquer la réponse de l'exercice 1

1. Monolithe en couches. Une petite équipe, une charge faible et des données liées (salariés, soldes, demandes) : un seul programme et une seule base sont plus simples et plus fiables.
2. Microservices, au moins pour la vente. Plusieurs équipes doivent livrer indépendamment, et la vente doit pouvoir monter en charge seule, sans multiplier tout le reste.
3. Monolithe, idéalement modulaire et en couches. Le binôme doit pouvoir lancer, comprendre et modifier toute l'application en une heure ; des microservices compliqueraient le démarrage et l'épreuve sans rien apporter.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 3 Ce qui change avec les microservices Réussi À revoir

ResaSalles est découpée en trois services : salles, reservations, employes, chacun avec sa base. Explique comment le service reservations peut vérifier la capacité d'une salle, et ce qui se passe si le service salles est indisponible. Que perd-on par rapport au monolithe ?

Voir la réponseMasquer la réponse de l'exercice 2

Le service reservations ne peut plus lire la table salle : il doit appeler l'API du service salles (GET /salles/2) pour obtenir la capacité, ou garder une copie locale des capacités, mise à jour par les événements « salle modifiée » publiés par le service salles.

Si salles est indisponible et qu'on l'appelle à chaque réservation, les réservations échouent aussi : il faut un délai d'attente court, un message d'erreur clair, voire la copie locale. Avec la copie, on peut continuer, au prix d'une capacité peut-être pas à jour.

On perd la simplicité : plus de jointure, plus de transaction couvrant les deux données, un appel réseau qui peut échouer, des cas d'erreur nouveaux à tester. Le monolithe vérifiait tout cela avec une requête SQL.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 3 Vrai ou faux ? Réussi À revoir

1. Serverless signifie que le code s'exécute sur le poste de l'utilisateur.
2. Dans une architecture en microservices, deux services ne partagent pas une même base de données.
3. Un monolithe ne peut pas être organisé en couches.
4. Une passerelle d'API est le point d'entrée unique des clients d'un ensemble de services.
5. Le démarrage à froid est un inconvénient des fonctions serverless.

Voir la réponseMasquer la réponse de l'exercice 3

1. Faux : le code s'exécute sur les serveurs du fournisseur de cloud ; tu ne les gères simplement pas.
2. Vrai, c'est l'un des principes : chaque service est seul propriétaire de ses données.
3. Faux : le découpage en couches organise le code à l'intérieur du programme ; un monolithe en couches est même la norme.
4. Vrai.
5. Vrai : après une période d'inactivité, la première exécution d'une fonction doit attendre que le fournisseur prépare son environnement.

Tu avais trouvé ?

Oui, j'avais bonPas encore