Bonjour à tous !

Chez Groupe LaCentrale, nous prenons très au sérieux la disponibilité et la surveillance de nos applications. Nous développons tous les jours de nouveaux services utilisés par des collaborateurs aux métiers divers de l’entreprise mais aussi par des clients externes comme vous.

C’est pour cela que nous prenons soin au sein de chaque équipe de suivre nos applications à l’aide de dashboards présents dans les open space. Ils avertissent des problèmes techniques survenus en direct et nous alertent par notification dès qu’un problème survient. Chaque équipe est responsable de son périmètre.

Cependant, une erreur applicative n’est pas nécessairement provoqué par l’équipe propriétaire de l’application. Cela peut être la conséquence d’un problème survenu précédemment dans le traitement du logiciel. Par exemple lors d’un appel à un service tiers.

Ne vous est il jamais arrivé qu’un web service externe soit défectueux? Nos applications sont aussi tributaires du bon fonctionnement de nos partenaires.

Tout comme Waze qui prévient ses utilisateurs d’un problème lors de leurs trajets, il nous fallait un moyen de prévenir les autres applications de manière manuelle et automatisée dès qu’un problème était présent dans le flux de données.

Dans une vision plus large, et tout en restant dans une métaphore automobile, nous voulions aussi pouvoir afficher l’état du trafic applicatif et voir en un coup d’œil l’état de celui-ci. Cela nous permettrait de savoir si une route serait accidentée afin de prendre la meilleure décision.

Cet outil de gestion de micro-services devait être aussi complet que possible pour les développeurs et les administrateurs afin de pouvoir réagir en cas de problème et à contrario informative et facile pour les utilisateurs fonctionnels qui souhaitent juste savoir si les applications se portent bien.

Problématique

Comment centraliser l’état de nos micro-services et les lier aux feature fonctionnelles correspondantes ? Comment suivre et agir sur la réaction en chaine provoqué par un micro service défectueux ?

Le battement d’ailes d’un papillon au Brésil peut-il provoquer une tornade au Texas ?

Recherche d’une solution adaptée

Etant très attentif à la sécurité, il nous fallait une application sécurisée par authentification. Nous voulions aussi prendre le moins de temps possible avec un maximum de résultats. Ne pas réinventer la roue.

Nous avions identifié lors d’une conférence un outil open source qui répondait à la plupart de nos besoins: le projet open source Izanami de la Maif.

Celui-ci proposait nativement des fonctionnalités tels que :

• Gestion des features (Création / Activation / désactivation)
• Interface web
• Api de gestion des features

Cependant malgré ses nombreux atouts, cet outil ne disposait pas de fonctionnalités dont nous avions besoins tels que la visibilité des features en lecture seule, les features inter-connectées, un graph de dépendances des features…

Il nous fallait aussi rendre le produit hautement disponible à moindre coût. Répondre aux nombreuses requêtes provenant de nos applications à forte audience telle que LaCentrale peut vite devenir complexe et très couteux.

Naissance du projet Feature-Flipping

Maintenant que le produit et les pré-requis étaient déterminés, il fallait rendre cet outil compatible avec les besoins internes, c’est-à-dire :

• Hautement disponible
• Authentification avec le SSO de la société
• Avoir un périmètre d’accès par équipe
• Accessible uniquement sur le réseau interne
• Proposer un monitoring des features en lecture seule
• Proposer un système de notifications
• Permettre de lier les fonctionnalités entre elles

Nous avons pour cela créer le projet Github Feature-Flipping.

Préparation de l’architecture réseau

Nous avons d’abord définit une infrastructure autour de l’application d’Izanami.
Le projet Izanami allait servir de référentiel. Nous avons construit une image AMI avec Packer et Ansible dans laquelle nous avons intégré le binaire Scala officiel de LaMaif mis à disposition sur Bintray.

Nous avons ensuite déployé l’infrastructure sur une stack avec le service d’Infra As Code CloudFormation d’AWS contenant le serveur EC2 (monté avec l’image précédemment crée) et un load balancer ALB. Celui-ci allait nous permettre d’ajouter le certificat ssl, de gérer les pic réseaux, mais également gérer le routing de la couche applicative

Afin de garantir d’une part la persistence des données même en cas d’instance défectueuse, et d’autre part pourvoir exploiter les données depuis d’autres applications, nous avons externaliser la base de données (par default inMemory sur la machine) vers le service NoSQL DynamoDB d’AWS. Le connecteur n’étant pas disponible par défaut, nous avons alors contribué au projet de la MAIF qui a accepté notre PR :).
Nous avons déployé de la même façon une stack CloudFormation contenant la table dynamo feature-flipping.

Séparation des responsabilités

Pour améliorer et simplifier la haute disponibilité du projet, nous avons séparé la responsabilité d’écriture et de lecture. La tache d’écriture des features serai de la responsabilité d’Izanami de part sa conception et ses fonctionnalités natives pointues.
En ce qui concerne la lecture, nous avons développé un service REST SERVERLESS (AWS Lambda) en NodeJS qui se chargerai de lire les données directement depuis la base de données Dynamo.

