Pourquoi faut-il s’intéresser à Dapr ?

Dans le cadre de la transformation digitale que nous connaissons tous depuis quelques années, il existe des scénarios de migration de solutions “legacy” ou “on-premise” vers une architecture de type cloud et si possible de type micro-services. En effet plutôt que de faire un simple “move to the cloud” les entreprises profitent pour faire un refactoring/reengineeing de solutions. Cela leur permet de pérenniser leurs investissements sur le long terme et attirer/conserver les développeurs vers les derniers patterns architecturaux.

Pour réaliser ce type de projet, Microsoft annonçait le 16 octobre 2019 le lancement de Dapr (pour Digital Application Runtime), défini comme “an open source project to make it easier for every developer to build microservice applications”. Plutôt alléchant, non ?

Force est de constater que ce projet a pris de l’importance au sein de la communauté GitHub et que de nombreux SDK sont prévus pour le premier trimestre de l’année 2020. Vous pouvez d’ailleurs retrouver la roadmap de cet outil.

Entrons dans le vif du sujet : qu’est-que Dapr ?

Dapr est tout d’abord un environnement d’exécution pour permettre de construire des applications distribuées de type micro-services.

En effet Dapr rassemble plusieurs avantages, il est :

• Cloud agnostic,
• Portable,
• Event-driven,
• Un support de nombreux langages et frameworks,
• Intégré nativement avec Kubernetes (mais peut s’exécuter localement ou sur du “on-premise”),
• Supporté par une large communauté de développeurs,
• Adapté à des projets Iot ou Azure on the edge de par son léger poids,
• En possession de son propre CLI utile pour le déploiement et le débogage.

En outre, voici un certain nombre de blocks fournis par le runtime Dapr. Ces derniers permettent surtout d’implémenter ces bonnes pratiques de développement :

• La possibilité de faire du service discovery,
• La gestion des états pour une architecture statefull ou même hybride avec des composants stateless,
• La publication et/ou les abonnements à des services de messages,
• La possibilité d’utiliser l’architecture Event driven,
• La possibilité d’utiliser les Bindings inputs/outputs notamment en utilisant un middleware kafka par exemple.

Ce qu’il faut comprendre c’est que Dapr utilise le principe du side-car, cela signifie qu’un processus ou un conteneur va s’exécuter juste à côté de votre module applicatif. L’avantage ici est de ne pas détricoter la solution existante. Dapr interagit sous le déclenchement d’événements et communique avec les autres APIs Dapr avec les protocoles standards HTTP/gRPC.

Enfin, le runtime Dapr supporte la gestion des états mais aussi les architecture stateless.

Voici les blocks proposés lorsque Dapr s’exécute en tant que conteneur :

Super ! On peut tester ?

De très bons “Getting started” sont présents sur le site GitHub et je vous renvoie dessus pour vous faire la main. Le but de cette documentation est de reprendre les tutoriels d’introduction mais aussi d’expliquer ce qu’est Dapr, les bénéfices que l’on peut avoir et quelques avis personnels. En effet, parmi ces tutoriels on a une simple application qui permet d’envoyer/recevoir des commandes avec une persistance des données. Le projet est réalisé avec un backend en node.js, un front en python et la base de données en Redis cache.

Je vous conseille de configurer votre machine locale avec minikube, ensuite d’installer le binaire de Dapr et enfin de suivre les instructions. Je vous conseille de regarder les commandes “kubectl” et les fichiers “Helm” pour le déploiement. Voici les choses à savoir sur Dapr :

• Le runtime prend en charge une multitude de langages donc cela facilite les projets de migration.
• On ne touche pas au code applicatif car Dapr permet d’encapsuler ce dernier : les appels se font à travers HTTP/gRPC.
• Comme on peut le voir ci-dessus, on peut avoir une double encapsulation. Le client n’appelle pas directement le code python et ce dernier n’appelle pas directement le backend : abstraction assurée !

Un exemple de fonctionnement de Dapr

Pour votre première installation, vous pouvez suivre les exemples et le tutoriel enregistré sur GitHub.

Voici les principales idées à retenir pour comprendre le fonctionnement de Dapr :

Les blocs en bleu “Dapr runtime” sont les points d’entrée respectifs pour appeler le code python et le state. Ce rapide exemple permet d’envoyer et de récupérer des commandes. On peut ainsi voir comment celles-ci sont envoyées et comment les informations sont enregistrées.

Pour effectuer la première encapsulation (le bloc bleu à gauche) il faut lancer la ligne de commande suivante :

Dapr propose aussi ses propres lignes de commande avec les arguments suivants :

• “dapr run” lance le runtime d’exécution Dapr,
• “–app-id” renvoie au nom de l’application Dapr qui s’exécute sur l’environnement cible,
• “–app-port” correspond au port d’écoute HTTP de Dapr,
• “–port” correspond au port d’écoute de l’application node app.js,
• “app.js” correspond au point d’entrée de l’application node.js qui va représenter les GET order / POST neworder.

Ensuite pour saisir ou récupérer des commandes, différents moyens existent : PowerShell, cURL, commandes Post. Ne pas oublier que vous pouvez réemployer Dapr CLI avec le code suivant :

Enfin, une fois la commande envoyée, vous pouvez récupérer la commande à l’aide de plusieurs paramètres :

• invoke : méthode pour appeler une méthode proposée par notre application node.js,
• nodeapp : correspond à app-id plus haut,
• method/order : nom de l’API de nodeapp (app.get(‘/order’, (_req, res)).

Et voilà ! Voici le résultat que nous avons en retour :

Et maintenant ?

Bon maintenant il faut gagner des retours terrain ! En effet, je vous conseille de faire des POCs pour que vous ayez une réelle idée de ce que ça pourrait donner une fois la production lancée, notamment pour les applications critiques dès lors que la version 1 de Dapr sera sortie. En tant que développeurs nous aimons tous tester de nouveaux frameworks ou pattern mais rien ne remplace l’expérience terrain.

Mon avis est de tester d’abord sur des applications non critiques, se faire une conviction et surtout partager le risque avec le client. En effet Dapr apporte de nombreux avantages mais le risque doit être partagé entre chaque partie prenante du projet. Par ailleurs, il vous faudra bien vous assurer que l’ensemble des compétences nécessaires soit couverte au sein de votre équipe.

Voici les différentes compétences et connaissances que doivent avoir les personnes de votre équipe :

• Compétences sur Kubernetes et Helm,
• Maîtrise des principes de base du réseau,
• Connaissance du pipelines Devops.

Pour finir : un peu de documentation

Si ce sujet vous passionne autant que moi, je vous invite vivement à vous documenter pour maîtriser ce pattern architectural !

📰 Le site officiel de Dapr reste une très bonne source d’information.

📰 Quoi de mieux que Github pour commencer avec Dapr.

 Les vidéos d’introduction réalisées par Azure Friday sur channel9 sont aussi toutes enrichissantes, d’ailleurs je vous conseille :

🎥 Le channel 9 sur l’introduction à Dapr (part 1)

🎥 Vidéo channel 9 sur l’introduction à Dapr (part 2)