5 ingrédients clés pour réussir son aventure cloud

Imaginez une équipe de développement de 5 à 10 personnes qui :

• Livre régulièrement de nouvelles fonctionnalités, dans les délais
• Détecte les interruptions de service avant ses clients
• Corrige les bugs rapidement — par corrigés, j'entends en production, pas seulement sur la branche main de votre git
• Garde de la marge pour explorer et expérimenter de nouvelles technologies

Et qui parvient à tenir ce rythme pendant des années sans s'essouffler !

Trop beau pour être vrai ? Voyons cela. Voici comment je démarrerais aujourd'hui un nouveau projet. Un projet cloud, sur GCP en l'occurrence.

La sécurité est trop souvent négligée. Les développeurs la jugent ardue et l'étudient juste assez pour franchir les paramètres par défaut du cloud et commencer à construire. Après tout, les clients n'achètent pas de la sécurité — ils achètent des fonctionnalités ; à leurs yeux, la sécurité du produit va de soi.

Hélas, cette approche mène vite à de mauvaises habitudes — des clés de sécurité publiées sur un git public, ça vous parle ? :)

Points clés :

• Maintenez un socle de sécurité au sein de l'équipe, en lien avec les technologies utilisées. Si vous démarrez sur un nouveau cloud, par exemple, assurez-vous que tout le monde (et pas seulement les DevOps) en maîtrise les bases. Sur GCP, par exemple, un développeur moyen peut se familiariser avec le modèle de sécurité en quelques heures.
• Désignez un référent capable de transmettre les bonnes pratiques de sécurité. Si personne dans l'équipe ne tient ce rôle, Google, dans notre exemple, dispose de partenaires dont c'est précisément le métier : ils servent de caisse de résonance sur le sujet.

Souvenez-vous du modèle de responsabilité partagée des clouds : ils fournissent des briques sécurisées, mais c'est à vous de les assembler de manière sûre.

Une fois vos fondations de sécurité bien comprises, vous pouvez passer à l'architecture.

Nous rêvons tous de voir notre entreprise devenir le prochain Twitter, Uber ou Google. Mais aucune de ces sociétés n'est née à l'échelle mondiale.

Le défi consiste à démarrer petit tout en gardant de la place pour grandir. Pour y parvenir, je recommande de constituer une petite cellule au sein de l'équipe, chargée de veiller à ce que celle-ci ne sombre pas dans une pensée purement tactique — un travers naturel dès qu'on enchaîne les fonctionnalités à la chaîne. Cette cellule s'assurera que les bons arbitrages sont faits. Quelques exemples :

• J'ai un jour développé un gestionnaire de batchs pour une base ElasticSearch. L'implémenter en mode actif/actif et scale-out aurait demandé dix fois plus d'efforts ; en revanche, une version singleton pouvait absorber une montée en charge x100, et il était acceptable qu'elle soit indisponible 10 à 15 minutes en cas de bug ou de maintenance.

Dans ce cas, nous avons sciemment choisi un composant à point de défaillance unique parce que c'était suffisant au regard de nos besoins métier.

• Stratégiquement, vous voudrez peut-être bâtir un produit cloud-agnostique. Choisir Kubernetes (K8s) comme plateforme applicative couvre déjà environ 80 % du chemin. Reste que vous devrez vous interfacer avec des services hors K8s de votre fournisseur cloud — Load Balancers, files de messages, etc. ; et il appartiendra à votre cellule architecture de s'assurer qu'aucun service propriétaire n'est retenu dans la précipitation d'une deadline. Et lorsque cela arrive, ce doit être un choix conscient et bien documenté.

Vos tech leads les plus expérimentés endosseront naturellement ce rôle, mais mieux vaut le formaliser et veiller à ce que leur voix porte. Quand un post-mortem démarre par je vous avais dit il y a six mois que ça allait casser, c'est le signe que votre cellule architecture a besoin d'ajustements. Le maître mot : faire confiance aux équipes.

Pour que cette cellule fonctionne et que toute l'équipe en bénéficie, il est essentiel que les Product Owners et le management aient confiance dans les bonnes intentions des développeurs. Des développeurs responsabilisés cèdent assez facilement à la pression des fonctionnalités, ce qui dégénère vite en mode je vous l'avais bien dit….

Ce qui suit peut paraître un brin radical, mais j'espère avoir capté votre attention. Le piège classique, c'est les fonctionnalités d'abord, les tests après. Sous la pression des deadlines, les tests sont en général les premiers sacrifiés.

Permettez-moi un témoignage personnel. J'ai travaillé sur un projet doté d'une excellente architecture, à un détail près : nous n'avions consacré aucun temps à la manière dont nous testerions notre produit. Au 5ᵉ sprint scrum, nous avons réalisé que nous passions systématiquement 2 à 3 jours avant la revue de sprint dans une véritable frénésie d'intégration, et que la situation empirait de sprint en sprint. Notre seconde erreur a été de ne pas savoir sortir de la course aux fonctionnalités pour communiquer clairement au product management qu'il fallait revenir à la planche à dessin et réajuster la conception côté CI (cf. la confiance aux équipes évoquée plus haut). Un an plus tard, nous nous retrouvions avec un CI rajouté à la va-vite, qui cassait plus souvent qu'il ne fonctionnait, et qui était une source constante de frustration pour les développeurs. Cette grosse boule de boue a fini par devenir si volumineuse que, même avec carte blanche pour la corriger, l'équipe ne parvenait pas à se mettre d'accord sur la meilleure façon de la rearchitecturer.

