Un zeste de devops et un vortex de microservices dans les nuages

Je suis très en retard pour ce second billet, environ d’une quinzaine de jours, autant dire une éternité dans le monde digital. Je dois préciser que le sujet choisi par ma cohorte marketing est plutôt rébarbatif et en pareil cas je procrastinise assez facilement devant l’écran blanc.

J’avais prévu de vous conter comment mon précédent billet avait initié une belle rencontre autour d’un mojito, et comment, revenant d’un voyage à dos de dragon à travers le cloud, nous avions évoqué avec mon interlocuteur toute la difficulté pour transformer une application monolithique pour le monde des nuages.

Commençons par démystifier mon propos. Le cloud, c’est simple comme un vortex de microservices avec un zeste de devops.

Où comment en quelques lignes j’arrive à placer les deux buzzword les plus excitants du moment.

Le devops c’est magique, vous appuyez sur un bouton et hop votre application est déployée automatiquement, sur un environnement tellement proche de votre environnement de production que la mise en production réelle devient enfantine. Et vous pouvez appuyer sur le bouton autant de fois que vous voulez dans la journée. Je vous laisse imaginer la promesse en gain de temps, de productivité et donc d’argent.

En pratique, le devops met en mouvement un ensemble d’opérations automatiques qui s’enchainent les unes les autres, tout en s’assurant à chaque étape que seule une application bien construite et fonctionnelle sera déployée sur l’environnement cible. Vous appuyez sur le bouton et après un certain temps vous savez si l’opération a réussi ou non.

Un certain temps doit vous rappeler une histoire de refroidissement de fût de canon et vous avez bien raison … car plus votre application devient imposante, et elle le devient à la faveur des évolutions fonctionnelles et de l’explosion de la dette technique, plus la promesse du devops devient illusoire … les temps de construction et de déploiement de l’application s’allongent avec l’inflation applicative, ainsi que votre réactivité à corriger les problèmes lorsque l’opération échoue, l’information d’échec arrivant après un certain temps …

C’est le moment propice pour introduire notre second buzzword du jour, le microservice.

Le principe du microservice est de découper finement une application monolithique en autant de grains que possible. La légende de notre monde veut d’ailleurs que chacun de ces grains ne réalise qu’une tâche mais la réalise à la perfection.

Pour construire une application, il suffit alors de réunir et de faire communiquer tous ces grains au travers d’interfaces parfaitement bien définies, les fameuses APIs.

La promesse du microservice est qu’il est possible de changer ou de remplacer un grain sans avoir à intervenir sur l’application entière. Chaque grain peut être implémenté avec l’équipe, la technologie et l’algorithme de son choix, sous réserve de respecter scrupuleusement les spécifications des interfaces. Une API ça se tient en grand honneur !

Cette promesse tombe vraiment à pic, un devops par microservice et hop j’appuie sur autant de boutons que nécessaires pour construire mon application, dans l’instant, et déployer chacun de mes microservices dans mes nuages. Et grâce au principe même du devops, les tests automatiques détecteront toute modification qui porterait préjudice au bon fonctionnement d’une API.

Une promesse ne venant jamais seule, je connais même une société incroyable qui réalise des opérations de reengineering d’architecture et de refactoring de code sur des applications monolithiques existantes pour extraire grains et interfaces à pousser dans les nuages.

A ce stade de mon apagogie, les promesses n’engageant que ceux qui y croient, il me semble important de vous parler du bât qui va blesser.

La réalité est que vous n’avez fait que déplacer la complexité de votre application monolithique vers le réseau, physique ou logique, qui supporte les échanges entre vos zillions d’APIs. Je me rappelle alors de mes cours sur les réseaux de Pétri colorés et je frémis. L’émergence d’une complexité induite par la dynamique des échanges entre microservices. Mais ce n’est pas tout.

Comme chaque microservice nécessite un environnement devops, vous venez de multiplier le nombre d’environnements, l’expertise nécessaire, le coût du maintien en condition opérationnelle.

Comme chaque API est un temple inviolable, pour assurer la stabilité de l’application, vous venez de complexifier les spécifications et les tests de chaque microservice.

Comme chaque API est un temple inviolable, vous venez de complexifier la gestion d’une évolution fonctionnelle majeure impactant plusieurs microservices et leurs interfaces, rendant indispensable mais ardu la synchronisation entre différents environnements devops.

Et comment fait-on pour faire évoluer une API censée être intemporelle ? et gérer les N versions d’une API ?

Où comment je viens de vous pointer que devops et microservices, c’est finalement plus de taf à tous les étages.

