Dans une ère sans précédent d’attentes élevées de la part des clients, de la faible confiance du marché et de la menace constante de petits joueurs perturbant le marché, les institutions financières se trouvent dans une position où elles doivent évoluer ou disparaître. Étant donné que les acteurs établis continuent de dépendre de la technologie existante et des systèmes monolithiques nécessitant des frais généraux importants et des délais supplémentaires pour fournir même la plus petite augmentation de valeur, beaucoup ont du mal à satisfaire les besoins de leurs clients et de leurs actionnaires. Leur capacité à rester compétitive diminue.

Il est temps que les institutions financières prennent le saut, comme leurs homologues technologiques ont fait, et embrassent le mouvement d’architecture micro services. Pour de nombreuses entreprises, telles que Netflix, Amazon, Gilt et PayPal, une architecture micro services a été la base qui leur a permis d’étaler rapidement, de valoriser et de devenir un leader de l’industrie. Au cours des dernières années, l’intérêt pour les micro services a augmenté, et selon Google Trends, il continue de croître. Cependant, la transition n’est pas simple, et toutes les entreprises ne réussissent pas.

Un bon exemple dans l’espace bancaire est le système bancaire de base que l’on retrouve au plus haut niveau de l’organisation informatique. Ces plates-formes sont généralement basées sur les lots, en grande partie monolithiques et anciennes selon les normes technologiques. Le défi qui  caractérise généralement ces plates-formes monolithiques est que les applications tournées vers le client doivent évoluer plus rapidement, mais elles ont des dépendances de données sur les services bancaires de base. Même si votre application utilise une méthodologie agile pour aller sur le marché, les  changements qui ont une incidence sur le core banking retardent l’acheminement de l’ensemble à temps. C’est un exemple parfait où une architecture de micro services en couches, sur le core banking pourrait découpler les cycles de publication et accroître l’agilité pour l’ensemble du système.

Cette publication explore pourquoi la mise en œuvre d’une architecture de micro services n’est pas simple et offre des conseils sur la manière dont les institutions de services financiers, en particulier les banques, peuvent efficacement évaluer et adopter le mouvement d’architecture micro services.

Qu’est ce qu’une architecture orientée micro service ?

Il y a une myriade de livres sur les micro services, tels que « Building Micro services » de Sam Newman. Martin Fowler a également écrit beaucoup sur ce sujet. En bref, les micro services proviennent de la même idéologie que Agile et DevOps en cherchant à décomposer les systèmes monolithiques à déplacement lent en de multiples petits services indépendants, fortement découplés et autonomes pour se concentrer sur une fonction ou une capacité spécifique. Cette dégradation des systèmes en pièces gérables qui fonctionnent indépendamment en parallèle permet aux grandes organisations d’être plus souples pour se déplacer à la vitesse de leurs concurrents plus petits. De plus, les micro services sont une approche technologique-agnostique, de sorte que les adopteurs peuvent exploiter différentes technologies. Cependant, cela ne signifie pas que vous devriez vous efforcer d’avoir un «zoo», mais que vous n’êtes pas lié à certains cadres et que vous pouvez utiliser les technologies appropriées et applicables.

Ce que les banques doivent comprendre à propos des micro services

Je suis un grand fan des micro services. Tout au long de ces deux dernières années, j’ai reconnu qu’une architecture micro services est tout à fait capable de résoudre des problèmes … si elle était correctement appliquée. Le mot-clé est « si ». J’ai vu de nombreuses entreprises adopter une architecture micro services seulement pour apprendre plus tard dans le processus qu’il impliquait beaucoup plus de complexité. De nombreuses questions à l’échelle de l’organisation doivent être immédiatement répondues et, après plusieurs mois, certaines entreprises abandonnent complètement l’effort. À l’inverse, ceux qui savaient comment appliquer le processus correctement ne reconnaissaient pas que le projet / produit n’avait pas besoin d’être fait dans un environnement de micro services. Il existe de nombreux avantages pour les micro services, en particulier avec des entreprises qui traitent de nombreuses données différentes issues de diverses sources de données. En général, ce sont les institutions financières, les services de renseignement de données, les services IOT et les sociétés de commerce électronique à grande échelle. Alors, qu’est-ce que je veux dire par « si appliqué correctement »? Aussi agréable que cela puisse paraître et autant que la plupart des développeurs souhaitent passer à un environnement micro services, il peut y avoir des pièges cachés. Une architecture micro services ne rend pas votre logiciel plus simple. En fait, cela rend plus compliqué! Il y a plus de pièces « mobiles » que dans une approche monolithique. Il est également plus difficile de surveiller, de gérer, de version et de désactiver. Deuxièmement, vous ne pouvez pas acheter une architecture micro services pour vous-même. Ce n’est pas un produit. Toute l’entreprise doit adopter une architecture de micro services pour réussir et tirer le meilleur parti d’une telle architecture.

