dapr : Distrubuted Application Runtime (https://dapr.io)

Aujourd’hui l’architecture à base de micro-services est de plus en plus présente. Cela consiste à créer des blocs d’application en respectant une logique métier. Cette architecture est devenue très populaire car elle est très permissive :

  • Elle permet une autonomie de chaque bloc applicatif
  • Une grande scalabilité
  • Une grande flexibilité
  • Chaque bloc peut être développé indépendamment (un service en C# et un autre en Nodejs par exemple)

Cependant ce type d’architecture a plusieurs désavantages. Il faut savoir qu’une grosse application peut avoir des dizaines de micro-services et que certains sont interdépendants, cela signifie par exemple que pour debugger un service qui dépend de deux autres vous devez donc avoir les 3 micro-services lancé s’ils ne dépendent pas d’autre micro-services et donc potentiellement debugger les trois. L’architecture micro-services peut vite devenir illisible et complexe à mettre en place et à maintenir. Pour pallier ses problèmes, Microsoft a mis en place un outil DARP (Distributed Application Runtime).

Dapr c’est quoi ? 

Dapr est un outil runtime open source, portable et orienté évènements qui permet au développer de facilement créer des applications avec une architecture micro-services. Concrètement ça veut dire quoi ?

Runtime

Dapr agit comme une couche d’abstraction dans votre code, autrement dit Dapr va fonctionnera du côté de votre application de manière indépendante et permettra de faire lien entre votre service et un autre service.

Portable

On dit de Dapr qu’il est portable car il fonctionne avec tous les langages ainsi que tous les Framework. Cette portabilité est possible car Dapr fonctionne comme une API ouverte à laquelle vous ferez appel dans votre code. Cela permet donc d’être utilisé dans tous les langages. De plus Dapr est portable car il est indépendant de la plateforme, ce qui signifie que Dapr peut être exécuté en locale ou bien sur Kubernetes.

Orienté évènements

Dapr est orienté évènements car pour communiquer entre vos différents services de votre application Dapr va utiliser un système d’événements.

Comment Dapr fonctionne ?

Dapr se compose d’un ensemble de blocs préconçus (building blocks) en API ouverte (accessible en http). Par conséquent vous pouvez faire appel à ses blocs depuis n’importe quel langage de programmation (Framework compris), Chacun de ses building blocks est indépendant, donc vous pouvez choisir d’y faire appel ou non dans votre code.

Ce schéma représente ce que je viens de vous expliquer, Vos applications (micro-services) peuvent être codé dans le langage de votre souhait, quand vous voudrez accéder à un building blocks de Dapr il vous suffira pour cela faire une requête http a l’api de Dapr.

Voyons maintenant les différents Blocks est leur utilité.

Building Blocks

Lors de la mise en place d’une Infrastructure micro-services il y a de nombreuses considérations à prendre en compte (le stockage des données, la communication entre services et les appels de leurs méthodes, etc…). Dapr a mise en place des Blocks préconçus sur la plupart des fonctionnalités communes aux applications micro-services.

Voici la liste des blocs disponibles dans Dapr :

  • Service to service invocation (permet de faire appel aux méthodes d’un autre service)
  • State management (permet de créer des états sous forme de clé valeur dans plusieurs DB)
  • Publish and Subscribe ( permet de gérer la gestion d’évènements entre services)
  • Ressource Binding and triggers (permet simplement d’envoyer des ressources en réponse a un évènement)
  • Actor (Un modèle pour les objets cela inclut plusieurs paramètre le cycle de vie, ainsi qu’une minuterie pour faire appel aux acteurs)
  • Observability ( ce bloc permet essentiellement de faire une surveillance des communications entre services ; il permet de récupérer des données métriques )
  • Secret (permet de faire la gestion des secrets de vos applications)

Anatomie d’un Building Block

Dapr en plus de mettre à votre disposition des building block vous permet d’en créer. Cependant chaque bloc doit respecter une certaine anatomie. Chaque bloc est composé de la manière suivante :

  1. Dapr spec, chaque bloc doit avoir une API intégrée dans la spécification Dapr
  2. Chaque bloc peut soit faire appel à des composants déjà existants, soit les créer soit même
  3. Chaque nouveau bloc doit être accompagné de tests unitaires et de documentation.

L’architecture de Dapr

Dapr est baser sur une architecture Sidecar. Autrement dit le Dapr est attaché à votre application (application parente) et fournit à celle-ci des fonctionnalités auxquelles elle peut faire appel (ici se sont les building block). De plus, Dapr partage le même cycle de vie que votre application, il sera donc mis en service/hors-service en même que votre application. Dans une application déployée localement Dapr ressemblera donc à cela :

Dans cet exemple nous avons deux services (A et B) et Dapr fonctionne à côté de chacun d’eux. Si vous vouliez faire appelle au bloc State Stores, vous devrez donc faire un appel à l’API de Dapr et Dapr sidecar lui fera appelle au bloc correspondant. Ce schéma représente donc Dapr en local, mais quand est-il de Dapr avec Kubernetes ?

Les concepts de Dapr sous Kubernetes restent le même que Dapr en local mise part quelques différences. Sous Kubernetes vous devez injecter dans votre cluster 4 pods Dapr :

  • Actor placement
  • Sidecar injector
  • Sentry
  • Operateur

Les pod Sidecar injector et Operateur permettent de lancer Dapr en tant que conteneur side-car dans le même pod que le conteneur de votre application et permet fournir des notifications des mises à jour des composants Dapr du cluster. Sentry est une autorité de certification, pour les authentifications. Ces grâce à ces éléments que le sidecar de chaque Microservice de votre application va communiquer avec les Components (building blocks).

Cet article est écrit par les Experts Infeeny et Kevin Ansard.