Architecture à base de services et architecture orientée services

Entre le monolithe et les microservices

Une grande partie des discussions du secteur présente un choix entre un seul monolithe et de nombreux microservices. En pratique, une large part des systèmes réels se situent entre les deux : une poignée de services déployés séparément, chacun couvrant tout un domaine d’activité, qui partagent souvent encore une même base de données. Mark Richards et Neal Ford ont nommé ce style architecture à base de services dans Fundamentals of Software Architecture et soutiennent qu’il s’agit de l’un des styles distribués les plus pragmatiques qui soient. Cette section le décrit, l’oppose à l’architecture orientée services (SOA), plus ancienne, avec laquelle on le confond souvent, et montre en quoi les microservices diffèrent de l’une comme de l’autre.

L’architecture à base de services : la topologie

Un système à base de services comporte trois parties. Une ou plusieurs interfaces utilisateur appellent un ensemble de services de domaine déployés séparément, chacun couvrant un domaine d’activité vaste et cohérent, comme les commandes ou les paiements. Richards et Ford observent que ces systèmes comptent généralement entre 4 et 12 services de domaine, environ 7 en moyenne. Les services partagent le plus souvent une base de données, et une couche API facultative (un reverse proxy ou une gateway) peut s’intercaler entre les interfaces utilisateur et les services pour gérer le routage, l’authentification et la limitation de débit.

Chaque service de domaine est à gros grain : il contient tout ce qu’il faut pour son domaine, de l’API à la logique métier et à l’accès aux données, et il est structuré en interne comme un petit monolithe, souvent en couches ou en modules (chapitre 5). Un service est généralement déployé sous la forme de quelques instances derrière un équilibreur de charge.

Deux conséquences en découlent. Premièrement, la plupart des workflows métier s’exécutent entièrement à l’intérieur d’un seul service : ils peuvent donc utiliser une transaction de base de données locale ordinaire, avec toutes les garanties ACID (chapitre 0). Deuxièmement, les services de domaine ont rarement besoin de s’appeler entre eux : une requête issue de l’interface utilisateur va au seul service propriétaire du domaine. Cela garde les chaînes synchrones courtes, ce qui compte pour les raisons calculées à la section 6.1.

La base de données partagée et comment la maîtriser

Partager une base de données est ce qui rend l’architecture à base de services économique et simple : pas de synchronisation des données entre services, pas de cohérence à terme, des rapports en SQL ordinaire. C’est aussi sa principale faiblesse. Si chaque service lit et écrit les mêmes tables, une modification des colonnes d’une table peut casser plusieurs services, qui doivent alors tous être testés et redéployés ensemble. La définition du chapitre 5 s’applique : des services qui partagent une base de données sont liés en un seul quantum d’architecture, si bien qu’ils partagent un même niveau de disponibilité et un même rythme de publication du schéma.

Les praticiens utilisent trois techniques pour réduire ce couplage. La première est le partitionnement logique : donner à chaque service son propre schéma (ou ensemble de tables) et lui interdire de toucher à ceux des autres, en faisant respecter cette règle par les permissions de la base de données autant que par convention. La deuxième consiste à placer les classes d’entités de la base partagée dans de petites bibliothèques par domaine plutôt que dans une grande bibliothèque partagée, afin qu’une modification des tables des restaurants n’affecte que les services qui les utilisent. La troisième consiste à donner à un service sa propre base de données quand il a une raison forte, comme un périmètre de sécurité, un profil de charge très différent ou un type de stockage de données différent. Les équipes qui appliquent ces techniques de façon systématique constatent qu’un passage ultérieur à des bases de données séparées, s’il devient un jour nécessaire, est bien plus facile.

L’architecture orientée services classique

L’architecture orientée services est plus ancienne et plus large. Le terme est entré dans le secteur par un rapport du Gartner de 1996 signé Roy Schulte et Yefim Natis, et à partir du début des années 2000 il est devenu le modèle dominant de l’intégration d’entreprise. Son idée centrale était saine : exposer les capacités métier sous forme de services dotés de contrats explicites et indépendants de la technologie, afin que les applications d’une grande organisation puissent être assemblées à partir d’eux au lieu d’être reconstruites ou intégrées de point à point.

Ce que la plupart des entreprises ont réellement construit, cependant, c’est ce que Richards et Ford appellent la SOA pilotée par l’orchestration. Les services étaient organisés en couches techniques : des services métier décrivant des processus (passer commande, ouvrir un compte), des services d’entreprise partagés fournissant des capacités réutilisables (client, tarification, facture), et des services applicatifs et d’infrastructure enveloppant les systèmes existants et les préoccupations techniques. Au centre se trouvait un bus de services d’entreprise (ESB) : un middleware qui acheminait les messages, les transformait d’un format à un autre, servait d’intermédiaire entre les protocoles et, au moyen d’un moteur d’orchestration, exécutait lui-même les processus métier.

