AUTEURS
Martino Zito
Director @Bip xTech
Dernièrement, on parle beaucoup de “micro-services”, mais de quoi s’agit-il réellement et comment les utiliser de manière efficace et rentable?
Ces derniers temps, on parle beaucoup des “micro-services”. Ce soudain regain de popularité est déjà en soi remarquable : jamais autant d’attention n’a été accordée à un style/une pratique d’architecture logicielle. Jusqu’à aujourd’hui, le sujet des architectures logicielles a toujours été l’apanage des spécialistes du secteur, et le fait de voir un tel sujet faire écho dans divers médias nous surprend beaucoup.
Les architectures de micro-services (alias AMS) sont utilisées pour la création de couches de services applicatifs de systèmes ou de plateformes. L’architecture, à un niveau élémentaire, consiste en un ensemble de processus (micro-services) qui interagissent les uns avec les autres. Chaque micro-service se comporte indépendamment des autres et est capable de communiquer via le réseau au moyen d’interfaces logicielles structurées, synchrones ou asynchrones (par exemple REST, Message Queue, …). Chaque micro-service traite de la gestion d’une ressource ou d’une fonction métier, et possède sa propre indépendance technologique (langages, frameworks) et sa propre couche de persistance. Une bonne conception dans le contexte des micro-services permet également de répartir le travail de mise en œuvre entre plusieurs équipes potentiellement indépendantes.
Vu sous cet angle, un micro-service donné n’est donc pas très différent d’une couche de service d’application classique sur un périmètre limité de fonctionnalités. Alors comment un artefact technique tel que l’AMS peut-il faire autant de vagues ? Est-il vraiment innovant ? Est-il vraiment un “game changer” ? Ou s’agit-il simplement d’une énième réinterprétation de concepts qui sont désormais soit des bonnes pratiques, soit des lieux communs ?
D’un point de vue purement technique, et par rapport au micro-service unique, la réponse à la dernière question est qu’”il n’y a pas de grande différence”.
La clé du succès réside essentiellement dans le fait que les architectures de micro-services sont le sommet évident de toute une série d’autres méthodologies et technologies : Agile, API First Design, Behavior Driven Development, Code Infrastructures et DevOps, pour n’en citer que quelques-unes.
En fait, lorsqu’elle est évaluée avec ces dernières technologies et méthodologies, l’AMS présente, à toutes fins utiles, les caractéristiques d’un “game changer”.
Pourquoi adopter une solution basée sur un AMS ?
Sur Internet, on trouve souvent des listes interminables d’avantages et d’inconvénients résultant de la mise en œuvre d’une architecture de micro-services ; il y en a tellement en fait que le lecteur finit par être confus et parfois, dépassé. Dans cet article, je résume certains des avantages significatifs qui peuvent justifier l’adoption d’un AMS.
Commençons par faire une distinction entre l’achat d’une solution basée sur l’AMS et sa construction. Il est clair que les avantages que l’on obtient dans le cas d’un “achat” s’appliquent également dans le second cas – la construction de l’AMS – après que les efforts nécessaires aient été déployés pour la première réalisation.
Dans le premier cas (achat), la solution présente les caractéristiques suivantes “prêtes à l’emploi” :
Indépendance vis-à-vis de l’environnement. Les solutions sont basées sur des “conteneurs”. Par conséquent, à condition de disposer d’un orchestrateur (ex : Kubernetes, OpenShift, Mesos), elles peuvent être installées “sur le site du client” ou sur n’importe quel fournisseur de cloud public et peuvent être déplacées si nécessaire.
Extensibilité indépendante. Chaque micro-service peut être mis à l’échelle (répliqué) indépendamment des autres en adaptant l’ensemble de la solution à la charge requise. Finalement, pour les charges impulsives, le microservice unique peut être réduit à zéro et activé uniquement en cas de besoin.
Déclin fonctionnel limité. Les microservices étant indépendants les uns des autres, la défaillance de l’un d’entre eux n’entraîne pas le dysfonctionnement de l’ensemble du système, mais le dysfonctionnement est uniquement limité au microservice affecté.
Mise à jour rapide et “à chaud”. Chaque microservice peut être mis à jour indépendamment des autres, de manière “plug & play”. Il est également possible de mettre à jour l’ensemble de la solution très rapidement, avec une perturbation nulle ou limitée (quelques minutes plutôt que quelques heures).
Si, toutefois, vous décidez de créer une solution à partir de zéro (ou de faire migrer une solution existante vers un AMS), l’architecture dans ce deuxième cas présente les caractéristiques suivantes :
Réalisation parallèle. Les micro-services étant indépendants les uns des autres, il est possible de paralléliser leur réalisation, ce qui réduit le délai de livraison et, par conséquent, le délai de commercialisation.
Indépendance technologique et polyglotisme. Les microservices individuels peuvent être créés avec des langages, des frameworks et des technologies différents. Cela permet d’utiliser la technologie de manière plus conforme au besoin imposé par la fonction commerciale que le microservice prend en charge, et d’exploiter les compétences déjà disponibles dans les différentes équipes.
Réutilisabilité des artefacts. Certains micro-services qui présentent des fonctions standard (ex : journalisation, audit, comptabilité, stockage de fichiers) peuvent déjà être disponibles et peuvent être utilisés dans une logique “plug & play” dans le cadre de la mise en œuvre.
Maintenabilité. Chaque micro-service est remplaçable par une version différente et améliorée tant qu’il respecte son interface de service. En outre, comme son code source est généralement relativement petit, il est facile à maintenir et à tester.
Extensibilité. S’il s’avérait nécessaire d’étendre les fonctionnalités du système, il suffirait d’ajouter des micro-services supplémentaires.
Est-il toujours avantageux de construire des architectures de micro-services ? Pas toujours. Une telle architecture s’est avérée efficace pour les systèmes riches en fonctionnalités ou les systèmes dont l’expansion est prévue à l’avenir. Si la mise en œuvre était petite et son périmètre parfaitement défini, d’autres architectures seraient plus “rentables”.
Les compétences nécessaires pour introduire une AMS dans votre entreprise:
Les AMS, comme toutes les architectures distribuées, nécessitent la présence d’un architecte logiciel pour leur mise en œuvre. Cette figure est de plus en plus flanquée de figures, jusqu’à présent peu présentes, telles que les ingénieurs DevOps, les ingénieurs de test et les architectes d’infrastructure cloud.
La complexité du travail passe du codage (relativement simple une fois les interfaces et les fonctionnalités définies) à la planification et à la conception. Une révision des modèles de conception est nécessaire pour répondre à des problèmes auparavant contournables ou inexistants.
L’avènement des AMS a conduit à la réinterprétation de certains termes existants, voire à la création de nouveaux termes. Voici quelques exemples notables : Event Sourcing, CQRS, Circuit Breaking, Saga, Eventual Consistency, API Gateway, Service Mesh.
La création d’une plateforme basée sur cette architecture introduit deux thèmes importants qui doivent être pris en compte : le changement culturel ainsi que la formation et la requalification des ressources.
Les principaux facteurs de réussite d’une mise en œuvre de l’AMS sont l’approche et la méthodologie plutôt que les technologies elles-mêmes.
Cas de réussite de la mise en œuvre de l’AMS:
D’un point de vue mondial, les AMS sont apparus au niveau de l’entreprise il y a environ 6 ans. L’un des précurseurs internationaux de la mise en œuvre des AMS a été la plateforme de streaming vidéo Netflix, suivie presque simultanément par le service de streaming audio Spotify, la plateforme de réservation AirB&B et le site de commerce électronique de vêtements Zalando. Chacun d’entre eux a contribué au succès de l’AMS en partageant son expérience et les “leçons apprises”.
Le cas le plus emblématique de réussite commerciale due à l’utilisation d’une architecture de micro-services est peut-être celui d’Amazon[1] . Le site web d’origine pour l’achat de livres en ligne était en effet une application monolithique, dans laquelle l’ajout de nouvelles fonctionnalités pour l’utilisateur final était très complexe tant d’un point de vue technique qu’organisationnel, et qui offrait une évolutivité limitée en cas de pics de demandes. Amazon s’est donc engagé sur la voie de la réingénierie des applications avec des micro-services dédiés à des fonctionnalités commerciales individuelles (comme le panier d’achat), chacune gérée par une seule équipe de développement, et des processus de mise en production standardisés et automatisés avec des pratiques CI / CD. Cela a permis à Amazon de créer des millions de nouvelles fonctionnalités chaque année, et de rassembler de nouvelles compétences importantes dans la création d’infrastructures hautement évolutives, ce qui a conduit à la fondation d’AWS en 2006, générant une nouvelle activité pour l’entreprise.
À la suite de ces exemples de réussite, d’innombrables entreprises des secteurs B2C et B2B sont en train de créer de nouvelles plates-formes “AMS-by-design” ou de les faire passer d’un style architectural différent à un style plus orienté AMS.
Depuis quelques années, les grandes entreprises italiennes ont également migré certains de leurs systèmes d’entreprise destinés à une utilisation B2C ou B2B vers un style AMS, reconnaissant son applicabilité et ses avantages, et poussées par les pressions du marché telles que la transformation numérique et la migration vers le cloud.
Aujourd’hui, les AMS sont presque devenus la norme de facto pour construire la couche de services des systèmes et des plateformes.
Micro-services @Bip xTech: une offre de bout en bout
Bip xTech suit ses clients depuis des années dans l’introduction et la mise en œuvre de technologies innovantes. Parmi celles-ci, en ce qui concerne les architectures logicielles, figurent les architectures de micro-services (AMS), les architectures sans serveur (BaaS, FaaS) et les architectures pilotées par les événements (EDA).
Notre équipe de professionnels comprend des architectes logiciels, des architectes d’infrastructure, des ingénieurs DevOps, des ingénieurs chargés des tests et des développeurs capables de couvrir de bout en bout un cycle de mise en œuvre donné.
Depuis 4 ans, presque depuis l’avènement de AMS, Bip accompagne ses clients dans la conception et la mise en œuvre d’applications d’entreprise basées sur AMS, principalement dans le secteur B2B.
Vers l’avenir, ensemble
La connaissance de la technologie et la capacité à la mettre en œuvre sont les ingrédients nécessaires et indispensables à toute réalisation technologique, mais ce ne sont pas les seuls.
Bip a toujours guidé et accompagné ses clients dans le développement de leur activité et aide à gouverner des projets à toutes les échelles de complexité.
La connaissance du domaine et la capacité à gérer des projets, combinées aux compétences techniques, sont la clé du succès des projets, toujours dans le but d’obtenir un bénéfice maximal pour nos clients.
Si vous souhaitez en savoir plus sur notre offre ou avoir une conversation avec l’un de nos experts, veuillez envoyer un courriel à [email protected] avec pour objet “Microservices”, et vous serez contacté rapidement.
Rendez-vous avec le prochain article qui traitera du domaine des “architectures sans serveurs” !
[1] Werner Vogels “Modern applications at AWS”, https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html