Pour répondre à cette question, j’illustre ma réponse avec un cas concret, celui de Colissimo. L’architecture monolithique était à bout de souffle et incapable de faire face à l’explosion du e-commerce. Sous la pression des autres acteurs du secteur, l’entreprise a cherché comment devenir plus réactive. La solution ? Passer à l’architecture microservices.
Prérequis : augmenter la résilience du SI et la scalabilité
Un système d’information résilient possède une grande résistance aux erreurs et problèmes qui peuvent survenir en production. À l’inverse d’une architecture monolithique, le système bâti en microservices est découplé ou asynchrone. Il continue de fonctionner si une de ses briques logicielles (application) s’arrête. Chez Colissimo, nous avons extrait les fonctionnalités une par une du monolithe, en maintenant la communication grâce aux API et Kafka Streams. Pour augmenter la résilience, Docker et Kubernetes ont été mis à contribution afin de gérer la charge. Concrètement, on crée des conteneurs-images qui prennent le relais si le conteneur principal tombe. Le temps d’indisponibilité du service se voit réduit de quelques jours à quelques minutes.
Être résilient c’est bien, mais pouvoir moduler ses ressources en fonction de la demande c’est mieux : devenir « scalable ». Dans le cas de Colissimo, il y a des périodes de trafic intense comme celle de Noël et des moments plus calmes comme le mois de mars. Même si le mot calme veut quand même dire des millions de colis par jour! Les microservices permettent de s’adapter à la variabilité de la demande. Avec deux gains : lorsque les besoins diminuent, la consommation de ressources baisse générant des économies d’énergie et un impact réduit sur l’environnement ainsi qu’une réduction des coûts. Kubernetes nous aide pendant les « temps fort colis » à dupliquer les composantes pour traiter un grand flux de données (scalabilité horizontale). Il nous faut aussi augmenter les ressources en CPU et RAM (scalabilité verticale). Le système peut alors traiter 50 millions d’événements par jour, soit environ 4 millions de colis.
Fin de l’architecture monolithique : La découverte de la flexibilité technologique
L’architecture monolithique de Colissimo utilisait la technologie d’Oracle et était donc pieds et poings liés avec l’éditeur, condamné à payer de nouvelles licences pour chaque mise à jour majeure ou nouvelle fonctionnalité. Les microservices, eux, sont libres d’utiliser la technologie qui convient aux besoins. Chaque service est comparable à un SI miniature, il suffit de mettre en place un protocole de communication commun (échange de données ou API). On peut construire des applications en Java qui communiquent avec des applications en Scala qui, elles, échangent avec des applicatifs en GO. C’est le cas chez Colissimo.
De même, les bases de données sont mixtes, l’une est en Cassandra et l’autre en Postgre, tout dépend du type de données qu’elles hébergent et celles dont on a besoin. On choisit aussi des cadres de travail différents, comme Akka et Spark qui ajoutent des fonctionnalités supplémentaires aux langages de développement. Les microservices libèrent un potentiel énorme, car toutes les technologies sont utilisables, selon le besoin. C’est aussi vrai pour les formats de données, on en utilise plusieurs (Protobeuf et Avro) sans aucun souci. Cette pléthore de possibilités apporte des réductions de coûts si la DSI opte pour des solutions open source. Cette flexibilité technologique rapproche les services des métiers et favorise l’innovation.
Les microservices boostent la vélocité
Ces systèmes assurent aux équipes un gain de vélocité dans la production et la mise en service de nouvelles fonctionnalités. Grâce aux méthodes agiles, l’automatisation des tests et du déploiement réduit le temps de la fin de développement jusqu’à la mise en production. Les tests QA, de recette, sont aussi automatisés. Colissimo utilise Cucumber pour fabriquer des scénarios de test à partir de requêtes en langage naturel.
Tout est accéléré grâce aux outils présentés plus haut, et le time to market est extrêmement rapide. Maintenant, le métier passe plus de temps à concevoir un type de notification à envoyer aux client, qu’à la développer et la mettre en service ! Les notifications (SMS, Email, Push) résultent de règles métier. Dans une architecture monolithique, elles demandent du code complexe. Dans les microservices, un outil comme Drools permet avec une syntaxe simple de créer de nouvelles règles métier à la volée. Aujourd’hui, les mises en production prennent 10 à 15 minutes. Avant, cela durait plusieurs heures.
ROI du passage d’une architecture monolithique à une architecture microservices
Les microservices permettent de développer des applications en parallèle, ce qui demande un peu d’organisation en matière de recette. Il n’est pas rare d’avoir dans un sprint des évolutions sur une dizaine d’applications avec des dates de production sur une même semaine. La parallélisation est possible car les applications sont indépendantes. En réduisant le temps de développement, on réduit mécaniquement les coûts. Autre avantage de cette parallélisation : le delivery en continu. On abaisse le délai de mise en production à 3 jours. Une architecture en microservices paraît complexe à mettre en œuvre, car elle demande un temps de réflexion assez important, mais en contrepartie elle libère le potentiel des équipes et de la DSI. Elle favorise l’innovation et libère l’entreprise des contraintes de temps, de qualité et de coûts. Chez Colissimo, la DSI est passée du rôle d’exécutant à celui de porteur d’idées innovantes.
_____________________________________________________________________________
Tout simplement “Agile Fan” !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Nidhal
