Architecture flexible : le rendez-vous avec les architectures événementielles

L'originalité de l'Architecture Flexible

L'Architecture Flexible, telle que définie ici et sur le site qui est dédié à ce concept, est d'abord une approche conceptuelle.

Elle trouve son fondement dans les chaînes de valeur, qui structurent le Business, au delà des processus, et des systèmes d'information. Le framework de la "Trame Business" explique cette structuration du Business.

Au niveau des systèmes d'information la figure de style propre à l'architecture flexible, qui lui donne toutes ses capacités, est celle du puits d'événement (ce terme est mieux adapté que celui de puits de données qui peut prêter à confusion).

C'est en combinant judicieusement puits d'événements, référentiels de données (généralement qualifiées de données maîtres d'où l’acronyme de MDM), dans le domaine étudié, que l'Architecture Flexible offre une solution innovante et pérenne. La Trame Business fournit un guide à cette analyse, lui donnant une efficacité inconnue dans les approches cantonnées au seul SI, qui peinent à définir des domaines objectifs, et stables.

Un atterrissage technique à prouver

Conceptuellement, l'Architecture Flexible peut fonctionner avec toutes technologies. En particulier, le modèle du Puits d'événement étant simple, il peut sans probléme être implanté sur une base de données classique, avec un modèle raltionnel en somme rudimentaire par rapport à celui de bien des bases existantes. De plus ce type de base est peu évolutif.

Cependant, en plaçant des Puits d'événements comme clés de voute de toutes les interactions, l'architecture technique doit être particulièrement efficace et sûre. Elle doit fonctionner en 24/7 et en temps immédiat.

De plus, il est souhaitable de pouvoir ajouter cette couche d'intelligence à moindre coût et sur des solutions "scalables".

L'émergence de nouvelles offres basées sur des "log d'événements"

L'évolution du monde de l'Open Source donne lieu à de nombreux projets, dont certains répondent aux besoins des entreprises natives de l'internet, typiquement confrontées aux grosses volumétries, aux multiples interactions, et un écosystème nativement événementiel.

Grosso modo, l'organisation des données a toujours été séparée en deux phases : celle de l'enregistrement et de mise en forme et celle de l'utilisation. C'était déjà le cas dans l'ancien temps, avec les registres de naissance par exemple, qui nécessitaient un gros travail manuel de préparation pour rendre les recherches faciles. Avec les bases de données, l'accent est mis sur la structuration sur des dimensions de recherche, ce qui en complique grandement la gestion. Avec les technologies traditionnelles, c'était le prix à payer pour rendre les bases de données exploitables. Avec la technologie actuelle, la performance des recherches permet d'imaginer des bases où la préparation est minimaliste. Ceci rendra probablement les bases classiques obsolètes... Sans pour autant dévaluer les vertus du modèle relationnel, des travaux sur la qualité des données, ... bref tout un acquis qui n'est pas à remettre en cause dans le monde dit "de la gestion".

De fait, le modèle technique qui tend à s'imposer est celui des "log d'événements immuables" : c'est justement le modèle des faits invariants défini pour les puits d'événements. Pour une argumentation convaincante sur ce nouveau modèle voir le long et lumineux article de Martin Leppmann : "Turning the data base inside-out with Apache Samza".

Les experts des micro-services, confrontés à la réalité de l'entropie naturelle, imaginent des architectures, dans une démarche "bottom-up". Ces démarches convergent de façon flagrante avec l'approche "top-down" de l'Architecture Flexible. Lire en particulier l'article très clair de Chritian Posta : "The hardest part about microservices : your data".

Une convergence nécessaire

Le schéma central de l'article de C. Posta correspond avec le type d'organisation de SI ciblé par l'architecture Flexible :

On voit bien qu’il y a coexistence de base « classiques » sur SQL et d’autres de type Elastic Seach.

Cet "event log" correspond bien à un « puits d’événements ». Il est instancié sur Apache Kafka.

Tout les avantages de la "promesse" de l'architecture Flexible sont repris par C. Pasta, avec un vocabulaire plus concret et technique :

This comes with some great advantages:

• we avoid expensive, potentially impossible transaction models across boundaries
• we can make changes to our system without impeding progress of other parts of the system (timing and availability)
• we can decide how quickly or slowly we want to see the rest of the outside world and become eventually consistent
• we can store the data in our own databases however we’d like using the technology appropriate for our service
• we can make changes to our schema/databases at our leisure
• we become much more scalable, fault tolerant, and flexible

Notably, this comes with disadvantages:

• it’s more complicated
• difficult to debug
• since you have a delay when seeing events, you cannot make any assumptions about what other systems know (which you cannot do anyway, but it’s more pronounced in this model)
• more difficult to operationalize
• you have to pay even more attention to CAP Theorem and the technologies you chose to implement your storage/queues

A noter que ne mettre en place que Apache Kafka, sans formaliser le log, n’a aucun intérêt : l’architecture repose certes sur la techno mais aussi sur la conception. Tant que les événements sont noyés dans des batchs il n’y a rien de possible ! Sans parler de la tri-datation. Il faut reconstituer un flux événementiel, souvent effacé par la mise en base de données. Par ailleurs, l’article montre bien que cette architecture, en organisant la division en domaines autonomes (mais interdépendants via le log), simplifie l’ensemble.

Il y a bien convergence, et possibilité d'enrichissement mutuel, entre ces approches.