Faut-il céder aux sirènes de l’architecture microservices ?

Que sont les microservices et pourquoi les développeurs les aiment-ils tant ?

Les microservices sont un sujet sensible. À cause de quelques success stories, l’architecture microservices (à ne pas confondre avec les points d’extrémité), s’est révélée être une excellente solution pour construire, livrer et déployer des fonctionnalités scalables, indépendantes et autonomes.

Pour comprendre les microservices, il suffit de les imaginer comme étant des pièces de puzzle indépendantes qui une fois assemblées, offrent une fonctionnalité ou une caractéristique de taille.

D’un point de vue sémantique, les microservices indiquent la séparation d’une grande fonctionnalité/caractéristique en plusieurs bouts de code. Ces derniers sont plus petits et faciles à gérer car chacun dispose de ses propres spécificités, déploiement et data.

• Maximiser l’autonomie des diverses équipes

Chaque microservice encapsule l’ensemble des logiques et des données dont il a besoin, ce qui signifie qu’il peut être développé indépendamment des autres éléments ou fonctionnalités. Cela permet de créer un environnement de travail où les équipes peuvent avancer sans avoir à se coordonner avec les autres.

• Optimiser la vitesse de développement

L’architecture microservices donne la possibilité aux équipes de construire des services puissants facilement et rapidement car les discussions concernant la complexité, le temps de QA et de déploiement, les dépendances et l’alignement n’ont plus lieu d’être.

• Focus sur l’automatisation

L’erreur est humaine. Plus de systèmes à gérer signifie plus d’occasions de faire des erreurs. Alors comment faire pour minimiser le risque ? La solution : tout automatiser. De cette façon, les petits éléments peuvent facilement rejoindre les tuyaux de déploiement où ils peuvent servir une autre équipe ou fonctionnalité. En outre, une complexité réduite signifie une automatisation plus rapide des tests portant sur l’UI, l’API, l’intégration, etc.

• Fournir de la flexibilité sans faire de compromis sur la cohérence

Laissez à vos équipes la liberté dont elles ont besoin pour développer leur partie mais faites en sorte de garder un ensemble de règles standards afin que tout le monde s’y retrouve. Au-delà des avantages de développement, les bouts de code sont également plus faciles à tester (tests automatisés ou unitaires), donc à changer et à adapter.

• Pensé pour être résilient

Les systèmes peuvent échouer pour de nombreuses raisons. Un système distribué introduit un nouvel ensemble de scenarii d’échec. Néanmoins, les erreurs de management et tout échec de mécanisme sont plus faciles à implémenter, tester et maintenir. Cela permet de garantir que des mesures sont en place pour minimiser les impacts. Notons que de multiples points d’échec requièrent une plus grande attention sur l’intégration des tests car les tests de non-régression pour le déploiement deviennent de moins en moins pertinents.

• Simplifier la maintenance

Qui dit architecture microservices dit plusieurs code base. Instaurez des consignes et mettez en place des outils pour garder une certaine cohérence. Si le développement est fortement guidé par les mêmes standards et pratiques, n’importe quelle équipe peut facilement choisir un microservice et le changer pour un code base plus court, simplifié et encapsulé dans des opérations logiques.

• Isoler les problèmes

Due à la nature particulière des microservices, en théorie l’identification des problèmes devrait être plus facile parce qu’on peut identifier et pointer le service responsable. La séparation des data et de l’exploitation est obligatoire pour faciliter cette fonctionnalité.

Ça semble presque trop beau pour être vrai, et vous vous demandez sûrement pourquoi les entreprises n’implémentent pas l’architecture microservices à tous leurs projets. Mais si sur le papier cela semble super, comme n’importe quel modèle architectural, l’architecture microservices a des limites qui doivent être prises en compte.

L’architecture microservices est-elle faite pour votre activité ?

L’une des principales caractéristiques de l’architecture microservices est la possibilité de séparer le domaine d’activité de l’application en plusieurs sous-domaines. Chacun d’entre eux vient avec ses propres données et sa logique métier, ce qui permet de retirer des petites applications de l’équation.

Je me souviens d’un entretien que j’ai passé il y a plusieurs années de ça pour un poste d’architecte de logiciel. L’employeur voulait savoir comment j’allais implémenter le back-end pour un jeu de morpions en utilisant les microservices. Il était évident que ce type d’application n’aurait jamais bénéficié des avantages du microservice mais nous avons malgré tout perdu 2h à imaginer comment cela pourrait être fait, en théorie.

