urbanisation-si.com

N’abusez pas des Micros-Services et n’oubliez pas : sans DevOps et sans le Cloud, mieux vaut encore un bon vieux monolithe Java dans un serveur d’applications JEE ou COBOL dans un antédiluvien mainframe IBM. Les micro-services font le buzz, alors faut-il suivre cette tendance aveuglément ? N’y a-t-il pas des cas où ça équivaudrait à se tirer une balle dans le pied ?

(Macro-modèle de la communication entre micro-services)

L’utilité des micro-services a été prouvée par un grand nombre d’entreprises de taille colossale (Netflix, Google…) qui les ont mis en œuvre pour résoudre une catégorie de problèmes liés à des cas d’utilisation bien particuliers.

Les limites des monolithes, comme celles des antédiluviennes applications COBOL sur mainframe, voire plus récemment Java dans les serveurs d’applications JEE, ont été atteintes en ce qui concerne, par exemple, leur gérabilité, leur évolution dans le Cloud, leur mise à l’échelle et la difficulté rencontrée à intégrer les méthodes agiles.

(Exemples de monolithes : les mainframe IBM et les serveurs d’application Java)

Certains d’entre vous reconnaîtront peut-être ce contexte d'architecture technique ci-dessus, montrant comment, au fil des années, les architectes techniques ont savamment fait un lifting du monolithe à coup de crème d’interfaces et de gateways. Cette couche cosmétique offre la possibilité à des applications de front office (client lourd ou client léger de type web) d’accéder aux dizaines de milliers de lignes de code COBOL enfouies dans les oubliettes du mainframe.

Les connaisseurs apprécieront le logiciel IBM ECI (External Call Interface) permettant à une application cliente d'appeler un programme CICS de manière synchrone ou asynchrone et le Saint Graal IBM CICS Transaction Gateway (CTG) qui est un connecteur conçu pour la modernisation des monolithes d’entreprise. Tous types d’applications Java JEE (renommer Jakarta depuis son transfert d’Oracle vers la fondation Eclipse), Microsoft .NET… peuvent communiquer avec CICS et des Web Services en COBOL.

Le tsunami de micro-services pourrait entraîner certains décideurs à les utiliser dans la conception et la réalisation de produits dans des contextes où ils ne sont pas censés être utilisés, entraînant dans certains cas des échecs.

Les microservices sans XOps (DevOps, DevSecOps, MLOps) ? Même pas en rêve !

Les microservices provoquent une explosion d'éléments (entités métiers, DAO/persistance, contrôleurs, sérialisation, annuaire/repository, gateway, load balancing, sécurité, logs, cloud...) à assembler. Ce n'est pas une bonne idée d'essayer de mettre en œuvre des microservices sans déploiement sérieux ni automatisation de la production du produit logiciel et de sa gouvernance. 

Vous devriez être en mesure d'appuyer sur le bouton de votre CI/CD (Intégration et Livraison Continues) et de déployer votre application. En fait, vous devriez même ne rien faire. Le code de validation doit faire déployer votre application via la gestion évènementielle de validation, qui déclenche le pipeline de livraison, au moins en développement.

Ne gérez pas votre propre infrastructure

Les microservices intègrent souvent plusieurs bases de données, brokers de messages, gestionnaires de caches de données et autres services qui doivent tous être maintenus en état opérationnel.

Pour cela, on a toute la panoplie du Cloud.

1. Infrastructure as a Service (IaaS) dans lequel le fournisseur Cloud gère le matériel serveur, les couches de virtualisation, le stockage, les réseaux.
    
2. Platform as a Service (PaaS) où le fournisseur maintient la plate-forme d'exécution de ces applications : les serveurs, les systèmes d'exploitation, les systèmes de bases de données et les infrastructures de réseau ainsi que de sauvegarde.
    
3. Software as a Service (SaaS) est un modèle d'exploitation commerciale des logiciels dans lequel ceux-ci sont installés sur des serveurs distants plutôt que sur la machine de l'utilisateur.
    
4. Function as a Service (FaaS) est une catégorie de services de Cloud qui fournit une plate-forme permettant aux clients de développer, d'exécuter et de gérer des fonctionnalités d'une application sans la complexité de la création et de la maintenance de l'infrastructure généralement associée au développement et au lancement d'une application. 
   Construire une application suivant ce modèle est un moyen de parvenir à une architecture « sans serveur » et est généralement utilisé lors de la création d'applications de micro-services. 

Ne créez pas trop de microservices

Chaque nouveau micro-service utilise des ressources. L'utilisation cumulative des ressources peut dépasser les avantages de l'architecture, si vous dépassez le nombre de micro-services que DevOps, l'organisation, le processus et le système peuvent gérer. Les rendre trop petits transfère la complexité des microservices vers une tâche d'intégration de services. 

N'oubliez pas de garder un œil sur le problème de latence potentiel

Rendre les services trop granulaires ou exiger trop de dépendances sur d'autres microservices peut introduire de la latence. Des précautions doivent être prises lors de l'introduction de microservices supplémentaires. Lors de la décomposition d'un système en micro-services autonomes plus petits, vous
augmentez le nombre d'appels passés au-delà des limites supportables par le réseau et par les CPUs, ce qui va dégrader les temps de réponse et le système de multithreading.

Ces appels peuvent être soit de service à service, soit de service à composant de persistance. Par conséquent, exécuter des tests de performance pour identifier les sources de toute latence dans l'un de ces appels est fondamental. De nombreux outils sont disponibles dans l’offre commerciale : on peut citer IBM Rational Performance Tester, Oracle Load Testing et dans l’open source très utilisé Apache JMeter. Vous devez identifier les goulots d'étranglement.

Conclusion

Ces anti-cas d’utilisation permettent d'éviter le battage médiatique des micro-services qui entraînerait des échecs sans certaines précautions. 

Ne donnons pas l’occasion aux détracteurs d'alimenter une polémique qui n’a pas raison d’être sur une technologie saine, aidant à l’agilité, réduisant le time to market et servant la stratégie de l’entreprise.

Pour finir, un dernier conseil : si la valeur de partage est une valeur universellement reconnue, ne l'appliquez pas aux micro-services qui ne doivent en aucun cas être liés à plusieurs systèmes différents.

Rhona Maxwel
@rhona_helena

"La courbe de tes yeux fait le tour de mon cœur,
Un rond de danse et de douceur,
Auréole du temps, berceau nocturne et sûr,
…
Le monde entier dépend de tes yeux purs
Et tout mon sang coule dans leurs regards."

Paul Eluard

Pour en savoir plus sur les micro-services :

1. L’Architecture Micro-Services expliquée à ma fille
    
2. Inconvénients de l'Architecture Micro-Services
    
3. Estimation de la complexité d’une Architecture Micro-Services