Une migration vers le Cloud ne s’improvise pas. Dans la première partie, nous avons vu qu’elle nécessite une réévaluation des assets techniques de l’entreprise. Cette deuxième partie se focalise sur les transformations organisationnelles nécessaires pour bénéficier pleinement des avantages du Cloud.

Le Cloud a l’avantage de mettre à disposition des ressources à la demande avec un modèle de tarification à l’usage (pay-as-you-go). La promesse est de faire payer uniquement les services individuels dont vous avez besoin. Il n’est plus nécessaire de faire du sur-provisionnement. Le désavantage de ce modèle est la variabilité des coûts. Sans surveillance, les factures peuvent vite s’envoler. C’est d’ailleurs de ce constat qu’est née la démarche FinOps, dont l’objectif est d’allier performance technique et discipline financière.

D'expérience, toute entreprise migrant dans le Cloud se retrouve au moins une fois face à une facture salée. Les exemples vont d’une mauvaise configuration passée inaperçue à une fonction appelée par une boucle infinie. Pour se prémunir de ce risque, deux principes fondamentaux doivent être adoptés. Les omettre c’est prendre le risque de voir votre migration vers le Cloud virer au cauchemar.

Le premier principe est de surveiller les ressources déployées. Pour être au courant de toute anomalie, il est nécessaire de mettre en place de l’observabilité et des alertes pour l’infrastructure et les applications.

Le deuxième principe est l’autonomie des équipes produits. Dans le Cloud, il n'est pas possible de se contenter de mise à jour trimestrielle. Les services Cloud évoluent quotidiennement et imposent des changements à leurs utilisateurs. Sans réactivité de la part des équipes produits, les incidents de production ou de sécurité peuvent devenir des risques majeurs. Une ressource Cloud dépréciée peut également voir son coût exploser puis être tout bonnement retirée du catalogue. Le meilleur moyen pour se prémunir de ces risques est de miser sur des équipes autonomes. C'est-à-dire des équipes pluridisciplinaires (Développeurs, Product Owner, Opérateurs, …), responsables à la fois du produit qu’elles développent et de l’impact de leurs choix sur les coûts. C’est le cœur de l’approche agile, DevOps, DevSecOps, FinOps… et toutes les variantes qui prônent la collaboration plutôt que la ségrégation de responsabilités.

Une équipe, de la demande à la production

Traditionnellement, les équipes d’une division informatique étaient organisées par fonctions: des équipes qui construisent (équipes projets) et d'autres qui opèrent (équipes de production). Les équipes projets sont responsables d’un ou plusieurs produits mais dépendent des équipes de production pour toute évolution. Elles ne décident pas des façons d’opérer leurs applications ni même parfois le socle sur lequel elles doivent s’appuyer. À contrario, les équipes de production ne décident pas du contenu de l’application.

Cette division organisationnelle crée des problèmes d’alignement d’objectifs et de vélocité. L’objectif premier des équipes produits est de faire évoluer leurs produits mais la stabilité de ces derniers ne leur incombe pas. Pour les équipes de production c’est l’inverse ce qui rend la collaboration difficile. L’approche “DevOps” change ce paradigme en assignant une équipe à un produit. Chaque équipe est responsable d’un produit de bout en bout (développement et run). Une mise en production ne nécessite pas l’intervention d’une personne extérieure à l’équipe. Elle est autonome.

Cette autonomie permet aux équipes produits de monitorer et modifier leur infrastructure en adéquation avec leurs besoins. Rendre responsable ces mêmes équipes passe aussi par la mise en place de piquets, mettre en place des SLIs, SLAs et SLOs, pour assurer une continuité de leurs services dans le cadre d’un budget.

Ces équipes sont idéalement composées d'une dizaine de personnes au maximum. Au-delà, la coordination se complique, la communication se dilue et la cohésion s’affaiblit, ce qui finit par ralentir la prise de décision et la livraison de valeur.

Les équipes production ne disparaissent pas mais leur ressources sont intégrées aux équipes produits ou se transforment en équipe plateforme (teamtopologies), qui à la façon d’un cloud permet aux équipes produits de piocher dans les offres de services qui auront été rendues disponibles par ces plateformes.