D’un autre côté, des applications à grande échelle ont généralement un haut niveau de complexité en termes de caractéristiques, de flux et de volume de données. De ce fait, il pourrait être difficile de créer une séparation nette du domaine afin de faciliter l’architecture microservices. Habituellement, pour s’assurer d’un haut niveau de contrôle, les entreprises optent pour un composant/module basé sur l’approche et migre les composants vers les microservices plus tard.

J’ai travaillé avec un client issu de la finance et qui avait une application monolithique très difficile à changer et à maintenir. Alors que l’on envisageait une migration vers les microservices, nous avons choisi une approche composant simplement parce que coordonner le développement demandait une connaissance précise de chaque fonctionnalité et il n’y avait aucune documentation et personne n’avait une connaissance suffisante du système. Cela aurait très bien fonctionné une fois implémenté mais ça aurait demandé des années de développement pour le faire correctement.

Compte tenu du contexte, les applications de taille moyenne sont les candidats les plus enclins à adopter ce modèle tant que la complexité du domaine reste suffisamment faible pour permettre la séparation en sous-domaine ainsi que la gestion du flux de data ou du volume de data en microservices.

Architecture microservices : qu’en disent les développeurs ?

Bien que l’architecture microservices soit une tendance qui grimpe et qu’elle fasse parler un grand nombre de personnes, les entreprises roumaines ayant des success stories significatives utilisant ce modèle se comptent sur les doigts d’une main. En retour, la majorité des développeurs ne possède pas l’expérience nécessaire pour travailler avec ce modèle et son implémentation, en dépit de leur bonne volonté, est loin des standards et des exigences attendus pour des microservices.

S’il vous prend la curiosité de lire un ouvrage sur les microservices, vous seriez surpris de voir que les règles et les pratiques sont très générales et manquent même de précision, laissant le champ libre à toute interprétation (ce qui se reflète dans la multitude de frameworks et d’approches qui facilitent le développement de microservices).

Dans ce contexte et au-delà de toute architecture et système, chaque développeur doit être en mesure de choisir l’approche la plus appropriée, le niveau de séparation ou encore les canaux de communication, entre autres ou cela pourrait profondément affecter l’ensemble du process de développement et le résultat souhaité.

Mon expérience m’a amené à voir de nombreuses équipes introduire plusieurs douzaines de technologies et frameworks (chacun excellent à sa façon) pour une poignée de microservices, ce qui a fini par créer un effet boule de neige avec toujours plus de dépendances et des fonctionnalités qui se chevauchaient, rendant la maintenance impossible pour une seule équipe. De plus, l’effort nécessaire pour synchroniser toutes les technologies et les ressources requises pour les faire fonctionner rendait l’application inutilisable. Par exemple (si l’on se penche sur une approche Architecture Delta), quelques microservices suffisent pour des databases SQL et NoSQL en parallèle d’un cache distribué, deux systèmes de messagerie différents, des traitements synchrones et asynchrones et différents services AWS pour simplement calculer et télécharger quelques prix de produits. Mais ça a pris des heures.

Une compréhension homogène du modèle établi au sein de l’équipe et un ensemble de pratiques plus rigide sont requis pour une implémentation réussie de ce type d’architecture. L’analyse d’architecture de logiciel et le design de système doivent fonctionner main dans la main à chaque itération pour s’assurer que seule l’implémentation requise arrive dans le code base. Se concentrer sur des morceaux de code plus petits et faciles à gérer et faciliter la révision du code sont la clé pour continuer à suivre la bonne voie.

Comment réussir ce défi ?

Le nombre d’équipes qui participent au process de développement est un autre challenge récurrent. Idéalement, avoir plusieurs équipes permet de séparer le développement de chaque fonctionnalité, assurant le développement en parallèle de plus petits morceaux de code qui ensemble, forme la fonctionnalité demandée.

Malheureusement, la pratique a montré que divers degrés d’expérience au sein d’une équipe menaient systématiquement à des goulots d’étranglement lors des livraisons. Une équipe peut avancer plus lentement que prévu, forçant l’autre équipe à attendre ou à simuler des dépendances pour finalement revoir tout son code après la livraison de la première équipe.

