Euler Hermes parie sur un cloud sans serveur et 100% as code
S'abstraire de l'infrastructure informatique qu'elle soit matérielle ou logicielle : voilà le pari que s'est lancé Euler Hermes à l'occasion de la migration de ses systèmes d'information vers le cloud. Un projet amorcé en 2017 qui doit s'étaler jusqu'en 2024. Comptant 5 800 collaborateurs dans 50 pays pour un CA de 2,7 milliards d'euros en 2018, le spécialiste français de l'assurance-crédit filiale d'Allianz a frappé fort. "Il était nécessaire de refondre la quasi-totalité des systèmes d'information : site web, data, back-office, middle-office...", se souvient Antoine Larmanjat, CIO du groupe Euler Hermes. "Nous avons décidé de 'replateformer' ces applications et optimiser leur nombre." Une couche d'API vient coiffer le nouvel édifice. Objectif : offrir aux marketplaces, ces nouveaux entrants s'ajoutant aux clients traditionnels, un canal digital, performant et résilient pour réaliser leurs demandes d'agrément. Pour se soustraire de l'infrastructure cloud d'Amazon, la société s'oriente dès que possible vers son service "sans serveur" : Lambda.
"La finalité est de réduire au minimum l'effectif de la DSI qui ne développe pas d'applications business", précise Antoine Larmanjat pour expliquer cette stratégie serverless first. "Quand je suis arrivé en 2017, 20 à 30% du personnel IT était en charge de l'infrastructure on-premise, sur les 550 personnes de la DSI." Deux ans après, les besoins en ingénieurs système se sont raréfiés. Une part de ces profils se sont reconvertis dans le code. Certains ont été mutés chez Allianz dont les centres de données restent conséquents en interne. Quant aux développeurs d'Euler Hermes, ils sont désormais en charge de la production des logiciels qu'ils programment, avec des astreintes à la clé. Via l'environnement Terraform, ils scriptent eux-mêmes l'infrastructure de leur projet. Quand ils ne prennent pas la forme de fonctions Lambda, les scripts en question pilotent les services cloud d'Amazon par API. Formalisée via la méthode agile Spotify, l'organisation DevOps d'Euler Hermes est intégrée de bout en bout. "Lambda s'auto-maintient et s'auto-dimensionne. C'est là ses principaux avantages. You build it, you run it", reconnait Antoine Larmanjat.
Une IA embarquée
Le service serverless d'Amazon a conduit Euler Hermes à abolir les batchs. Les traitements pas lots sont "progressivement remplacés par une infrastructure temps réel". Exemple : lorsqu'un client désire réaliser une recherche sur une entreprise par exemple., il sollicite l'API proposée dans ce domaine par la société de La Défense. L'interface génère un événement qui est streamé par Amazon Kinesis. Ce dernier déclenche immédiatement une fonction Lambda pour puiser l'information dans la base d'entreprises du groupe. Adossée à Amazon Elasticsearch, elle référence pas moins de 80 millions d'entreprises. En quelques millisecondes, le résultat est renvoyé au client.
"Evidemment dans un tel environnement, la sécurité est un élément clé"
Autre exemple d'application de Lambda mise en œuvre chez Euler Hermes : la gestion des demandes de limite de crédit ou de notation d'entreprise. Là encore, l'interface sollicitée fait appel à une fonction Lambda. En mode synchrone, celle-ci analyse le risque de crédit via une IA puis renvoie immédiatement le résultat au client. Pour optimiser les performances du processus, la fonction embarque directement le modèle de machine learning préalablement entraîné. Enfin, Lambda est utilisé pour charger le data warehouse d'Euler Hermes, lui-aussi hébergé sur AWS.
"Evidemment dans un tel environnement (combinant services cloud et API, ndlr) par définition très ouvert, la sécurité est un élément clé. Elle doit être efficace sans pour autant faire perdre ce qui a été gagné en performance et en simplicité", insiste Antoine Larmanjat. Pour monitorer ses processus serverless, Euler Hermes recourt aux outils open source de supervision Grafana et Prometheus.
Comment passer outre les limitations
Autres contraintes à avoir en tête : les limitations imposées par Lambda. Les fonctions d'Amazon ne peuvent pas dépasser 50 Mo et 250 Mo en mode non-compressé. "Du coup, nous avons été obligés d'optimiser le poids du code du modèle de machine learning utilisé pour les credit limit request pour qu'il ne dépasse pas ce seuil", précise Antoine Larmanjat. Autre limitation : le temps d'exécution des fonctions ne peut excéder 15 minutes, ce qui met par définition sur la touche les traitements longs, par exemple dans le big data et le calcul massivement distribué.
Dernière restriction de Lambda, l'initialisation par Amazon des fonctions demande un certain délai, de quelques dizaines à centaines de millisecondes. Une contrainte qui a conduit Heuler Ermes à mettre en place un processus de pré-provisionning de fonctions dans le cas des traitements critiques. En ligne de mire : disposer de fonctions dites chaudes prêtes à entrer en action à tout moment.
"Quand un projet n'est pas éligible à Lambda, nous optons pour d'autres solutions : une architecture Amazon ECS ou encore AWS Fargate, voire des instances EC2 le cas échéant", reconnait le DSI d'Euler Hermes. Mais dans tous les cas, l'architecture sera codée sur Terraform, en exploitant les API d'Amazon.