Data driven

Le Time To Market : les difficultés posées par les Microservices (2/2)

14 février 2018

Nous abordons dans cet article, le sujet de la résilience d’une architecture Microservices, c’est-à-dire, sa capacité à fonctionner en cas de panne.

Dans un Système Distribué, une erreur sur un seul composant peut potentiellement se propager à tout le Système (par erreurs en cascades).

Prenons un exemple pour illustrer ce problème :
– Un composant C appelle un composant A
– Le composant A appelle le composant B qui ne répond pas car en panne (ou panne réseau)
– Le composant A est donc bloqué car en attente d’une réponse du composant B
– Les appels du composant C vers le composant A s’accumulent peu à peu au niveau du composant A … jusqu’à ce que le composant A soit surchargé et tombe lui-même en panne
– De la même façon, le composant C accumule les requêtes en attente vers le composant A jusqu’à tomber lui-même en panne
– Et ainsi de suite, les appels en cascade font se propager une panne à tout le Système

L’exemple ci-dessus montre une première limite des communications synchrones dans un système fortement distribué.

La latence du réseau est une autre limite des communications synchrones dans un système fortement distribué : le réseau est lent par essence et cette latence pose très vite des problèmes lorsque le nombre de communications augmente.

Le choix des échanges asynchrones permet un découplage temporel dans les communications entre les Microservices qui augmente la tolérance aux pannes du système, minimise les impacts de la latence du réseau et renforce l’isolation entre les Microservices. On parlera alors d’Event Driven Architecture ou Architecture Reactive.

Ces architectures sont plus complexes à mettre en œuvre que des architectures classiques basées sur des communications synchrones.

La gestion de pannes et des erreurs de communication entre les Microservices est un sujet qui n’est jamais trivial et qu’il ne faut pas traiter à la légère : c’est un sujet très structurant et crucial qui doit être instruit avec soin dès la phase de conception.

On peut définir plusieurs niveaux de tolérance aux pannes pour un Système Distribué :
– Un système est dit Fragile lorsqu’il ne peut plus fonctionner en cas de panne
– Un système est dit Robuste lorsqu’il s’adapte et peut continuer à fonctionner (éventuellement en mode dégradé) en cas de panne prévue
– Un système est dit Résilient lorsqu’il a la capacité de continuer à fonctionner en cas de panne prévue et imprévue
– Un système est dit Antifragile lorsqu’il a la capacité de continuer à fonctionner en cas de panne prévue ou imprévue et que chaque panne le rend plus robuste. Un système Antifragile se renforce en cas de panne.

Dans une Architecture Microservices, il est conseillé de viser au minimum un système résilient car, le grand nombre d’échanges réseaux et la complexité de ces échanges augmentent le risque d’erreurs ou de pannes imprévues.

Pour garantir la résilience du Système, on sera alors amené à aborder des concepts tels que :

  • Design for Failure : mode de conception qui intègre les défaillances et les pannes comme le mode normal de fonctionnement. On ne cherche pas à prévenir et éviter les défaillances mais, à fonctionner avec.
  • Crash-Only Software : logiciel dont le mode de fonctionnement unique est le crash. Le seul mode d’arrêt est le crash et le seul mode de démarrage est la récupération suite à un crash.
  • Gracefull Degradation : offre à l’utilisateur un mode de fonctionnement dégradé en cas de panne (au lieu de l’arrêt complet du service rendu).
  • Circuit Breaker : équivalent logiciel du coupe circuit de l’électricien. Lors de communications synchrones entre Microservices, il permet de ne plus router les requêtes vers un Microservice qui serait tombé en panne ou qui répondrait avec trop de latence. Cela permet d’éviter que la lenteur ou la panne d’un seul Microservice se propage à tout le Système (erreurs en cascades).
  • Idempotence : une requête idempotente est une requête qui aura exactement le même effet sur le Système si on l’envoie une seule fois ou si on la rejoue plusieurs fois.

Microservices

 

 