Afin de réussir ce défi, le management doit être davantage impliqué dans le process de livraison. Les cérémonies Agiles doivent être encore plus importantes pour arriver au succès du produit et une attention constante est requise afin que les équipes soient bien alignées. Comme le dit la loi de Conway : « Les organisations qui conçoivent des systèmes… sont contraintes de produire des designs qui sont des copies de la structure de communication de leur organisation ». Autrement dit, la communication microservices doit imiter les problèmes qui apparaissent au niveau de la communication des équipes, pour mener à une nécessité forte d’améliorer et de maintenir un haut niveau de communication.

Tester la data

Les systèmes monolithiques ou isolés sont bien plus faciles à tester que les microservices. L’absence de dépendances externes, de logique métier encapsulée et une certaine rigidité bénéfique du système maintenue par des tests unitaires rendent les applications standards moins compliquées en termes de testing.

Par définition, les microservices impliquent des dépendances externes. Même si les tests unitaires garantissent la bonne intention de chaque implémentation de services, la valeur métier ne peut réussir qu’à travers une communication de service.

Des efforts importants sont nécessaires pour automatiser l’intégration de tests et s’assurer que la collaboration des services, perçus comme une seule fonctionnalité, fonctionne comme prévu. Cela n’implique pas seulement d’avoir dans chaque équipe un spécialiste QA automation mais également de développer des applications séparées afin de tester les applications que vous êtes en train de développer.

L’infrastructure doit (au moins) répondre à une livraison en continu avec une exécution automatisée des tests intégrés et un système de notification qui soit capable d’identifier les problèmes émergents après le déploiement de chaque microservice.

Autre défi relatif à l’automatisation des tests : l’exactitude des données et la capacité à produire un volume suffisant de données correctes afin que les tests d’automatisation soient pertinents. D’après mon expérience, cela prend autant de temps, si ce n’est plus que l’actuelle implémentation de microservices qui conduit à un temps de développement plus important et bien sûr, des coûts de développement plus élevés. Dans le pire des cas, l’intégration de tests se transforme en goulot d’étranglement à la livraison.

Tout est une question de ressources

Imaginons que nous ayons une application qui soit parfaite pour une approche microservices et que les équipes soient sûres à 100% de la faire dans le temps imparti. L’élément suivant à prendre en compte est le prix de l’infrastructure.

Supposons, arrivé à un certain moment dans le process de design de logiciel, que quelques composants du système aient besoin de gérer un volume important de data et de demandes, tandis que les autres seraient rarement sollicitées. Pour ce faire, nous essayons de séparer ces fonctionnalités basées sur l’usage et de créer un plan de déploiement qui faciliterait un plus grand nombre d’instances de microservices spécifiques. Des outils existants, comme Kubernetes, facilitent grandement la coordination des déploiements mais l’astuce est d’avoir suffisamment de ressources pour vos besoins.

À de nombreuses occasions, afin d’améliorer la performance de quelques fonctionnalités, j’ai vu des dépenses en ressources être multipliées par 10, nous faisant abandonner l’idée et accepter que le temps de réponse de certaines requêtes serait de quelques secondes ou minute, tant que les coûts resteraient gérables. Par exemple, en raison de la nature du produit, le traitement par lots n’était pas possible, ce qui a mené à un processus séquentiel (exigeant l’appel à un service pour chaque article). Mettre à l’échelle pour améliorer les performances signifiait avoir des centaines d’instances (afin de satisfaire les centaines d’articles et les clients parallèles), ce qui n’était pas le plus judicieux en termes de coût.

Plongée dans l’océan des microservices

Il est vrai que dans certains cas, l’architecture microservices a prouvé qu’elle offrait de bons résultats et qu’elle a grandement amélioré la qualité et les performances de différents services et produits.

Il est facile de céder face à l’engouement des microservices mais tous les projets n’ont pas besoin des microservices et pour certains, cela les rendrait plus compliqué ou plus chers.

Avant de plonger dans l’océan des microservices, prenez suffisamment de temps pour comprendre les coûts et les bénéfices de l’architecture de microservices. Assurez-vous que vos équipes comprennent vos objectifs et les meilleurs moyens pour les atteindre.

Consultez aussi :

Code Refactoring en continu : indispensable pour faire évoluer sa plateforme

Méthodologie agile : 4 manières de configurer la réussite de votre projet

Développement web : Pourquoi doit-on utiliser NodeJs ?