Un peu d'histoire: de monolithique vers les microservices ( Netflix/Uber)
À mesure que de nouvelles technologies émergent la transformation numérique, l'acte d'adopter ces nouvelles technologies, devient plus cruciale pour les organisations de toutes tailles, des startups aux entreprises de plusieurs décennies. Pour rester compétitif, vous devez considérer comment votre entreprise s'adaptera aux technologies émergentes et comment vos applications évolueront également. Le style architectural exact que vous adoptez pour votre application dépendra de vos besoins uniques, mais les monolithes et les microservices sont des architectures très présent. Pour déterminer lequel vous convient, vous devez d'abord comprendre les différences entre les applications monolithiques et microservices, ainsi que leurs avantages et inconvénients.
L'architecture d'une application monolithique est généralement déterminée au début du cycle de vie de l'application. Pour de nombreuses applications, l'architecture est déterminée au moment de la création de l'entreprise. Au fur et à mesure que l'entreprise se développe et que l'application évolue, les développeurs qui ajoutent de nouvelles fonctionnalités se retrouvent souvent contraints et limités par les choix effectués lors de la conception initiale de l'application. Elle est limitée par le choix du langage, par les bibliothèques qu'elle peut utiliser, par les outils de développement avec lesquels elle peut travailler et par la nécessité d'effectuer des tests de régression approfondis pour s'assurer que chaque nouvelle fonctionnalité ajoutée ne perturbe pas ou ne compromet pas l'ensemble de l'application. Tout refactoring d'une application autonome et monolithique reste essentiellement limité par les décisions architecturales initiales : les conditions initiales déterminent exclusivement l'avenir de l'application.
L'adoption d'une architecture de microservices apporte une "liberté" considérable aux développeurs. Ils ne sont plus liés aux décisions architecturales du passé. Ils peuvent concevoir leur service comme ils le souhaitent et ils sont libres de choisir le langage, la base de données, les outils de développement, etc. Le message qui accompagne les conseils en matière d'architecture de microservices est généralement compris et entendu par les développeurs:
construisez une application qui fait une chose, une seule chose et qui fait cette chose extraordinairement bien. Faites ce que vous avez besoin de faire, et construisez-la comme vous le voulez. Il faut juste s'assurer qu'elle permet de faire le travail.
Même si cette idéalisation romantique du développement de microservices est vraie en principe, tous les microservices ne sont pas créés égaux - et ne devraient pas l'être. Chaque microservice fait partie d'un écosystème de microservices, et des chaînes de dépendance complexes sont nécessaires. Lorsque vous avez cent, mille ou même dix mille microservices, chacun d'entre eux joue un petit rôle dans un très grand système. Les services doivent interagir de manière transparente les uns avec les autres et, surtout, aucun service ou ensemble de services ne doit compromettre l'intégrité de l'ensemble du système ou du produit dont il fait partie.
Netflix : Un pionnier des microservices
En 2009, Netflix faisait face à des défis significatifs à cause de sa croissance rapide. L'infrastructure de la société ne parvenait pas à supporter la demande croissante pour ses services de streaming vidéo. Pour résoudre ce problème, Netflix a choisi de migrer son infrastructure de data centers privés vers le cloud public, tout en remplaçant son architecture monolithique par une architecture de microservices. À l'époque, le concept de « microservices » n'était pas encore bien établi.
Netflix a été l'une des premières grandes entreprises à réussir cette transition, ce qui lui a valu le prix JAX Special Jury Award en 2015. Cette réussite est en partie attribuée à sa nouvelle infrastructure intégrant les principes de DevOps. Aujourd'hui, Netflix utilise plus de mille microservices pour gérer différentes parties de sa plateforme, et ses ingénieurs déploient fréquemment des mises à jour logicielles, parfois des milliers de fois par jour.
Cette transformation de Netflix est devenue un exemple de référence dans le passage d'une architecture monolithique à une architecture de microservices, un changement qui est désormais de plus en plus adopté dans l'industrie.
Vous connaissez surement la stack Netflix OSS:
- Service Discovery (Eureka),
- Circuit Breaker (Hystrix),
- Intelligent Routing (Zuul)
- Client Side Load Balancing (Ribbon).
Uber : Un autre exemple de succès
Uber a démarré son service à San Francisco avec une version monolithique. Ce repo monolithique contenait la logique métier permettant de faire le matching entre les chauffeurs et les passagers, de vérifier des taches en background, de s'occuper de la facturation et du paiement, ainsi que de toutes les autres fonctionnalités connexes.
Au fur et à mesure que le service devenait populaire, l'équipe d'ingénieurs a été confrontée à des problèmes typiques connus des monolithiques. Les problèmes d'évolutivité, les composants étroitement couplés, l'ensemble de la code base devant être redéployé pour une infime modification du code, etc.
En bref, il y avait toujours ce risque d'impact en cascade de la modification du code sur les fonctionnalités existantes. Les implémentations d'une seule version nécessitaient de sérieux tests de régression après les déploiements. L'ajout de nouvelles fonctionnalités était fastidieux. Tous ces problèmes nécessitaient davantage de ressources de la part des développeurs.
L'équipe a décidé de se libérer en passant à une architecture distribuée de microservices. Chaque service prendrait en charge l'exécution d'une fonctionnalité spécifique. Les choses seraient couplées de manière plus souple. Les équipes pouvaient s'approprier les microservices. Il était plus facile d'ajouter de nouvelles fonctionnalités et de modifier le code sans risquer de tout casser.Il serait possible d'exploiter la puissance d'une variété de technologies. L'équipe ne serait pas contrainte d'écrire des fonctionnalités utilisant une seule technologie.
La transition architecturale s'est traduite par plus de 500 microservices. Mais comme tout dans l'univers du développement logiciel est un compromis, il n'y a pas de solution miracle, pas de technologie ou de conception parfaite. Ces services ont nécessité un investissement important en ressources pour la gestion de l'infrastructure. Ces microservices nécessitaient une infrastructure standardisée pour communiquer entre eux et la mise en œuvre de nombreuses fonctionnalités supplémentaires telles que l'authentification et l'autorisation pour chaque service, la sécurité des typages, la validation, la prise en charge des logs, la traçabilité des services distribués, la tolérance aux pannes, la gestion des timeout côté client, les politiques de relance (retry policies), les interruptions de service, la découverte de services, une approche de test standardisée, la prise en charge de plusieurs langues, un contrat de communication auquel tous les services et les clients qui consomment les services pourraient adhérer et ainsi de suite.
La transition des architectures monolithiques vers les microservices a été un tournant majeur pour de nombreuses entreprises technologiques comme Netflix et Uber. Cette approche permet de surmonter les limitations des monolithes en offrant une plus grande flexibilité, scalabilité et résilience. Les leçons tirées de ces pionniers ont influencé l'industrie, rendant les microservices une architecture privilégiée pour le développement d'applications modernes.
TakkJokk
