urbanisation-si.com

Le nouveau style d’architecture pour concevoir des applications informatiques, voire pour urbaniser enfin le Système d’Information de l’entreprise.

C’est le premier article d’une nouvelle série qui vise à expliquer l’Architecture Micro-Services.

Evolution de l’architecture logicielle

Tentons de résumer l’évolution de l’architecture logicielle en trois grandes étapes, forcément réductrices, qui ont mené à l’Architecture Micro-Services :

1-      Architecture monolithique

A la fin du 20e siècle, les applications informatiques développées étaient monolithiques, c.-à-d. constituées d’un seul bloc, parfois très gros. Ce qui n’empêchait pas la programmation modulaire. Seul le stockage des données, centralisé, était confié à un Système de Gestion de Base de Données (SGBD).

De nombreuses applications monolithiques sont encore en production aujourd’hui (souvent une application monolithique par domaine métier), tellement cloisonnées entre elles que l’on parle alors d’architecture en silos.

2-      Architecture Orientée Services

Au début du 21e siècle, disons vers 2005, un premier effort de partitionnement a été effectué avec l’Architecture Orientée Services (SOA), pour supporter l’avènement des processus métier et leur orchestration. Les données étaient toujours centralisées dans un SGBD.

Les solutions techniques mises en œuvre, peut-être trop lourdes (protocole SOAP et autres Web Services sur un ESB - Enterprise Service Bus), n’ont pas permis à la SOA de rencontrer le succès escompté : son usage s’est souvent limité aux gros projets dans les grandes entreprises.

3-      Architecture Micro-Services

Le terme micro-service fut utilisé pour la première fois en 2011, lors d’une conférence pour les architectes. Un des objectifs était de proposer un mécanisme de mise à l’échelle (scaling) plus performant et surtout plus flexible pour faire face à l’accroissement du nombre de visites des sites web les plus populaires (Amazon, eBay, Google, Netflix).

Au lieu de dupliquer en entier des applications monolithiques, il s’agit désormais de distribuer, et même de dupliquer, certains micro-services uniquement, sur différents serveurs. Tout en gagnant en flexibilité et en agilité, pour effectuer plus rapidement des changements, le plus souvent des améliorations.

Une application partitionnée en micro-services est plus robuste qu’une application monolithique. Un micro-service en panne ne bloque pas forcément toute l’application, qui devient alors résiliente.

C’est une évolution de la SOA (Service Oriented Architecture) : certains parlent de l’Architecture Micro-Services comme la SOA à grains fins. Elle ne remet pas en cause la SOA, mais propose des solutions techniques plus légères, souvent Open Source, comme RESTful notamment.

Principes de l’Architecture Micro-Services

C’est un style d’architecture dont l’approche est de :

- concevoir une application en une suite de petits services, appelés micro-services,
  découplés le plus possible les uns des autres,

- chaque micro-service :

• répond à une fonctionnalité métier unique,
• est simple ou moins complexe,
• est indépendant, voire autonome,
• s’exécute dans son propre processus,
• dispose de sa propre base de données,
• peut être développé dans un langage de programmation quelconque,
• communique avec un protocole léger,
• est déployable indépendamment des autres,
• est déployable de façon continue et automatisée,

- la gestion centralisée des micro-services doit être réduite au strict minimum
(service discovery, par exemple ; il s’agit d’un dispositif pour découvrir les services).

Le fait que chaque micro-service doit disposer de sa propre base de données est sans aucun doute la différence principale avec l’Architecture SOA et provoque un fort impact sur la conception.

Partitionnement et granularité

L’Architecture Micro-Service se doit de répondre à une question primordiale : Comment partitionner une application volumineuse ou le Système d’Information de l’entreprise en micro-services ? Et ce partitionnement a son pendant : quelle granularité pour ces micro-services ?

Si vous comptez sur The Open Group (l’auteur de TOGAF) pour connaitre la bonne granularité d’un micro-service, vous serez fort déçu : « les bons micro-services sont situés entre les monolithes et les nanoservices ». Nous n’osons pas reproduire ici le diagramme lapalicien associé à cette affirmation, visible à cette adresse https://www.opengroup.org/soa/source-book/msawp/p6.htm.

Le partitionnement en tant que tel ne doit pas être un objectif, mais la conséquence de l’application des principes de l’Architecture Micro-Services. La démarche à suivre sera sans doute différente selon qu’il s’agisse de refondre une application monolithique existante (et même tout le Système d’Information de l’entreprise) ou de concevoir une nouvelle application en partant d’une feuille blanche.

L’approche de type top-down, orientée décomposition, est la plus courante, mais une approche alternative de type bottom-up, orientée agrégation, n’est pas exclue. Nous reviendrons sur ce sujet crucial du partitionnement d’une application et de la granularité des micro-services.

Prochains articles

Après les principes-avantages de l’Architecture Micro-Services, que nous venons de présenter dans ce premier article, nous nous intéresserons dans le deuxième article aux :

- Considérations techniques, inconvénients et impact sur l’organisation de l’Architecture Micro-Services,

Puis nous développerons le sujet de l’Architecture Micro-Services, souvent associé à d’autres sujets plus conceptuels, déjà abordés sur ce blog (liste non exhaustive) :

- Le partitionnement d’une application et la granularité des micro-services,

- L’Architecture Micro-Services dans les cadres d’Architecture d’Enterprise (Praxeme, TOGAF),

- Les méthodes de conception de l’Architecture Micro-Services,

- La modélisation de l’Architecture Micro-Services avec UML, ArchiMate ou autres,

- L’Architecture Micro-Services et les bases de données,

- L’Architecture Micro-Services et les processus métier,

- L’Architecture Micro-Services et les règles métier,

- La gestion des API et la gouvernance des micro-services.

N’hésitez pas à poster un commentaire en cliquant sur le lien ci-dessous.

Thierry BIARD

Architecte d’Entreprise, Spécialiste EDI, BPMN et DMN, je propose mes compétences aux leaders du Transport et de la Logistique, pour mettre en place des échanges B2B efficients. J’ai fait mienne cette citation de Nelson Mandela : « Je ne perds jamais. Soit je gagne, soit j’apprends ». En fait, j’apprends plus souvent que je gagne !

« La vie ce n’est pas d’attendre que l’orage passe, c’est d’apprendre à danser sous la pluie ».