Conception sans titre

Les microservices : une architecture Agile — Deuxième partie

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 :

MS1

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.

MS2

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

8 responses to “Les microservices : une architecture Agile — Deuxième partie

  1. Je suis curieux. Docker + Kubernetes, c’est quelque chose d’utilisé à l’interne chez Pyxis?
    Est-ce que c’est quelque chose d’utilisé à chaque projet pour des clients?

    1. C’est encore à l’étape d’exploration à l’interne. Nous gardons une attention particulière à ces outils pour nous assurer de les connaître et de les utiliser sur nos projets internes, lorsque le besoin se présente.

      C’est de cette manière que nous encourageons l’apprentissage continu dans notre équipe et que nous nous assurons de pouvoir donner les meilleurs conseils lorsque des clients nous communiquent des besoins qui nécessitent ce type d’architecture.

  2. Un peu sceptique… Dans la vraie vie, les applications d’entreprises sont très complexes et les fonctionnalités très intriquées. Le microservice, de son côté n’est sensé avoir qu’une et une seule responsabilité. Fonctionnellement, il est donc nécessaire de coupler ces microservices afin qu’ils puissent «composer» les fonctionnalités attendues. Plus les services sont micro, plus le couplage fonctionnel est important. Dès lors que l’on observe un couplage fonctionnel, on peut dire adieu à la résilience de l’ensemble, puisqu’un ou plusieurs services en erreur empêcheront probablement l’ensemble de fonctionner. De plus, ce style d’architecture dans un contexte pouvant légitimer le DDD, nécessitera énormément de rigueur et un rôle transverse d’architecte d’entreprise, ceci afin de garder le maillage entre les microservices le plus lisible possible : lorsque l’on connaît la difficulté à déployer ou mettre à jour de telles solutions, il est probable que, sans contrôle, les évolutions ne seront pas codées au sein des services concernés, mais prendront place dans de nouveaux services anémiques, créés pour l’occasion, sous couvert d’agilité. Les microservices ne sont pas la panacée…

    1. Bonjour,
      Présentement nous n’avons pas de formation directement reliée à DDD. Par contre, dans notre catalogue, (https://pyxis-tech.com/fr/catalogue-formation/) nous offrons des formations techniques, sous la colonne « Concepts et pratiques génie logiciel », qui pourraient vous intéresser ou répondre à un besoin.
      N’hésitez-pas à communiquer avec nous à [email protected] si vous souhaitez avoir plus d’information. Un expert pourra entrer en contact avec vous pour répondre à vos questions.

  3. Est-ce que les microservices sont plus complexes?

    Pas du tout, au contraire, il est toujours plus facile de gérer 100 projets git qu’un seul ! Il existe des outils d’automatisation (scripts python / API Gitlab), qu’on va se forcer à utiliser si il y a plusieurs projets. Donc au contraire, les micro-services, nous poussent à bien faire les choses, de manière automatisable.

    Est-ce que les microservices causent une augmentation du temps de réponse?

    Parfois au contraire ! Le principe de base du micro-service, est de choisir la bonne techno pour l’utilisation. Par exemple, de faire du go pour une tâche, qui serait trop lente à faire en Php, et appeler son micro-service go depuis Php. (on fait ça par exemple pour le machine learning, Php –> C++).

    Aussi, avec des techno comme gRPC/HTTP2, le coût du transport est négligeable.

Laisser un commentaire

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