Deux choses se produisent quand on intègre CI et CD au cœur même de l'architecture :

• Vous commencez à vous demander comment vous savez que le système fonctionne. Cela vous conduit naturellement à instrumenter votre code pour collecter des métriques opérationnelles.
• Quand vous déboguerez les échecs nocturnes du CI, vous développerez à la fois les compétences et les outils (logs corrects, collecte de traces, etc.) nécessaires pour analyser et corriger des problèmes déjà survenus. Ce sont précisément les compétences et techniques dont votre équipe aura besoin pour déboguer les pannes en production.

Effet de bord appréciable : vous disposerez de systèmes de logs et de monitoring avant même la mise en production. Un avertissement à propos des frameworks de monitoring et de logging : leur coût d'exploitation, qu'il s'agisse de SaaS ou d'une solution maison, peut grimper très vite — je recommande vivement d'estimer ces coûts potentiels et de les intégrer à votre décision.

Une fois votre pratique CI à un niveau qui vous satisfait, vous pourrez occasionnellement vous permettre le fonctionnalités d'abord, tests après. Et par après, j'entends au sprint suivant, sauf s'il s'agit d'une fonctionnalité jetable, ponctuelle, de démo, que vous désactiverez via des feature flags.

Chaque cloud propose ses propres services natifs de monitoring et de logging, qui peuvent ou non vous convenir. Avec K8s, la partie CD est largement balisée ; en revanche, la partie CI demandera une bonne phase de recherche de votre côté. Les trois grands hyperscalers fournissent bien des outils CI, mais soyons honnête : ce n'est pas leur cœur de métier.

Le principe You build it — you run it est une évidence dans les petites entreprises : il n'y a tout simplement pas d'équipe SRE par-dessus laquelle balancer le code. La question n'est donc pas qui est responsable de la production, mais plutôt quelle expérience cela représente d'assumer un workload en production.

L'avantage, c'est que si vous avez soigné les étapes précédentes, l'ownership de la production deviendra très naturel pour votre équipe. Voyons pourquoi :

• Vous avez commencé par la sécurité : vous disposez donc déjà d'une séparation des périmètres. Vous savez où chercher en cas de problème ; les situations où du code de développement se connecte par erreur à la base de production et fait des ravages sont tout simplement écartées.
• Votre architecture est réaliste et adaptée à votre équipe. Elle est claire et facile à comprendre. Par exemple, vous ne maintenez pas de systèmes distribués complexes sans nécessité, et lorsque vous le faites, vous êtes en mesure de les maîtriser. Armé de vos outils d'observabilité, vous identifiez rapidement la source des problèmes.
• Votre CI est stable et fiable, et votre CD est fluide. Du coup, lorsqu'il faut corriger un bug, les processus de test et de déploiement sont rapides, simples, sans charge cognitive ni montée d'adrénaline. Cela limite la corvée liée aux bugs et évite la dérive vers une maintenance permanente.

Vos applications intègrent déjà l'observabilité ; il ne vous reste qu'à configurer les dashboards de monitoring et à mettre en place les alertes.

Un aspect moins évident de l'ownership de la production, en particulier pour les développeurs, c'est le coût d'exploitation du produit. Je suis convaincu que les développeurs devraient connaître les modèles de facturation cloud et savoir combien leur logiciel consomme, pour les raisons suivantes :

Éviter les mauvaises surprises sur la facture

Vous devez comprendre le modèle de facturation du cloud pour bien concevoir votre système (bill shock, ça vous parle ?) — qu'il s'agisse de l'architecture applicative ou de l'architecture CI/CD. Pour boucler la boucle, mettez en place des budgets et des alertes de facturation.

Connaissez votre coût unitaire

Il est précieux pour les équipes produit et commerciales de connaître ce coût unitaire. Si, par exemple, votre produit supervise des appareils en edge, le coût unitaire correspond à la part de la facture cloud générée par chaque appareil supervisé. Cette donnée est très utile pour bâtir des modèles économiques et sortir le capacity planning du domaine du pifomètre.

Avec vos métriques applicatives en place, il est généralement aisé de relier la logique applicative aux coûts en analysant en profondeur vos données de facturation.

Nous adorons nos bits, nos octets et notre logique formelle, mais au bout du compte, nous restons une bande d'humains qui travaillent ensemble.

Si nous rejoignons des startups, c'est parce que nous croyons en quelque chose et que cela nous enthousiasme.

Managers, faites confiance aux bonnes intentions de vos développeurs. Challengez leurs idées, mais laissez-leur de l'espace pour innover. Soyez attentifs aux signes d'un repli défensif : à partir de là, chaque fonctionnalité devient subitement complexe à implémenter et le projet commence à stagner.

On peut parler de cloud et de technologie toute la journée, mais si le travail n'est pas plaisant, l'innovation ne durera pas.