De la Gamification au Platform Engineering : l'art de personnaliser pour répondre aux besoins

Les origines

En 2021, certains se souviennent peut-être que WeScale a lancé un coding game baptisé Abhra Shambala. Ce projet visait à engager les développeurs à travers des défis stimulants, favorisant ainsi l’apprentissage et la collaboration au sein de la communauté technologique. 

Forts du succès rencontré lors de cette première édition, nous avons décidé en 2023 de franchir une nouvelle étape pour la saison 2 en concevant une plateforme plus sophistiquée. Cette initiative avait pour ambition de créer un écosystème dynamique où chaque développeur pouvait non seulement participer, mais aussi contribuer activement en élaborant ses propres épreuves intégrées à l'univers du jeu. L'approche par les conteneurs permettait de standardiser les conditions de participation, garantissant une expérience homogène pour tous les participants (et la mise en pratique des compétences utiles à la résolution des puzzles).

Bien que le projet n’ait pas eu la portée envisagée, les discussions entre collègues et les enseignements tirés des premières tentatives ont constitué les prémisses de nos premières plateformes d’outillage internes.

Un champ de besoins = une plateforme

Confrontés à des besoins opérationnels internes, différents des usages dans des contextes hétérogènes de mission, nous avons finalement dû accepter l’idée qu’il n’y aurait pas de solution miracle (et ce n’est toujours pas le cas…). Nous avons atteint un stade où nos besoins se sont clarifiés autour de deux axes technologiques principaux :

• une plateforme dédiée à l'exécution d'applications cloud native avec un focus sur la facilitation du travail des développeurs. Les consommateurs de cette plateforme sont bien les équipes de développement qui doivent être autonomes sur un grand nombre de paramètres pour ne pas se retrouver limités dans leurs expérimentations.
• une plateforme permettant de gérer le cycle de vie de cette première plateforme et donc les différents environnements instanciés. On vise là un public plus orienté équipe d'infra, réseaux, sécurité, qui vont pouvoir instancier et faire évoluer la plateforme pour les développeurs.

Les contraintes que nous nous sommes fixées demeurent nos lignes directrices aujourd'hui :

• Utiliser des solutions Open Source ou, à défaut, dont la licence ne limite pas nos usages.
• Concevoir des plateformes agnostiques des fournisseurs de cloud.
• Conserver un couplage faible entre les composants de chacune des plateformes pour assurer extensibilité et modularité.

Nous avons beaucoup expérimenté. Les visions différentes des deux plateformes nous amènent parfois à déplacer des composants de l’une à l’autre, voire à dupliquer certaines capacités (ah, le casse-tête de l'authentification !).

OXP : Operational eXcellence Platform

L’équipe autour d’OXP est conséquente, et propose régulièrement de nouveaux produits à tester et intégrer. De plus, nos collègues construisent actuellement des plateformes pour leurs clients et nous amènent de nouveaux contextes, donc de nouveaux sujets de réflexion.

Nous nous réunissons régulièrement pour discuter de nos expérimentations, de nos lectures et de nos convictions. Il nous arrive de nous accorder, mais plus souvent, ce sont des désaccords qui engendrent des débats constructifs et donnent lieu à de nouvelles expérimentations.

La vie du produit "Plateforme" n'est pas un long fleuve tranquille.

À l’heure actuelle, voici l’implémentation que nous utilisons au quotidien. Nous aurons l’occasion de revenir sur ses différentes composantes.

OXP s’exécute sur un cluster K8S managé par Scaleway.

TOC : Tactical Operations Center

Une plateforme comme OXP nécessite de la surveillance, des mises à jour, bref : de la maintenance. Cette histoire ressemble à un conte mythologique grec classique : OXP a bien engendré sa mère. Les besoins récurrents de maintenance, ainsi que la nécessité de démarrer de nouvelles instances d’OXP dans différentes versions pour faire des expériences, ont conduit à l’idée de créer une plateforme ancêtre. Cette nouvelle plateforme aura un niveau de complexité technique moins élevé qu’OXP, pour réduire son Total Cost of Ownership (TCO) propre et ainsi maximiser l'effort sur les instances OXP.

Cette réflexion nous a amené à vouloir TOC comme une plateforme :

• basée sur des capacités fixes en systèmes, CPU et RAM. 
• privilégiant la fiabilité à la scalabilité
• favorisant une reconstruction rapide plutôt que la haute disponibilité.

Pensées partagées

Les réflexions et solutions posées ici sont liées à notre contexte opérationnel. Chaque organisation et chaque contexte technique trouveront des solutions adaptées à leurs besoins. Nous vous partageons ici les quelques convictions que nous avons retirées de nos sessions de conception, en espérant contribuer à inspirer les vôtres.

Convictions

Adopter une approche de Platform Engineering soulève plusieurs questions d’ordre philosophique…

• Il n’existe pas de chemin unique. L’expérimentation et le prototypage sont essentiels.
• Valorisez le droit à l’erreur et autorisez-vous à faire machine arrière.
• Nos deux plateformes internes :
  • TOC (Tactical Operations Center) : centrée sur l’infrastructure et la gestion du cycle de vie des ressources.
  • OXP (Operational eXcellence Platform) : dédiée à l’exécution des applications cloud-native, intégrant toutes les capacités nécessaires, du build au run.

Les principes directeurs

• Open Source : privilégier les solutions ouvertes et gratuites, ou à défaut des licences non contaminantes.
• Agnostique : rester indépendant des fournisseurs de cloud.
• Modulaire : construire des plateformes flexibles et extensibles, avec des fonctionnalités optionnelles.
• Couplage faible : garantir une intégration souple des composants.

Une fois ces principes posés, il est temps de démarrer l’implémentation. Et c’est souvent là que le bât blesse : par où démarrer cette construction ? Mais cela fera l’objet d'un prochain article !