Lisez la première partie de cet article ici : « Les microservices : une architecture Agile — Première partie ».
Utiliser le DDD (Domain Driven Design) pour créer des microservices
En nous appuyant sur la séparation des modèles qu’offre le DDD, nous pouvons rejoindre facilement le même concept qui est à la base des microservices. Il suffit de décomposer le modèle d’affaires en plusieurs parties (avec le patron de modèle du domaine) pour se retrouver avec une représentation du système qui utilise le même vocabulaire et les mêmes spécifications que dans la réalité de tous les jours. Visuellement, dans le cas d’une application de commande en ligne, nous arrivons à un diagramme comme celui-ci :
Avec un peu d’analyse, la vision se précise et chaque modèle du domaine se trouve appartenir à une entité parente. Dans le vocabulaire du DDD, ils sont appelés les agrégats (aggregates). Ils consistent en un regroupement de modèles qui peuvent être traités comme un tout. Dans notre exemple, « Commande » et « Client » sont des agrégats du domaine. Nous pouvons centrer toutes les opérations qui ont rapport aux commandes sur l’objet « Produit » et tenir pour acquis que ses photos et sa catégorie seront bien gérées.
En créant la liste de ces agrégats et leurs responsabilités, les entrées de l’interface serveur (API) sont presque déjà définies et prêtes à être configurées dans la passerelle (API Gateway). Le but de cette passerelle est d’être la porte d’entrée unique de toutes les requêtes. À part gérer la sécurité avec l’authentification et les autorisations, elle ne fait aucun autre traitement que l’envoi d’un événement ou la redirection vers une autre entrée, que ce soit sur le même serveur ou non.
En y réfléchissant quelques instants, pouvez-vous faire un lien avec certains modèles de vos domaines d’affaires existants?
Par exemple, il est possible que la logique relative aux produits et au catalogue soit déjà bien divisée et qu’il n’y ait pas beaucoup d’interconnexions. Ce cas peut alors être un parfait candidat pour commencer à établir les bases d’une architecture de microservices. De cette manière, s’il se trouve que notre catalogue serait plus sollicité si nous ajoutions certaines fonctionnalités supplémentaires, il est plus facile pour une équipe d’assimiler les connaissances de ce domaine spécifique et de le faire évoluer.
Si au contraire la demande est trop grande, nous pouvons aisément installer une autre copie du service et gérer la charge de travail au niveau de la passerelle. C’est en s’attaquant aux petits morceaux que nous pouvons y voir plus clair et les faire évoluer vite et bien.
Avant de vous lancer, voici quelques questions que vous devriez considérer avant de vous engager à utiliser une approche par microservices.
À quel point les microservices doivent-ils être petits?
C’est une question à laquelle vous seul pouvez répondre. Quand vous planifiez de séparer des microservices d’une application monolithique déjà existante, il faut que vous vous demandiez si votre service est assez petit pour en arriver à une meilleure flexibilité et Agilité. Si votre service est crucial au fonctionnement du reste de l’application et qu’il y a beaucoup d’interconnexions, il peut être préférable maintenir le statu quo.
Comment les microservices peuvent-ils évoluer?
Modulariser les services de l’application distinctivement en utilisant une technologie de conteneur comme Docker offre une bonne approche pour l’évolutivité horizontale (plus de machines). Le concept s’applique aussi à la structure monolithique, puisque cette technique peut être appliquée dans les deux cas en créant un réseau de services qui se partage la charge.
Est-ce que les microservices sont plus Agiles?
Avec les pratiques DevOps, les conteneurs et le Domain Driven Design, les microservices offrent clairement une meilleure Agilité et une productivité plus optimale. Comme chaque composante est segmentée et indépendante, les décisions d’architecture peuvent être prises en considération pour chaque composante, au lieu de l’ensemble. En ayant l’opportunité de relayer la gestion des dépendances aux conteneurs, l’effort à investir dans l’intégration lors du développement est moins grand.
Pour de petites applications moins complexes, la structure monolithique peut quand même offrir une meilleure rapidité de développement, tout en étant aussi Agile.
Quel est le meilleur moyen de déployer les microservices?
Qui dit application avec plusieurs services, dit que ceux-ci doivent être administrés convenablement, sinon nous nous retrouvons rapidement à surcharger l’équipe des opérations. C’est pourquoi il est important de se munir dès le début d’outils d’automatisation et d’orchestration (comme Kubernetes). Cet effort peut accentuer la courbe d’apprentissage initiale et sembler peu nécessaire avec un petit nombre de services, mais au fur et à mesure que les services se multiplient, vous voyez l’intérêt.
Est-ce que les microservices sont plus complexes?
Comme mentionné dans la réponse précédente, il y a beaucoup plus de défis dans le déploiement de microservices que dans le cas d’une application monolithique. Pour arriver à une indépendance de services, l’équipe doit s’assurer de couvrir le cycle de vie complet d’un microservice, de l’écriture du code jusqu’au déploiement. Cette appropriation peut se solder par de gros changements au niveau organisationnel et au niveau de la configuration. Chaque microservice devra avoir son propre processus de compilation et une mécanique de déploiement soutenue par une interconnexion rapide entre chaque service.
Est-ce que les microservices causent une augmentation du temps de réponse?
Plus il y a de microservices, plus grandes sont les chances que vos utilisateurs constatent des répercussions sur la performance, causées par les nombreux appels aux serveurs. Pour vous assurer de respecter des délais qui n’influencent pas la qualité de l’application, il faut chercher à toujours réduire le nombre d’appels et si possible, les exécuter en parallèle. Si votre système requiert des réponses en temps réel, ce n’est peut-être pas un bon candidat pour une structure en microservices, à moins que vous n’encapsuliez l’infrastructure en temps réel à l’intérieur d’un microservice.
Est-ce que les microservices sont résilients?
Le fait de garder les microservices dans des processus différents apporte un grand avantage au niveau de la résilience. En effet, certaines parties peuvent tomber sans affecter les autres processus puisque les ressources des serveurs sont séparées. Si la gestion des erreurs est bien développée, il est possible de tout simplement réessayer en cas de problème. En poussant un peu plus loin, s’il y a trop d’erreurs suite à un déploiement, nous pouvons automatiser un retour en arrière.
Besoin d’aide?
Que ce soit pour obtenir de l’aide avec les microservices ou autres, chez Done l’expertise de nos équipes multidisciplinaires, nous permet d’accompagner les entreprises qui souhaitent développer les compétences de leurs équipes de développement. Pour en savoir plus sur la formation et le coaching technique, cliquez ici.
En résumé
Les microservices offrent plusieurs avantages autant aux utilisateurs qu’aux développeurs :
- Les modules sont isolés donc les erreurs ont moins de conséquences;
- L’expérimentation avec les nouvelles technologies est moins risquée;
- L’apprentissage des nouveaux membres de l’équipe est facilité.
Plusieurs grandes entreprises comme Walmart, Spotify ou Amazon ont effectué un virage vers les microservices et ont obtenu des résultats allant au-delà de leurs attentes. Par contre, il est primordial de bien considérer la complexité et l’automatisation de l’infrastructure pour ne pas tomber dans le piège d’investir trop d’efforts dans le gouffre sans fond du déploiement et de la configuration.
Références
- Introduction to Microservices (https://www.nginx.com/blog/introduction-to-microservices/).
- The CxO Guide to Microservices (https://www.thoughtworks.com/insights/blog/cxo-guide-microservices).
- Pattern: Microservice Architecture (http://microservices.io/patterns/microservices.html).