Autonomie et vélocité

Une équipe autonome, c’est une équipe capable de faire évoluer son produit avec le minimum de friction avec le reste de l’organisation. Son autonomie lui permet de s’adapter en continu aux retours et aux besoins des clients afin de leur apporter un maximum de valeur. Elle choisit quelle fonctionnalité développer en priorité et quand la déployer. La flexibilité sur ses choix d’infrastructure et de ses coûts (dans un budget cadré) lui permet de tester rapidement de nouvelles fonctionnalités, de les valider et en cas de succès de les pérenniser.

Prenons un exemple concret. Un de nos clients, avec qui nous avons mis en place ce modèle opérationnel, souhaitait utiliser un modèle d’IA pour un besoin métier de classification de données.

Dans sa réflexion, l'équipe a cherché à trouver une solution optimisant les aspects suivants:

• la capacité à tester rapidement la solution avec des clients
• la facilité de maintenance
• le coût

Une solution à été trouvée en quelques jours et en quelques semaines les premiers retours clients ont permis de valider l’approche.

Le passage à l'échelle demandera sans doute un plus gros budget et donc de rentrer dans des processus plus longs de validation mais le business case sera plus facile à construire (nb d’usage, nb de prospects intéressés,...) puisque les clients utilisent déjà la solution.

Vers un nouveau mode de gouvernance

source: wikipedia

L'approche DevOps pousse également à repenser les processus de contrôle ainsi que les rôles de gouvernance. Avoir des équipes autonomes va à l’encontre de l’idée de gates externes de contrôle.

Dans les faits, passer par des gates pour valider les demandes projets de ressources ne fait souvent que donner une illusion de contrôle. Refuser la demande de nouvelles ressources est difficile sans compter les deadlines qui ajoutent une pression non négligeable. Être en capacité de valider une demande requiert également des connaissances fines des besoins. Dans le cas où le contrôleur externe n’est pas en capacité de les avoir, les validations arbitraires arrivent très vite. De l’arbitraire né la frustration. De la frustration, l’envie de contourner les règles voire de ne plus innover. C’est une situation loose/loose.

Il est important de noter qu’avoir des équipes autonomes ne signifie pas l’absence de contrôle centralisé. Pour s’assurer qu’il n’y ait pas de dépassements de budgets par les équipes, il est essentiel d’avoir des systèmes de surveillance communs ainsi que des remédiations automatiques. La clé pour réagir rapidement aux comportements hors normes est l’automatisation. Elle a aussi l'avantage de dissuader de contourner les règles d’entreprise.

Un exemple caricatural: on n'essaiera pas de négocier contre une fonction qui détruit toute machine virtuelle qui n’est pas rattachée à une équipe produit (par le mécanisme de tag). On respectera la règle quand on créera la VM.

Pour conclure

L’autonomie et donc la responsabilité des équipes produits sont primordiales dans la gestion des coûts d’infrastructures dans le cloud.

Nous considérons que la manière la plus efficace de faire du FinOps est d’avoir des équipes pluridisciplinaires et autonomes. Il s’agit donc de donner en partie la responsabilité financière et opérationnelle aux équipes qui gèrent les applications, afin qu’elles puissent mesurer, comprendre et optimiser elles-mêmes leurs coûts.

Concrètement, cela signifie que les équipes doivent pouvoir visualiser les coûts liés à leurs assets, surveiller les dépassements grâce à des alertes et ajuster les paramètres des ressources qu’utilisent leurs applications. Cela inclut, par exemple, la taille des machines virtuelles, la topologie de stockage ou le niveau de service des offres SaaS.

Nous considérons que les rôles de gouvernance ont tout intérêt à évoluer d’une logique de validation vers une logique d’accompagnement. Leur mission n’est plus de freiner ou de bloquer, mais de conseiller, guider et évangéliser les bonnes pratiques (10 Ways to work WITH Developers to take action with FinOps). Le but est de permettre une plus grande vélocité des équipes tout en gardant une gestion des coûts maîtrisée.

Malgré le fait que nous reconnaissons le besoin de contrôler le travail des équipes, nous considérons avant tout qu’elles doivent être autonomes et responsables dans leurs décisions.