Publié par

Il y a 5 ans -

Temps de lecture 7 minutes

Microxchg : un résumé du premier jour

Measuring microservices (par Richard Rodger)

Pour mesurer l’état de santé du corps, on ne mesure généralement pas les échanges ioniques des globules rouges mais plutôt des propriétés inhérentes au système dans sa globalité, la pression artérielle, le rythme cardiaque.

Comment trouver les bonnes métriques pour un système de microservices ? Richard Rodger souhaite nous partager son expérience. Plutôt que de considérer le système comme un ensemble d’entités s’échangeant des messages, il préfère l’étudier sous la forme de messages échangés entre entités. Petite différence syntaxique mais elle met en valeur l’élément important, le message.

Petit point d’attention : le monde des microservices compte beaucoup sur le monitoring pour assurer le bon fonctionnement au global en production. Il faut alors avoir un système de monitoring qui soit ENCORE plus disponible que le système lui-même !

Les architectures orientées messages sont bien connues et identifiées. Il existe plusieurs patterns comme Actor, Publish/Subscribe, Chain ou encore Tree. À chaque pattern correspond une dynamique. Par exemple, un Actor est vu comme une fonction qui, à partir d’un message en produit un autre, il y a un ration 1/1. Pour un pattern pub/sub, pour un message entrée il devrait y avoir N messages en sortie, où N est le nombre de subscribers. C’est un ratio 1/N.

Mesurer ce ratio permet d’avoir une vue de l’état de santé du système. Perd-il des messages ? Va-t-il s’emballer ? Il prend l’exemple d’un site de e-commerce, 1 message de passage de commande = 1 message de tax = 1 message d’envoi.

Son conseil : n’apprenez ni Go, ni Swift cette année, apprenez plutôt TLA + de Leslie Lamport. C’est un outil de preuve formelle pour les systèmes distribués, notamment utilisé chez Amazon. Il faut porter son attention sur ce qui doit être tout le temps vrai, les invariants du système, plutôt que de tenter de voir ce qui semble faux.

Building Event-Driven Microservices with Scala, Functional Domain Models and Spring Boot (par Chris Richardson)

Chris Richardson est entre autre l’auteur du site http://microservices.io/. Il nous présente aujourd’hui une architecture qui vient de plus en plus sur le devant de la scène : Scala + Docker + CQRS + EventSourcing.

Chris dresse une liste des défauts d’un système monolithique :

  • Il intimide et effraie les nouveaux développeurs.
  • C’est un obstacle au déploiement fréquent.
  • Mettre trop de contraintes divergentes dans le même système le sclérose.
  • Le système s’englue dans ses frameworks.

Il nous dresse également les problématiques et les limites des bases de données sur les sujets de :

  • la scalabilité,
  • la distribution de la charge,
  • la mise à jour des schémas.

A partir de ces analyses, Chris nous propose l’approche évènementielle. En se basant sur le livre The art of scalability, de Martin L. Abbott et Michael T. Fisher, il nous indique qu’il faut se concentrer sur l’axe Y : « Functional Decomposition ».

C’est un terme qui a été cité des dizaines de fois. Le découpage se fait avant tout en suivant les problématiques métiers.

Chaque module ou microservice possède sa propre source de données et en est maître. Dans une approche classique, il est difficile d’assurer une cohérence à travers plusieurs sources de données sans transaction distribuée.

La réponse qui vient est alors l’EventSourcing. Cette technique, qui consiste à ne pas stocker l’état d’une entité mais la liste des événements immuables qui composent son cycle de vie, apporte plusieurs réponses. Elle est orientée message, immuable et facilite la programmation concurrente et asynchrone. Chris nous met en garde sur le fait que la gestion d’évènements est compliquée. En effet, gérer des évènements dupliqués ou bien encore la consistance des données (le temps que les évènements soient bien propagés) peuvent s’avérer des challenges.

Le problème d’un EventStore est qu’il ne permet que d’accéder aux éléments par clé primaire. C’est alors que CQRS apporte une autre réponse. La séparation des logiques de traitements (commands) et de vues (queries) permet de construire des vues ad-hoc, adaptées à chaque besoin. Il n’y a plus de modèle universel. Chaque besoin est alors adressé par une réponse technique ajustée au plus juste.

Hybris-as-a-service

