Comment Slack a cadré le cycle de vie de ses projets infra
Publié par Clément Bohic le - mis à jour à
Voilà quatre ans, Slack adoptait un framework de cycle de vie et l’appliquait à un de ses projets d’infra. Comment se structure-t-il ?
Comment favoriser le décommissionnement de technologies ? En adoptant un framework de cycle de vie. Slack s’était en tout cas engagé sur cette voie voilà près de quatre ans, dans le cadre de l’évolution d’une plate-forme interne de compute.
Cette plate-forme se fondait alors sur un ensemble de modules Terraform et de recettes Chef, assorties d’un format de paquet maison. Aujourd’hui, elle repose sur Kubernetes et exploite des fichiers YAML. Elle a connu une itération intermédiaire.
Slack y a donc appliqué un framework de cycle de vie. Celui-ci lui a servi à la fois d’outil de communication et de planification. Il s’agissait notamment de pouvoir expliquer clairement aux utilisateurs ce qu’ils pouvaient attendre d’une techno spécifique : quel support ? quelle roadmap ? quel traitement pour les signalement de bugs et les demandes de fonctionnalités ?…
Le framework ne présente pas d’approche novatrice en matière de terminologie, ni de structuration. Il comporte six stades par lesquelles passent la plupart des technologies.
Alpha
Stade expérimental. Pré-prototypes dont la « v2 » pourrait éventuellement être la bêta. Usage global fortement découragé. Aucun support. Évolution possible vers les stades Bêta ou Décommissionné.
Bêta
Prototypes ont l’usage en production est fortement découragé. Ou alors de manière limitée, en consultation avec l’équipe qui les développe. Support uniquement pour obtenir des retours d’utilisateurs. Documentation éparse, voire inexistante (meilleure source d’information : probablement… les discussions Slack). Priorité basse pour toutes les demandes hors celle relevant de la sécurité et de la conformité. Évolution probable vers le stade Actif, mais passage direct en Maintenance envisageable – ou plus rarement en Obsolète.
Actif
Technologies de niveau prod. Ressources de support réservées pour traiter signalements de bugs et demandes de fonctionnalités. Priorisation selon des procédures normales. La plupart des technologies au stade Actif bénéficient aussi de ressources d’assistance dédiée. Évolution probable vers le stade Maintenance – plus rarement, vers le stade Obsolète.
Maintenance
Technologies anciennes dont le successeur est généralement en fin de bêta ou au début du stade Actif. Disponibles en prod. Nouveaux usages découragés, mais pas interdits. Ressources dédiées au traitement des bugs, pas des demandes de fonctionnalités. Priorisation normale. Généralement pas d’assistance dédiée. Pour le cloud, possibilité de limiter le support aux heures de bureau. Évolution possible vers le stade Obsolète ou retour en Actif.
Obsolète
Technologies pour lesquelles il existe une alternative fonctionnellement complète au stade Actif. Leur date d’obsolescence est souvent fixée (Slack donne l’exemple des versions d’Ubuntu). Nouveaux usages interdits. Support minimal. Documentation possiblement pas à jour ou incomplète. Rapports de bugs classés en priorité basse. Pas de garantie de traitement des demandes de fonctionnalités. Une fois au stade Obsolète, il s’écoule au moins deux trimestres complets avant décommissionnement.
Décommissionné
Aucun support. Peut fonctionner, mais aucune garantie. À ne pas utiliser.
2017-2022 : une plate-forme, trois incarnations
En février 2017, Slack avait mis en service la première itération de sa plate-forme interne de compute. Elle s’appelait alors BuiltBySlack (BBS).
En mai 2018 avaient démarré les travaux sur le socle Kubernetes. Il en a résulté Bedrock. La première itération, désormais dénommée Bedrock Classic, avait posé l’essentiel des bases aujourd’hui encore exploitées, mais les owners avaient à leur charge un certain nombre d’aspects du processus de conception et de déploiement des conteneurs. Aussi bien écrire les scripts de build que pousser les images vers des registres et créer les ressources Kubernetes pour l’exécution.
En mars 2020, Slack introduisit son framework de cycle de vie. Bedrock Classic est alors au stade Actif. Son successeur envisagé (Bedrock YAML), en bêta. BBS, en maintenance. Ce dernier passa en Obsolète en juillet 2020, après accord en interne sur la parité fonctionnelle de Bedrock.
En avril 2021, Bedrock YAML passa au stade Actif. En juillet de la même année, BBS fut déclaré obsolète, tous ses utilisateurs ayant migré vers Bedrock. Puis en juillet 2022, après des mois à maintenir une parité fonctionnelle entre les deux incarnations de Bedrock, la « Classic » devient à son tour obsolète.
À consulter en complément :
Comment Slack a développé son usage de Terraform
Comment Slack a modernisé le suivi de sa flotte AWS EC2
Pourquoi Slack est passé à l’architecture cellulaire
Illustration © Slack