Deux autres idées complétaient le tableau. Un modèle de données canonique définissait une représentation unique, à l’échelle de l’entreprise, de chaque entité métier (un seul Customer, un seul Order), et chaque message était traduit vers ce modèle et depuis ce modèle dans le bus. Et une famille de standards de services web, généralement appelée WS-*, définissait comment les services se décrivaient et s’appelaient : SOAP pour les messages, WSDL pour les descriptions d’interface, UDDI pour les registres, WS-Security, WS-ReliableMessaging et WS-AtomicTransaction pour les qualités, et WS-BPEL (version 2.0 approuvée par OASIS en 2007) pour les définitions de processus exécutables.

Pourquoi la SOA classique est tombée en disgrâce

À la fin des années 2000, beaucoup de programmes SOA avaient déçu. Anne Thomas Manes, du Burton Group, a saisi l’état d’esprit du moment dans un billet très lu de janvier 2009 intitulé SOA is Dead; Long Live Services : l’étiquette était devenue toxique, mais l’idée de services avait survécu. Les raisons méritent d’être connues, car chacune est un piège dans lequel les architectures modernes peuvent retomber.

La réutilisation a créé du couplage. Un service d’entreprise Customer partagé, utilisé par quarante applications, ne pouvait pas changer sans l’accord de quarante consommateurs ; la réutilisation, l’objectif principal, transformait chaque changement en négociation. Le bus est devenu le goulet d’étranglement. Placer la logique de routage, de transformation et de processus dans un ESB central, généralement détenu par une seule équipe d’intégration, signifiait que presque chaque changement métier avait besoin de cette équipe, et le bus est devenu un point unique de défaillance et de retard. Le modèle canonique était trop gros. Une définition unique de Customer qui satisfasse les ventes, la facturation, le support et la logistique est soit énorme, soit inadaptée à la plupart d’entre eux ; les contextes délimités du chapitre 5 expliquent pourquoi un terme peut légitimement signifier des choses différentes dans différentes parties d’une entreprise. Les standards étaient lourds. Les spécifications WS-* étaient complexes, l’outillage coûteux, et les transactions distribuées entre services se sont révélées fragiles. Le partitionnement technique faisait qu’une fonctionnalité simple traversait plusieurs couches de services détenues par des groupes différents.

Les leçons durables sont celles sur lesquelles les microservices ont été bâtis : des contrats de service explicites, des services détenus par ceux qui les construisent, la logique dans les services plutôt que dans le middleware, et des données détenues par un seul service plutôt que partagées dans toute l’entreprise.

En quoi les microservices diffèrent

Les microservices, traités en détail dans la section suivante, conservent l’idée de la SOA de services dotés de contrats explicites et inversent la plupart de ses choix de mise en œuvre. James Lewis et Martin Fowler ont résumé l’un de ces renversements par la formule smart endpoints and dumb pipes (des extrémités intelligentes et des tuyaux simples) : le réseau ne fait que transporter les messages, et toute la logique vit dans les services. Les services s’organisent autour des capacités métier plutôt que de couches techniques, la réutilisation passe délibérément après l’indépendance, chaque service est propriétaire de ses données, et la gouvernance est décentralisée.

Par rapport à l’architecture à base de services, les microservices sont à grain plus fin, bien plus nombreux, et exigent des données séparées. Cela apporte davantage d’indépendance, une mise à l’échelle plus ciblée et une meilleure isolation des pannes, et cela coûte beaucoup plus en exploitation, en cohérence et en coordination. L’architecture à base de services peut être vue comme le point du spectre où arrivent la plupart des avantages liés au déploiement et aux équipes, pour une fraction du coût.

Quand l’architecture à base de services est le juste milieu pragmatique

Choisissez-la quand le système compte quelques domaines métier clairs, quand deux à peut-être huit équipes doivent mettre en production indépendamment, quand la plupart des workflows restent naturellement à l’intérieur d’un domaine, et quand une cohérence forte au sein d’un domaine a de la valeur. C’est aussi une excellente étape de migration pour sortir d’un monolithe : découper un monolithe bien modularisé en une poignée de services de domaine est bien moins risqué que de sauter directement à cinquante microservices, et le résultat est souvent assez bon pour s’arrêter là.

Évitez-la, ou prévoyez de la dépasser, quand des parties d’un domaine ont besoin d’une scalabilité ou d’une disponibilité très différentes (elles relèvent de quanta séparés), quand des dizaines d’équipes ont besoin d’autonomie, quand la base de données partagée est devenue le goulet d’étranglement des écritures, ou quand les services de domaine ne cessent de s’appeler entre eux pour traiter des requêtes ordinaires, signe que les frontières sont mal placées.