Je dois reconnaitre que certains d’entre vous sont plus malins et que vous savez que l’informatique n’est pas si binaire.

Que toutes les applications monolithiques ne peuvent pas être si facilement hachées menu.

Que le modèle applicatif est intimement lié à l’usine logicielle qui le supporte.

Que même dans ce nouveau monde digital, le déploiement peut être envisagé sur des cycles plus longs que la journée sans remettre en cause la pérennité économique de l’application.

Que même si vous avez succombé aux sirènes des nuages, il est possible de régler finement le curseur entre le tout monolithique et le tout microservices, entre le pas d’API et le trop d’APIs et choisir un modèle devops efficace.

Qu’il existe au moins une entreprise qui peut vous aider dans ce domaine.

Je finirais par un petit rappel à notre histoire commune … comme je le lisais déjà il y a plus de trente ans – et oui les sorcières ne sont plus toutes jeunes – lors de l’apparition des langages orientés objet … there is no silver bullet !

Si vous souhaitez approfondir ce sujet en particulier, ou d’autres, n’hésitez pas à me contacter directement, car j’adore licher des mojitos en after-work, surtout la variante dite des pieds au plafond.

Et comme un gentil admirateur s’est permis de me faire remarquer que j’avais une sacrée plume mais que je manquais cruellement de temps pour inonder la planète numérique de doux billets aptes à remplir mon pipe commercial, je cite de mémoire, j’ai prévu d’écrire une suite.

Cheers,

— Julie

Autres articles

Découvrez les nouvelles fonctionnalités de B4M intégrées à ISIMAN

Découvrez les nouvelles fonctionnalités de B4M intégrées à ISIMAN

Nouvelles fonctionnalités• TEMPLATE PDFLes rapports peuvent être téléchargés en PDF. Il est également possible de définir un template en définissantun en-tête personnalisé ou d’intégrer un logo. • INTÉGRATION DES PROFILSIl est possible de créer, éditer ou supprimer...

Metrixware sera présent au salon Solutions 2024

Metrixware sera présent au salon Solutions 2024

Metrixware sera présent  lors des Salons Solutions qui se tiendront les 9 et 10 octobre 2024 à Paris Porte de Versailles. Cet événement majeur de la gouvernance IT réunit chaque année les experts de la transformation digitale pour aborder les défis actuels et futurs...

Metrixware remercie les visiteurs du SIPEN 2024

Metrixware remercie les visiteurs du SIPEN 2024

Metrixware tient à exprimer ses sincères remerciements à tous les visiteurs qui ont pris le temps de venir nous rencontrer lors du Salon International des Professionnels du Numérique, tenu à Dakar les 27 & 28 juin dernier. Nous sommes ravis d'avoir eu...

SIPEN 2024

SIPEN 2024

Metrixware participe avec Kewël au Salon International des Professionnels de l'Économie Numérique de Dakar (SIPEN) 2024 ! 🚀 Organisé par l'OPTIC (Organisation des Professionnels des TIC), le SIPEN est un événement crucial axé cette année sur l'accélération de la...

Business Case AFD

Business Case AFD

Besoins client   L'Agence Française de Développement (AFD) gère divers risques dans le cadre de ses projets liés à la nature des interventions, aux contextes politiques et économiques , aux aspects environnementaux et sociaux ainsi qu'aux aspects financiers comme...

Business case BUY WAY

Business case BUY WAY

Besoins client   BUY  WAY , une société spécialisée dans le crédit à la consommation, avait identifiée plusieurs défis liés à son infrastructure mainframe. Le besoin principal était de migrer vers une architecture distribuée et ouverte pour simplifier la gestion...

Nouveau Delphi V12 Athens

Nouveau Delphi V12 Athens

Découvrez la nouvelle version de Delphi, la V12 Athens, qui regorge de nouvelles fonctionnalités passionnantes.   VCL modernisé avec MDI retravaillé et interface à onglets pour VCL Amélioration de la modernisation des applications grâce à la prise en charge de la...

Metrixware Systemobjects acquiert TCLog

Metrixware Systemobjects acquiert TCLog

Metrixware Systemobjects renforce sa position avec l’acquisition du fond de commerce “TCLog”, une solution d’agenda éprouvée depuis plus de 20 ans, adoptée notamment par des institutions financières majeures.

Business Case AXA

Business Case AXA

Besoins client   Le service IARD d’AXA, assurances de protection des biens, avait comme projet de moderniser et rendre plus ergonomique l’interface utilisateur de sa plateforme dédiée à l’assurance des 2 roues : l’objectif étant d’offrir une meilleure expérience...