Les bénéfices que cette architecture apporte

Si elle est correctement mise en œuvre, les micro services ont beaucoup d’avantages, y compris de plus petites unités de fonctionnalité, ce qui la rend:

• Plus simple et plus rapide à développer (moins d’informations dans les spécification du développeurs ).
• Plus facile de refactorer, de modifier (plus petite empreinte).
• Plus facile à mettre à l’échelle (il suffit de répliquer les instances).
• Plus rapide à déployer (moins de fonctionnalité et dépendances moins dures)
• Une empreinte d’échec plus petite (seule une partie d’un système peut être en panne à la place de tout le système).

Pourtant, pour gérer correctement une architecture micro services, toute l’entreprise doit optimiser et aligner ses opérations. Ce n’est plus que du point de vue du développement. Pour réussir, d’autres parties de l’organisation devront également être touchées. Par exemple:

• Les propriétaires de produits devront trouver des exigences plus petites et, en tant que tels, plus faciles à comprendre avec une portée beaucoup plus petite. Cela équivaut à moins d’attente jusqu’à ce que la mise en œuvre soit terminée.
•  Les équipes entières seraient plus petites, plus agiles et travaillent avec une portée plus petite.
• Il y aura un lien étroit avec les équipes DevOps, car un plus grand nombre de services rendrait nécessaire une automatisation complète du déploiement.
• Bonne communication organisationnelle avec support d’application pour surveiller les centaines de services. Pour ce faire, vous aurez besoin d’outils appropriés, de suivi, de récupération et d’alerte appropriée pour vos services.
• Documentation sur le service de vie. La documentation doit également être automatisée ou vos points d’extrémité seraient inutiles même dans votre entreprise

Quel est le meilleur chemin pour effectuer cette transaction?

Pour commencer votre transition vers une architecture micro services, examinez d’abord les questions suivantes:

• Votre organisation a-t-elle vraiment besoin de micro services? Vous devez être capable de répondre à cette question.
• Avez-vous la bonne compétence en interne? Les micro services sont plus complexes que les applications monolithiques traditionnelles et vous aurez besoin d’une équipe avec une expertise approfondie dans l’architecture micro services. Les équipes inexpérimentées peuvent effectivement produire des résultats inverse (vous obtiendrez une solution totalement obscène).
• Est-ce que tous les services sont d’accord avec le passage à l’architecture des micro services? Tous les départements (tels que le support d’application, la sécurité) doivent être alignés car il s’agit d’un changement à l’échelle de l’organisation.

Une fois que vous êtes convaincu qu’une architecture micro services est bien adaptée à votre organisation et que vous avez un « go » organisationnel, le plus grand défi consiste à comprendre ce qui sera nécessaire et à la portée de vos affaires. La plupart de la littérature suggère, et je suis d’accord, que l’élimination des systèmes existants en petits morceaux une par une jusqu’à ce qu’un produit entier soit une collection de micro services est le chemin à parcourir. Cela vous permet de créer l’infrastructure requise au fur et à mesure. Beaucoup d’entreprises tombent dans un piège dès le début en commençant par un petit projet de terrain vert (environ trois mois) et essayez de faire une preuve de concept de micro services à ce stade. Cela se termine par un service à moitié prêt qui a des problèmes de déploiement, manquant de journalisation, de traçage et de découverte (service discovery). Alors, qu’est-ce qui se passe réellement dans ces situations? Le problème est que la portée n’est pas comprise à l’avance. Les exigences métier peuvent être correctes et assez claires, mais les exigences non fonctionnelles ne sont pas claires à ce stade. L’approche habituelle des questions non fonctionnelles, telles que «Comment logger?» est-ce que nous supprimons un fichier, nous le classerons plus tard. Donc, la question devient « plus tard quand? » À ce stade, l’équipe DevOps construit une sorte de déploiement (généralement en utilisant les anciennes méthodes), le support d’application obtient leur suivi du journal des fichiers texte, les exigences commerciales sont là. Peut ont sans aucun risque dire que nous venons de mettre en place des micro-services? La réponse est non. C’est à peu près le même genre de service avec moins de fonctionnalité et des artefacts semi-terminés qui l’accompagnent. À ce stade, il existe un risque important de revenir aux applications / services monolithiques qui sont plus familiers. C’est pourquoi je suggére de veiller à ce que votre organisation dispose d’une équipe avec une expertise approfondie dans l’architecture des micro services.

Étape suivante:

Les micro services ne sont pas seulement un développement. Il s’agit de sécurité, découverte de service, automatisation du déploiement, enregistrement et de la surveillance agrégés. Cela inclut beaucoup d’ infrastructures qui doivent exister ou alors une décision devra être prise avant le début du développement. Nous aborderons cet aspect des micro services dans un futur article.