Andrea Stubbe nous présente le projet qu’elle porte chez Hybris, YaaS, ou Hybris-as-a-service. Hybris souhaite lancer un nouveau produit. L’idée est intéressante : établir un « marketplace » pour des API services ou microservices.

YaaS est une plateforme qui permettra à tout un chacun de chercher des APIs, déclarer les siennes et les monétiser. Mais YaaS n’est pas un PaaS ni un IaaS. Il sert avant tout d’annuaire et de moyen d’authentification.

La définition des services est basée sur RAML.

Microservice challenge (par Fred George)

Fred George est connu pour être l’initiateur d’un mouvement post-agile, « Developer Anarchy ». Ce mouvement préconise de tout mettre en place dans l’entreprise pour que le développeur ou l’équipe légitime et libre, de l’idée à son exploitation au travers d’un produit. C’est l’idée des équipes autonomes poussée à l’extrême.

Pourquoi les architectures microservices émergent-elles maintenant ?

C’est pour lui la conjonction d’innovations technologiques (langages, frameworks) mais aussi d’un changement de contexte économique (l’émergence de startups grandissantes partout dans le monde).
Cependant, ce type d’architecture n’est pas sans défi à relever. Voici la liste des challenges qu’il faut s’attendre à résoudre avant de s’y lancer.

Challenge 1 : Synchronous vs asynchronous

Tout le monde est à peu prêt d’accord pour dire qu’un microservice est :

  • très petit,
  • polyglotte,
  • disponible dans plusieurs versions simultanées.

La communication entre services est une problématique cruciale, mais doit-elle plutôt être synchrone ou asynchrone ? Certains disent que la programmation asynchrone est difficile à comprendre pour les développeurs et conseillent donc un modèle synchrone. Pour Fred George, c’est une erreur. Si c’est difficile, enseignons la programmation asynchrone pour avoir de meilleures applications.

Challenge 2 : Speed of stream

Pour éviter d’engorger son système basé quasiment exclusivement sur l’échange de messages, il faut organiser ses flux et données pour garantir une certaine QoS.
Fred George propose un modèle en trois parties sur le thème des cours d’eaux :

  • Rapids : tous les événements bruts y sont postés. Il y a un fort débit.
  • Rivers : ce sont des événements dérivés. Ils sont la consolidation ou transformation d’événements bruts avec une cible plus restreinte.
  • Ponds : ces larges étendues de données contiennent l’historique et les états. C’est l’endroit où terminent les événements.

Challenge 3 : Microservice ou Clojure ?

Le découpage fonctionnel d’un problème en microservice peut devenir tellement fin, qu’on peut se demander si cela ne revient pas à un élément élémentaire de traitement de données, la fonction.

En prenant trois exemples, Forward, Daily-mail et Outspace, Fred George nous montre la tendance d’évolution du nombre de microservices dans ces entreprises, ainsi que les technologies utilisées.

Les projets qui utilisent des langages fonctionnels, et plus particulièrement Clojure, avaient tendances à réduire le nombre de microservices. Car si un microservice peut tenir en 100 lignes de code, Fred George nous précise avec humour qu’on peut changer le monde en 1000 lignes de Clojure !

Challenge 4 : Choosing architecture and Frameworks

Aujourd’hui, la plus grande collection cohérente d’outils pour les architectures microservices reste le portefeuille open-source de Netflix. Il traite du déploiement dans le cloud, de la sécurité, de la communication, du stockage des données.
Bref, y jeter un œil est forcément une grande source d’inspiration. Mais tout reste à faire dans ce domain qui bouge à un rythme effréné.

Challenge 5 : What is a microservice ?

Fred George pointe du doigt le fait que la notion de microservice est récente et que selon les personnes, la définition n’est pas la même. En effet, à la conférence, nous avons pu observer que les speakers proposaient tous leurs définitions. Pour Fred George, un besoin de convergence est nécessaire et devrait bientôt arriver. Des conférences de deux jours ultra spécialisées comme Microxchg ne sont qu’un début. Il faut que les développeurs continuent d’échanger les avis et pratiques pour faire évoluer et pérenniser le mouvement « Microservice ».

Publié par

Publié par Xavier Bucchiotty

Software Engineer Scala Fanboy FP constant learner Akka trainer

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.