Les Microservices sont fortement distribués et sont complètements autonomes pour gérer la persistance de leurs données : il faut alors abandonner la notion de transaction et leurs propriétés ACID (Atomicité, Consistance, Isolation et Durabilité).

On ne peut plus garantir la cohérence et la consistance globale du système à chaque instant : on parle alors d’Eventually Consistency, c’est à dire que le système peut se trouver dans un état global incohérent à un instant donné mais, on garantit que ce système reviendra dans un état cohérent plus tard.

Les autres difficultés à surmonter dues à la forte distribution des architectures Microservices sont :

  • L’exploitation et la gestion des infrastructures : le grand nombre de Microservices rend impossible la gestion manuelle de l’infrastructure par les équipes d’exploitation. Il faut automatiser et outiller les tâches relatives à la création et la surveillance des infrastructures.
  • La gouvernance du SI : le nombre important des Microservices, la forte autonomie des équipes de développement sur le périmètre d’un Microservice et la vitesse des évolutions et l’hétérogénéité technologique que permettent les Microservices rendent très compliquée la gouvernance du SI par les Architectes d’Entreprise.
  • La gestion des compétences et expertises techniques : l’hétérogénéité technologique que permettent les Microservices ont un impact sur la culture des équipes de développement. Celles-ci doivent accepter de travailler dans un environnement technologique mouvant et s’adapter.
  • La dilution des données dans le SI
  • Les impacts sur l’organisation de l’entreprise : pour que les Microservices apportent l’agilité promise, il est primordial que l’on adapte son organisation en conséquence (loi de Conway : « une organisation ne peut produire que des Systèmes qui vont refléter sa structure et son mode de fonctionnement »).

Dans le prochain article, nous traiterons de la trajectoire pour transformer ses applications en Microservices.

Illustrations : Sandy Malosse

7ème billet d’une série d’articles décrivant comment l’architecture logicielle est un levier d’optimisation du Time To Market :

  1. Le Time To Market : un enjeu stratégique
  2. Le Time To Market : les applications monolithes
  3. Le Time To Market : Microservices vs Applications Monolithes
  4. Le Time To Market : caractéristiques des Microservices
  5. Le Time To Market : Microservices et agilité
  6. Le Time To Market : les difficultés posées par les Microservices (1/2)
  7. Le Time To Market : les difficultés posées par les Microservices (2/2)
  8. Le Time To Market : une trajectoire pour la mise en œuvre de Microservices

Newsletter

Inscrivez-vous à notre newsletter pour recevoir nos dernières actualités*

Les informations recueillies sur ce formulaire sont enregistrées dans un fichier informatisé de gestion des Clients et Prospects (CRM).

Le Responsable de traitement est la société weave, 37 rue du rocher 75008 Paris RCS Paris 802 396 085.

Elles sont destinées à l’activité marketing du groupe weave ainsi quà celle de ses filiales, à l’exclusion de tout transfert hors de l’UE. Elles sont conservées pour une durée conforme aux dispositions légales (par exemple 3 ans pour les données prospects).

Ce traitement nécessite votre consentement que vous pourrez retirer à tout moment sans que cela ne remette en cause sa licéité.

Conformément à la loi « Informatique et Libertés » et au règlement européen n°2016/679, vous bénéficiez d’un droit d’accès, de rectification ou d’effacement, ainsi que d’un droit à la portabilité de vos données ou de limitation du traitement. Vous pouvez également pour des raisons tenant à votre situation particulière, vous opposer au traitement de vos données et donner des directives relatives à la conservation, à l’effacement et à la communication de vos données après votre décès. Vous disposez également du droit d’introduire une réclamation auprès de la Commission Nationale de l’Informatique et des Libertés (www.cnil.fr).

Vous pouvez exercer vos droits en nous contactant à l’adresse vosdonnees@weave.eu.

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour mesurer notre audience, vous proposer des contenus et des offres personnalisées, ainsi que des fonctionnalités de partage sur les réseaux sociaux. En savoir plus sur notre politique de cookies et notre charte des données personnelles