Data driven

Les difficultés posées par les Microservices 1/2

24 janvier 2018

La première difficulté pour ceux qui se lancent dans les Microservices : quelles granularités pour mes Microservices ?

Une question très structurante lorsque l’on souhaite diviser une application monolithe en Microservices est de déterminer la bonne « granularité » des Microservices, c’est à dire leur bonne taille. La taille d’un Microservice correspond au périmètre fonctionnel qu’il couvre, c’est-à-dire : les fonctionnalités ou les cas d’utilisation qu’il implémente.

Déterminer la granularité des Microservices est un sujet qui est complexe et très lié au contexte de l’application (organisation, domaine métier, contexte technologique, …). Il est peu probable que la granularité des Microservices reste stable dans le temps.

Des Microservices trop gros ne permettront pas d’atteindre l’agilité recherchée.

Ce qui freinera alors l’agilité :

  • Chaque Microservice ne pourra plus être maintenu par une seule équipe agile (8 personnes max)
  • Ils ne seront plus aussi évolutifs : leur refonte ou leur réécriture complète représentera un investissement trop important pour que cela puisse être envisagé
  • Chaque Microservice ne sera pas centré sur une seule et unique fonctionnalité et, on perdra alors en modularité

Des Microservices trop petits posent d’autres problèmes.

On parle alors de Nanoservices lorsque la granularité des Mircroservices est trop fine et que leur utilité ne compense pas tous les problèmes et difficultés qu’ils posent.

Car des services plus petits impliquent des services plus nombreux et donc :

  • Plus d’échanges réseau et potentiellement des problèmes de performances dus à la latence du réseau
  • Des problèmes d’exploitabilité (trop de services à monitorer et surveiller pour les exploitants
  • Difficultés pour gérer la consistance et la cohérence globale du système (chaque service est autonome même en ce qui concerne ses données).

La méthode Domain Driven Design est une méthode de conception qui est adaptée à la problématique du découpage d’une application monolithe en Microservices. Nous reviendrons plus en détail sur cette méthode et sur ce qu’elle peut apporter dans une démarche active pour améliorer son Time To Market.

Les difficultés à surmonter pour passer aux Microservices : le prix à payer pour bénéficier de l’agilité

Les Microservices apportent une forte complexité et se révèlent donc coûteux à mettre en œuvre.

Une architecture Microservices est une architecture fortement distribuée sur le réseau. Tout le monde a déjà fait l’expérience que le réseau est lent et peu fiable : il représente donc la première difficulté que l’on doit surmonter lorsque l’on souhaite passer aux Microservices.

Le réseau n’est pas fiable et peut connaitre des pannes (plus ou moins temporaires) à tout moment : tout échange à travers le réseau a une probabilité non négligeable de ne pas aboutir. La mise en place d’une architecture avec un grand nombre de composants communiquant à travers le réseau impose alors de mettre en place une gestion fine et complexe des erreurs qui peuvent se produire lors des échanges sur le réseau.

Dans le prochain article, nous approfondirons le sujet de la gestion des erreurs et des pannes dans une architecture Microservices.

 

Illustrations : Sandy Malosse

6è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