La séparation est transparente pour l’utilisateur grâce au routing applicatif par url que nous avons configuré sur notre ALB

Connexion SSO

De la même façon, nous avons configurer les routes de notre ALB pour rediriger les requêtes de connexion vers un micro service dédié à la connexion SSO.
Celui-ci développé en NodeJS, se charge de vérifier les accès de l’utilisateur et génère un token JWT à l’aide d’un secret partagé avec Izanami dans un coffre fort sécurisé AWS Secret Manager.

Service de notifications

Izanami propose nativement un système de notifications par SSE ou Webhook. Celui-ci permet de faire un appel http personnalisé lors d’un évènement (type changement d’état). Malheureusement cette fonctionnalité ne pouvait pas notifier plusieurs applications simultanément à moins de créer autant de webhook que de dépendances. Et cela impliquait que la machine ait l’autorisation de contacter toutes les machines de notre réseau. Nous ne voulions pas prendre le risque de donner trop de responsabilité à une application.

Nous avons donc pris la décision de déporter cette partie sur un réseau de micro-services lambda afin de pouvoir gérer avec granularité les autorisations avec IAM.

Le micro-service REST que nous avons mis en place permet de référencer l’état des fonctionnalités par appel HTTP. Cela signifie que c’est à l’application de vérifier l’état de sa feature sur le serveur avant de s’exécuter. Or nous avons trouvé interessant de pouvoir notifier directement les applications lors d’un changement d’état.

Nous avons pour cela ajouté à notre DynamoDb un flux de commande AWS Dynamo Stream lui même connecté à un service de notifications AWS SNS.
Celui ci permet de notifier les applications abonnées dès qu’une modification sur la table des features est modifié.
Cela nous a permis d’ajouter un service de notifications Slack mais également d’ajouter un service de dépendances de features.

Features dépendantes connectées

Izanami ne propose pas nativement de lier les features entre elles.
Pour le proposer, nous avons d’abord créer un service exploitant un dictionnaire json.
Celui ci décrit des features parentes fonctionnelle à l’aide du pattern « MASTER: » et les features dépendantes technique avec le pattern « CHILD: ».

{
 "MASTER:TEAM_1:FEATURE_FONCTIONNELLE": [
    "CHILD:TEAM_1:APP_1:FEAT_TECHNIQUE",
    "CHILD:TEAM_2:APP_XYZ:FEAT_TECHNIQUE_ABC"
 ],
"MASTER:TEAM_2:FEATURE_FONCTIONNELLE": [
    "CHILD:TEAM_1:APP_1:FEAT_TECHNIQUE",
    "CHILD:TEAM_2:APP_XYZ:FEAT_TECHNIQUE_ABC"
 ]
}

Lorsqu’une feature master est modifiée, le service est déclenché et vérifie les features child liées et les active / désactive par appel api à notre serveur Izanami.

Monitorer l’état des services inter-connectés

Pour afficher l’état des features disponible, il fallait se connecter sur Izanami et avoir au préalable les droits suffisants. Ainsi seul les administrateurs et les équipes propriétaires des features avaient la visibilité sur les services actifs. Il était donc impossible de les visualiser simplement hormis en passant par notre service REST http pas très user-friendly…

Pour proposer la visualisation, nous avons donc crées un graph via D3.js. Ce graph visualisable par toute personne sur le réseau du groupe apporte une visualisation interactive des features parentes, de leur dépendance et de leur état. C’est la fameuse carte interactive.

* Izanami à sorti depuis peu une fonctionnalité de gestion CRUD des utilisateurs ! Cela nous aurai permis d’avoir un espace de visualisation en lecture seule ouvert à tous directement depuis l’outil. Cependant, même avec cela, nous aurions tout de même eu besoin de développer une interface des dépendances inter-features.

Conclusion

L’utilisation de la solution Open Source Izanami lié à des micro-services personnalisés nous a permis de proposer un outil interne complet pour référencer les liens entre les applications sans avoir besoin de connaitre le code et ses aboutissants.

L’api et l’interface d’Izanami permettent aux équipes de prévenir lorsqu’une de leurs fonctionnalités est défectueuse. Cela permet de se « protéger » de l’effet papillon.

Celui-ci ne peux pas être interrompu à chaque fois car certains de nos services partenaires sont indispensables pour assurer le bon fonctionnement de nos applications (imaginez une seule route pour arriver à destination) mais l’outil donne un moyen de signalement centralisé efficace pour agir.
Nous pouvons ainsi prendre les meilleurs précautions le temps de certaines tempêtes 😉

J’espère que vous avez apprécié cet article. Et vous, comment gérez-vous vos micro-services ? Avez vous des outils / mode de fonctionnement privilégiés ?

Nous remercions chaudement la MAIF pour leur superbe solution et leur interactions sur GitHub toujours très actives.

A très bientôt.