Les Microservices

Style d'architecture qui structure un système autour de services légers et faiblement couplés

Caractéristiques

• Responsabilité business unique
• Forte cohésion
• Couplage faible
• Autonomes

Quels avantages ?

• Système plus modulaire
• Indépendance dans le déploiement
• Facilitent le scaling
• Solutions adaptées à chaque situation
• Réecriture partielle possible
• Équipes autonomes

Les challenges

• Les frontières d'un µS
• La communication
• La gestion des transactions

Découpage technique

Manque de cohésion

Un changement dans un µS

nécessite des modifications dans d'autres µS

Déployer un µS

nécessite le déploiement d'autres µS

Le même développeur intervient sur plusieurs µS

aboutit à un

monolithe distribué

Services par entité

Héritage du SOA

Couplage sémantique

Besoin de connaître les versions des services avec lesquelles on est compatible

Crée des bottlenecks

Gestion complexe des transactions

en two phases commit

La disponibilité du système dépend de la quasi totalité des µS

Loi de conway

Comment assurer une meilleure cohésion de chaque service ?

Un µS est responsable d'un ensemble de comportements

Besoin d'un modèle adapté

Aussi simple que possible

Comment construire ce modèle ?

Explorer l'espace du problème

et collaborer beaucoup plus avec les experts du domaine métier

Cesser de tout modéliser sous la forme de données

S'approprier le langage des experts du domaine

le structurer, le compléter, identifier les nuances...

Les Bounded Contexts

Bornes d'un bounded context

=

Bornes d'un µS

Bonne piste, mais pas systématique

Comment faire ?

Agrégats

Définit les bornes d'une transaction

c'est une unité de consistance transactionnelle

Cluster d'objets

composé d'entités

et de value objects

Garantit la cohérence de l'ensemble

en contrôlant les invariants

expose une collection de traitements métiers

à travers la racine de l'agrégat

Définit une unité de distribution

les objets liés le reste, et leur cohérence est assurée

Bornes d'un agrégat

=

Bornes d'un µS

Modes de communication

Shared database

RPC / synchrone

Messaging / asynchrone

Shared database

Couplage au build

Couplage au deploy

Couplage au runtime

Shared mutable state is the root of all evil

Henrik Eichenhardt

http://henrikeichenhardt.blogspot.fr/2013/06/why-shared-mutable-state-is-root-of-all.html

Communications synchrones

solution la plus maitrisée

reproduit les mécanismes de communication des monolithes...

...sur un réseau non fiable

augmente le niveau de dépendance aux autres services

perte d'autonomie

Messaging

découple les services par inversion de contrôle

redonne de l'autonomie aux services

rend les services plus tolérants à l'erreur

change le modèle de consistance

ACID

Eventual Consistency

Les Domain Events

Les événements existent partout dans le domaine

Moyen de communiquer

Permettent de faire du contrôle de cohérence

Prennent la forme de value objects...

...communiqués au monde extérieur

exemples

ProductPurchased

OrderShipped

MoneyWithdrawn

TransferCompleted

Event driven architecture

Choregraphy over orchestration

Event Storming

Emergence...

• Ubiquitous Language
• Bounded Contexts
• Chorégraphie

Contrats

Quelles sont les dépendances entre µS ?

Quel service impose aux autres son modèle ?

Comment assure-t-on la compatibilité entre services ?

Comment coordonne-t-on le développement et le déploiement des services ?

Context mapping

pas un diagramme de flux

Diagramme d'influence

upstream et downstream

Types de relation

• Partnership
• Customer - Supplier
• Conformist
• Anti Corruption Layer
• Shared Kernel
• ...

Le pattern utilisé influence...

...les contrats d'interface

Commandes définit ses attentes à Catalogue Produits

...la synchronisation des backlogs

Les besoins de Commandes impacte le backlog de Catalogue Produits

...le mode de communication des équipes

...la synchronisation des déploiements

Commandes peut être déployé indépendamment de Clients

décrit la situation actuelle

documente la façon dont les contextes influent les uns sur les autres

documente la façon dont les µS doivent communiquer

Quoi retenir ?

Votre capacité à bien faire des µS dépend de votre capacité à bien faire des monolithes

Faites du monolith-first !

Et passez en µS lorsque leurs bornes seront évidentes

Sortez de l'espace de la solution,

et explorez l'espace du problème

Essayez les ateliers d'Event Storming

Soyez clairs et explicites sur le langage utilisé

Identifiez des contextes bornés candidats

Pensez comportements

plutôt que data

Expérimentez le context mapping

Considérez les architectures event-driven et le messaging

CQRS

Event Sourcing

Persistance de l'historique des événements

Les événements deviennent la source de vérité

pour reconstituer l'état

Source de données immutable

en append only

Commande "Ajouter une carotte au pot au feu 42"

Commande "Ajouter une carotte au pot au feu 42"

Commande "Ajouter 2 choux au pot au feu 42"

Commande "Ajouter une carotte au pot au feu 42"

Commande "Retirer une carotte du pot au feu 42"

Commande "Ajouter une carotte au pot au feu 42"

Commande "Ajouter 2 choux au pot au feu 42"

Commande "Ajouter une carotte au pot au feu 42"

Commande "Retirer une carotte du pot au feu 42"

Testabilité (immutabilité)

Versioning d'agrégats

Debugging et reproductibilité

Rollback facilité

Et non ! pas en supprimant le dernier event !

Traçabilité offerte

Recomposer des projections à la demande