Contenu
Dans les épisodes précédents de cette série, nous avons exploré les étapes fondamentales pour établir un projet serverless, notamment la mise en place d'un environnement de développement avec des outils d'émulation et la définition d'une architecture multi-niveaux générale. Ce segment se concentre sur la mise en œuvre de modèles de conception adaptés au développement d'un système serverless respectant le paradigme Function as a Microservice (FaaM). \n\nLa question de la granularité des services a évolué avec l'histoire de l'informatique distribuée. Dans les années 1970 et 80, les premières approches d'intégration telles que les appels de procédure distante (RPC), CORBA et l'environnement de calcul distribué (DCE) ont émergé, mais étaient souvent limitées en scalabilité et flexibilité pour les environnements hybrides. Le milieu des années 1990 a marqué un tournant avec l'avènement de l'architecture orientée services (SOA), qui a gagné en importance au début des années 2000 via des implémentations basées sur SOAP. SOA a révolutionné la conception logicielle en permettant des services faiblement couplés. L'évolution a continué dans les années 2010 avec REST, les architectures pilotées par événements (EDA) et les microservices, mais un défi persiste : déterminer la taille et la portée idéales d'un service.\n\nHistoriquement, SOA définissait deux principaux types de granularité de service : grossière et fine. Les services grossiers englobent de larges capacités métier, tandis que les services fins se concentrent sur des fonctions étroitement ciblées. Les deux extrêmes posent des défis ; les services grossiers risquent de devenir des « monolithes » ingérables, tandis que les services fins peuvent produire un nombre écrasant de petits composants interdépendants, compliquant la scalabilité, la modifiabilité et la sécurité. Le cadre de modélisation orientée services (SOMF) propose des catégories nuancées : les services atomiques sont des composants de base indivisibles avec des processus limités ; les services composites agrègent des services atomiques ou autres services composites en structures hiérarchiques ; et les clusters sont des groupes de services liés collaborant vers des solutions plus larges.\n\nLa traduction de ces concepts dans le domaine du serverless avec Serverless Framework et AWS Lambda implique la compréhension de trois constructions centrales : Événements, Fonctions et Services. Les événements déclenchent les fonctions, qui exécutent des morceaux de code discrets accomplissant des tâches spécifiques. Les services encapsulent des groupes de fonctions Lambda avec leurs événements déclencheurs et exigences d'infrastructure. Le Serverless Framework recommande généralement de créer des fonctions Lambda individuelles pour chaque opération CRUD — impliquant qu'une entité comme Utilisateur pourrait correspondre à quatre fonctions Lambda. Bien que simple, cette approche évolue mal : dix entités conduisent à 40 fonctions, chacune nécessitant gestion et associée à des instances API Gateway AWS distinctes, augmentant la charge opérationnelle.\n\nPour gérer cette complexité, le modèle Function as a Microservice (FaaM) est proposé. Ici, chaque fonction Lambda agit comme un petit cluster, gérant plusieurs capacités métier liées et routant divers événements atomiques en interne. Par exemple, plutôt qu'une fonction par opération de ville, une fonction de géolocalisation gère collectivement les opérations CRUD pour pays, villes et régions. Pour éviter l'encombrement monolithique, chaque fonction devrait idéalement gérer au maximum 7±2 entités, conformément aux limites cognitives décrites par la loi de Miller. Ce design suppose que chaque fonction maintient la responsabilité exclusive de sa source de données spécifique.\n\nLa mise en œuvre de FaaM dans AWS Lambda nécessite des mécanismes de routage efficaces, étant donné la contrainte qu'une fonction Lambda dispose d'un seul gestionnaire d'entrée. Un modèle Client-Dispatcher-Server peut faciliter cela en dirigeant les requêtes entrantes selon leurs chemins URI. Par exemple, une requête HTTP vers /movie devrait être routée vers la fonction pertinente gérant les opérations liées aux films. Avec ce modèle, plusieurs services logiques — tels que utilisateurs, géolocalisation et publications — peuvent partager le même code gestionnaire mais différencier le traitement en interne via le routage. Cette approche réduit le nombre de fonctions Lambda et de points d'entrée API Gateway, simplifiant la gestion tout en préservant des frontières claires entre domaines métier.\n\nEn pratique, la configuration Serverless Framework pourrait définir plusieurs services avec plusieurs événements HTTP pointant tous vers le même gestionnaire — par exemple, les points de connexion login, logout et signup sous utilisateurs, divers points de localisation sous géolocalisation, et les opérations CRUD pour films sous publications. La logique de routage à l'intérieur du gestionnaire partagé inspecte l'URI et la méthode de l'événement pour invoquer le module de logique métier approprié. Cette stratégie améliore la maintenabilité en évitant la répétition du code gestionnaire et permet une croissance modulaire au sein des architectures serverless.
