Comment Air France - KLM a conçu son PaaS Cloud Foundry

PaaS et CaaS

Il y a 3 ans, le groupe a mis en musique cette stratégie en associant de concert PaaS (Platform-as-a-service) et CaaS (Container-as-a-service).  « En parallèle, nous avons implémenté d’un côté, Docker Swarm (l’orchestrateur de containers de la société Docker, NDLR), et de l’autre, Cloud Foundry dans une déclinaison pure open source », témoigne Thierry Morcq, ajoutant qu’il a perçu un usage distinct des deux plateformes. « En matière de delivery, ces deux solutions ont des services complémentaires ». Docker Swarm répond par exemple à deux usages : la livraison d’image sur la market place, qui répond à une demande spécifique de certains projets ;  et la nécessité d’avoir accès à la couche infrastructure. « On peut faire du fine-tuning sur certaines applications complexes et s’assurer que tout est optimisé », commente-t-il.  A côté de cela, Cloud Foundry traduit justement cette agilité dans une solution intégrée et dans une couche d’abstraction, lorsque ce fine-tuning n’est pas nécessaire.

Pour le responsable, choisir le bon équilibre technologique est clé dans la capacité de répondre aux besoins des métiers, mais également pour porter les compétences des développeurs, généralement attirés par les outils modernes. Les containers, Kubernetes (vers lequel avance également le groupe), le PaaS et l’open source en sont des exemples dans la stratégie d’Air France – KLM.

Il y a 12 mois, Air France - KLM se heurte toutefois  à un problème : parvenir à proposer une qualité de service 24/7 avec le PaaS open source, déployé par les équipes internes. Une composante essentielle, comme l’indique Thierry Morcq. « Une grande marche vers le 24/7 que l’on arrivait pas à franchir. Le SLA est important et il faut le tenir vis-à-vis des métiers. »

Pour Nathan Wattimena, product owner chez Air France – KLM, il était difficile de maîtriser seul Cloud Foundry pour des problèmes de compétences en interne mais aussi pour la difficulté de  passer la plateforme en production. Il évoque également un manque d’alignement avec les applications métiers du groupe. « Il était en fait utilisé pour le prototypage. »

Le choix d’un partenaire était donc devenu nécessaire, mais tout en capitalisant sur des compétences en interne acquises sur le socle Cloud Foundry. Pivotal a été retenu pour accompagner le groupe.

A ce stade, « il ne s’agissait pas de remplacer nos experts mais bien de faire monter en compétence les équipes internes du groupe », nuance toutefois Thierry Morcq.

Pivotal a ainsi permis d’apporter un outillage, une expertise, des bonnes pratiques en matière d’automatisation adaptés au monde des entreprises, renchérit Nathan Wattimena, qui intervenait dans une session lors du Cloud Foundry Summit 2018 de Berlin.

Le chemin vers la conception de la plateforme

 Les équipes de groupe (une trentaine de personnes) ont donc intégré le programme de Pivotal qui permet d’accompagner les clients vers les définitions des exigences et donc vers une plateforme PaaS adaptée. L’éditeur découpe ce processus en trois phases : la phase Canary  qui est une étape de consulting pour identifier les contraintes et les exigences et concevoir les logiques de l’application. A la fin est créée une maquette baptisée Canary ; la phase Dojo qui correspond à un sprint de 8 semaines pour construire la plateforme. Celle-ci s’appuie sur le concept de peering entre collaborateurs (Dev et Ops dans ce cas), et inclut la montée en compétence des équipes internes. Air France KLM en est à cette phase.

Puis suit le Lab qui porte sur la transformation même des applications. « Air France - KLM doit certes amorcer cette transformation, mais on ne sait pas si Pivotal sera choisi pour cela », tient à préciser Thierry Morcq.

Une arrivée au Dojo qui n’a pas été simple, confie par ailleurs Nathan Wattimena, qui cite le changement culturel d’approche que cela a impliqué dans les équipes du groupe. « Les approches du Dojo, le peering, le lean et la disciple étaient difficiles pour nous ». Il précise que la période initialement de 6 semaines en a duré 8 pour ce projet. « Mais cette dimension nous a permis d’apprendre quelque chose. »

Côté développeur, cette phase de Dojo a permis de structurer les exigences métiers. Pour créer cette infrastructure, les équipes de développeurs ont réalisé une enquête pour collecter les besoins et les exigences fonctionnelles. « Plus de 100 exigences ont été qualifiées. 34 ont été nécessaires pour démarrer », témoigne à son tour Fabien Lebrere, ingénieur logiciel chez Air France- KLM . Un MVP (Minimal Viable Product) de la plateforme a été établi à partir de ces critères avec des fonctions cœur (2 services brokers).  Une seconde phase a mis en musique 20 autres exigences pour enrichir la première phase et créer un catalogue de services plus complet. « Quelque 10 services supplémentaires ont été ajoutés », liste-t-il. Les développements se poursuivront selon ce cycle, pour obtenir un catalogue de services plus important.

Cloud Foundry déployé sur trois datacenters

Cette longue étape a abouti sur le déploiement de sept fondations Cloud Foundry dans 3 datacenters. Les déploiements ont été réalisés sur une infrastructure vSphere.

 « Nous sommes partis de zéro, sans même un serveur physique »,  décrit-il, témoin de la difficulté de l’opération. Des intégrations ont été réalisées avec les outils en place de monitoring et de gestion de logs par exemple pour faire entrer la plateforme dans les standards des systèmes Air France - KLM.

La plateforme en 24/7 est aujourd’hui en production et plus d’une dizaine d’applications devrait être placée en production sur cette infrastructure. Une trentaine est en cours d’acception.