Sachez jauger l'opportunité de migrer vers une architecture moderne

La seule chance de voir ses coûts d'exploitation baisser en migrant vers une plateforme mutualisée, est d'opter pour une architecture logicielle suffisamment modularisée et parfaitement distribuée. En effet, les architectures "archaïques" n'offrent pas suffisamment d'opportunités d'économies d'échelle pour amortir l'investissement de départ. Alors, bien sûr, il existe de nombreux exemples de succès de migration de systèmes monolithiques vers des architectures de microservices dans le cloud :

D'abord, Netflix (déjà remarquée pour son investissement précoce dans l'ingénierie du chaos) est un excellent exemple de migration réussie vers une architecture de microservices dans le cloud, sous le nom de projet Reloaded. L'entreprise est parvenue à améliorer la flexibilité et l'évolutivité de son système, ainsi qu'à développer et déployer des fonctionnalités plus rapidement. Elle a pu améliorer la disponibilité de son service en optimisant les performances de l'infrastructure et la conception des modules applicatifs. Ce dernier point étant primordial, car la réduction de la facture globale ne s'obtient qu'à force de remises en question, en l'occurrence vers le serverless (projet Cosmos) qui a permis de supporter le triplement des utilisateurs.

Amazon (le "libraire") est également parvenu à développer et à déployer de nouveaux services indépendamment les uns des autres, grâce aux microservices. Cette architecture lui a permis d'évoluer rapidement, de gérer un trafic élevé et de répondre aux besoins changeants de ses clients. Bien sûr, ce chantier est allé de paire avec l'évolution de sa plateforme publique, et AWS (comme d'autres) propose une expertise pointue sur le sujet de la migration vers le cloud des applications et des données, depuis des systèmes monolithiques ou non.

De même, Uber et Spotify ont réalisé une migration afin de maîtriser leurs croissances rapides et de répondre à la demande évolutive de leurs services de réservation de voitures et d'écoute en ligne. L'architecture microservices leur a permis de produire de nouvelles fonctionnalités plus rapidement et d'améliorer la résilience de leur système d'information, afin de prendre en charge un grand nombre de demandes simultanées.

Et en dehors des tech companies ?..

Dans le secteur bancaire, où les architectures mainframe ont historiquement dominé, il y a eu des exemples de migration réussie, bien que parfois partielle, vers le cloud.

Capital One, une grande institution financière aux États-Unis, a effectué avec succès sa migration en utilisant des technologies de virtualisation telles que Docker et Kubernetes pour découper leur système monolithique en services indépendants plus résilients et évolutifs.

BBVA, une banque internationale basée en Espagne, a adopté une approche progressive en isolant des parties spécifiques de leur système monolithique et en les reconstruisant sous la forme de services indépendants. Cette transition leur a fait bénéficier d'une plus grande agilité, leur permettant d'améliorer leur capacité à innover et de réduire les coûts liés à la maintenance des systèmes hérités.

DBS Bank qui est basée à Singapour, a entrepris une transformation numérique majeure en adoptant une approche de modernisation progressive grâce à de nouveaux services construits autour de leur infrastructure existante. Leur capacité à fournir de nouveaux services s'est améliorée, ainsi que l'expérience client, avec une capacité d'adaptation rapide aux évolutions du marché.

Cependant, ces migrations sont complexes et nécessitent une planification minutieuse pour garantir la sécurité des données, la conformité réglementaire et la continuité des opérations bancaires critiques. Bien qu'il soit plus difficile de dater précisément les périodes pendant lesquelles les systèmes bancaires ont effectué leur migration, on retiendra que les grands noms du secteur IT l'ont effectuée vers les années 2010 ; à part Amazon, qui avait anticipé cette évolution dès les années 2000 !

Mais est-ce que ça fonctionne à tous les coups ?

Il est moins facile de se renseigner sur des exemples d'échecs de migrations vers des architectures de microservices dans le secteur bancaire. Les institutions financières ont tendance à rester discrètes sur les problèmes techniques ou les échecs potentiels, en raison des implications en matière de sécurité, de confidentialité et de confiance des clients. Les migrations vers des architectures cloud présentent des défis importants, et il y a des situations où elles peuvent échouer ou rencontrer des difficultés significatives.

1. La transition d'une architecture monolithique à des microservices peut entraîner une complexité accrue dans la gestion des services, des dépendances entre les services et des communications entre eux. Une mauvaise planification ou une mauvaise conception peuvent provoquer des problèmes graves d'intégration et de coordination.
2. Lorsqu'un système monolithique est décomposé en microservices, il peut y avoir des dépendances cachées ou mal comprises entre les différentes parties du système. Cela rend la migration difficile et entraîne aussi des problèmes d'intégration.
3. Beaucoup d'acteurs réalisent aujourd'hui l'importance de la migration des données dans la trajectoire de relocalisation des systèmes d'information, mais pas tous. Cependant, il ne faut jamais négliger l'enjeu de la migration du code qui, dans le cas des mainframes bancaires ayant plusieurs dizaines d'années d'existence, représente couramment un capital de millions de lignes dans des langages largement dépréciés.
4. La transition vers des architectures distribuées nécessite un changement culturel et organisationnel important, car il s'agit d'une approche décentralisée du développement et du déploiement des logiciels. Si l'organisation n'est pas prête à adopter ce changement, cela entraîne des résistances internes et des difficultés de mise en œuvre.
5. Bien que les architectures de microservices puissent offrir une évolutivité et une disponibilité améliorées, elles peuvent également introduire des problèmes de performance et de latence si la communication entre les services n'est pas optimisée ou si les services ne sont pas correctement dimensionnés.

Bien sûr, les échecs ne sont pas une indication que les architectures de microservices soient intrinsèquement mauvaises ou impraticables, loin de là. Ils soulignent plutôt l'importance d'une planification approfondie, d'une compréhension claire des défis et des risques, et d'une exécution soignée lors de la migration progressive vers une architecture moderne.