L’intérêt des architectures microservices est, aujourd’hui de plus en plus connu, notamment par les bénéfices suivant qu’elles apportent :

  • Une application monolithique peut être transformée par étape en extrayant peu à peu des microservices.
  • Les microservices peuvent être mis à jour, étendus et déployés plus rapidement, indépendamment les uns des autres et sans mettre en péril l’ensemble de l’applicatif.

Elles s’accompagnent cependant d’une complexité architecturale et opérationnelle indéniable, de par leur caractère distribué intrinsèque. Alors, est-il possible de bénéficier des avantages, notamment de l’agilité de l’architecture distribuée et de minimiser les inconvénients, notamment la complexité ?

Une des réponses est l’utilisation de Dapr (Distributed Application Runtime). Ce qui n’était à l’origine qu’un prototype est devenu un projet open-source très prisé de la Cloud Native Computing Foundation et supporté par une large communauté du fait, notamment, de son aptitude à faciliter la création d’applications distribuées quelle que soit l’infrastructure.

 

Découvrez tous les avantages de Dapr

Infrastructure

Dapr a été conçu pour être indépendant de la plateforme sur lequel il est déployé, vous ne serez donc pas limité dans le choix de votre fournisseur d’infrastructure Cloud comme Microsoft Azure, AWS ou Google Cloud Platform, mais également dans le cas d’architectures cibles à la fois Cloud er On Premise.

Fonctionnalités apportées

Pour répondre aux problématiques propres à l’aspect distribué des architectures microservices, Dapr fournit des fonctionnalités telles que la gestion d’état (State Management), l’appel de service à service (Service Invocation), la publication/abonnement à un bus applicatif (PubSub), la gestion des secrets (Secrets Management), le partage des configurations ou la mise en place de workflows entre vos microservices. Cette liste n’est pas exhaustive et est régulièrement enrichie.

Dapr_Fonctionnalités

Chaque fonctionnalité est implémentée par des composants enfichables et interchangeables présentant une interface commune pour permettre leur exécution par le runtime Dapr. Le projet Dapr fournit lui-même un ensemble de composants spécifiques à une plateforme donnée pour chaque fonctionnalité. Par exemple pour la gestion d’états, une trentaine de plateformes cibles sont possibles depuis les solutions en mémoire, Redis, ou des bases de données relationnelles ou non sur tous les clouds publics existants : la liste complète est disponible là  State store component specs | Dapr Docs.

Ceci rend le code des microservices plus portable et plus flexible : c’est au niveau de la configuration Dapr que le « bon » composant pour une infrastructure cible est choisi. Pour le même microservice et le même code , des configurations distinctes ainsi peuvent être choisies , pour chaque plateforme différente.

 

Simplicité de développement

En tant que développeur, vous pourrez tirer partie de ces fonctionnalités de systèmes distribués, avec la simplicité d’un unique appel REST ou gRPC à l’API locale exposée par Dapr.

Comme l’explique Thomas, Consultant Senior et Scrum Master

En se basant sur des standards largement répandus (REST) ou en forte progression (gRPC), Dapr facilite l’intégration, peu importe la technologie ou le langage que vous employez. En outre, Dapr fournit des SDK*  pour les langages les plus populaires actuellement (.NET, Python, Go, Java, PHP, JavaScript, etc.). Par conséquent, pour ces langages, vous n’aurez pas besoin de coder vous même n appel REST ou gRPC et vous pourrez utiliser directement les classes et les objets dédiés. La documentation Dapr présente enfin des exemples d’utilisation des différentes fonctionnalités implémentées. Par ailleurs, Dapr bénéficie d’une communauté active qui vous permettra de résoudre rapidement vos difficultés.

Flexibilité

Grâce à son architecture basée sur des composants enfichables, Dapr simplifie considérablement la machinerie derrière les applications distribuées en ajoutant une encapsulation des outils sous-jacents.

Par exemple, si vous souhaitez mettre en place un bus applicatif au sein de votre architecture microservices, vous pouvez démarrer en utilisant une solution simple de type Redis en développement, puis passer à un bus applicatif plus évolué pour l’environnement production Cloud et un autre différent pour un autre environnement production OnPrem. Cela donne de la flexibilité en fonction des capacités des environnements, mais aussi en fonction du temps, sans réinvestissement dans le code.

Comme l’explique Thomas,

Avec Dapr, vous pouvez lier dynamiquement votre base Redis à votre side-car Dapr avec un fichier de configuration YAML et enfin consommer le service PubSub exposé par Dapr sous la forme d’une interface standardisée. De cette manière, si vous devez un jour modifier votre système sous-jacent, ici Redis, vous n’aurez qu’à modifier le fichier de configuration sans modifier votre code. Alors que, si au départ vous aviez utilisé directement le SDK Redis, il y a fort à parier que la modification soit beaucoup plus complexe pour remplacer Redis par RabbitMQ par exemple.

Pour un besoin donné, il est aussi possible de développer votre propre composant Dapr à la place des composants fournis s’il est nécessaire d’implémenter pour une plateforme non supportée ou avec des spécificités propres.

Conception incrémentale

Enfin, vous pouvez utiliser Dapr de manière incrémentielle pour moderniser une architecture existante.

Comme l’explique Thomas

Par exemple pour remplacer la solution tiers ou maison qui couvrait une des fonctionnalités dans le périmètre de Dapr, soit pour des raisons d’obsolescence de cette solution, soit pour simplifier le code de votre nouveau microservice. Dans ce cas de figure vous pouvez déployer votre side-car Dapr et n’utiliser que le composant Dapr dont vous avez besoin. Cela permet éventuellement à l’équipe de développement de se familiariser avec ces nouveaux concepts. Par ailleurs, Dapr une fois en place, si vous voulez utiliser une autre fonctionnalité de Dapr ou remplacer une autre brique technique équivalente, votre side-car est déjà présent et prêt à l’emploi.

 

Architecture

Dapr utilise le patron de conception du side-car et l’image est très parlante en particulier dans une architecture conteneurisée.

Le principe des conteneurs Sidecar est qu’ils fonctionnent en conjonction avec le conteneur principal partout où ce dernier est déployé. Ce modèle side-car étend les fonctionnalité de vos conteneurs principaux sans les modifier. La plupart du temps, ces conteneurs side-car sont simples et petits et consomment moins de ressources que le conteneur principal.

Dapr_Architecture

Dans le cas de Dapr, le déploiement de ce « sidecar » peut se faire concrètement sous forme de conteneur Docker dans votre plateforme de conteneurisation, Docker Engine  ou Azure App Container, par exemple, bien s’executer « localement » sur un serveur Windows/Linux.

Pour bien démarrer avec Dapr

https://learn.microsoft.com/fr-fr/dotnet/architecture/dapr-for-net-developers/getting-started

 

 

SDK* : kits de développement logiciel, ensemble d’outils fourni pour une plateforme matérielle, un système d’exploitation ou un langage de programmation

Ne ratez plus aucune actualité avec la newsletter mensuelle de SoftFluent

Newsletter SoftFluent