Comment gaspiller 5 millions de dollars en infrastructures conteneurisées

« Nous avons créé un cluster Mesos de 70 000 nœuds pour nos développeurs, mais ils ne veulent pas l'utiliser. Pouvez-vous m'aider ? » C'était le début d'une conversation avec le vice-président des opérations d'infrastructure d'une très grande et célèbre entreprise. Bien que ce soit un exploit impressionnant, il s'agit également de loin de la plus grande infrastructure conteneurisée que j'ai vue qui soit restée inutilisée. Malheureusement, il ne s'agissait

J'ai parlé de cette rencontre avec un grand nombre de clients, d'analystes, d'amis, de collègues, de partenaires, de sociétés de capital-risque et de concurrents. Nous avons tous vécu des expériences similaires et nous voulions tous savoir pourquoi il en est ainsi. Après tout, si tant de ressources sont gaspillées dans notre secteur, nous prenons tous de grands risques en ne comprenant pas le problème et en ne le résolvant pas. Sinon, la prochaine vague d'utilisateurs pourrait commencer à douter que les conteneurs puissent aider leur entreprise, et nous devrions tous commencer à peaufiner notre CV

Pour être honnête, je suis développeuse, ingénieure et technologue. J'adore créer des produits en utilisant les dernières technologies. Alors, pour trouver la réponse à cette question sur les 70 000 nœuds, j'ai d'abord cherché les technologies utilisées. La technologie Mesos n'était-elle pas la bonne ? Cela a-t-il été mal mis en œuvre ? Ont-ils utilisé un code source ouvert ou un code source fermé ? Y a-t-il eu un SI impliqué ? De telles questions me sont venues en premier à l'esprit. Avec le recul, je pense que ce n'étaient probablement pas les bonnes questions

La réponse m'est venue quand je me suis souvenue d'un jour de ma carrière il y a 15 ans : assise à mon bureau en tant que développeur dans une grande banque, je me souviens que des vendeurs impeccablement habillés entraient et sortaient de nos salles de réunion pour courtiser notre vice-président des infrastructures et son équipe. Ils venaient de VMware, la société spécialisée dans les infrastructures virtualisées à l'époque. J'étais juste développeuse à la banque, mais ni mon patron, ni même le patron de son patron, n'étaient invités aux dîners organisés par VMware presque chaque semaine dans un steakhouse. Les vendeurs de VMware ne s'intéressaient qu'aux décideurs en matière d'opérations et d'infrastructures. Deux ou trois mois plus tard, notre équipe a été informée qu'un accord avec VMware avait été signé et que nous allions bientôt transférer nos services aux machines virtuelles, et peu de temps après, ce déménagement a eu lieu quelques week-ends

Puis, un lundi matin, les services dont mon équipe était responsable fonctionnaient sur des machines virtuelles au lieu d'utiliser des vieux serveurs entièrement équipés de lumières bleues clignotantes et de ventilateurs bruyants. C'est tout. L'ensemble de notre infrastructure a été virtualisée en quelques mois sans que les développeurs aient leur mot à dire, et alors que nous faisions semblant de résister à ce changement (et qui aime le changement après tout ?) et en acceptant à contrecœur de rester en veille pendant quelques week-ends, nous n'arrivions pas vraiment à faire la différence entre l'ancienne et la nouvelle configuration : tout était pareil. Nos serveurs de machines virtuelles se comportaient et semblaient être de « vrais » serveurs. Je suis sûre que nous n'aurions pas été en mesure de faire la différence dans un test en double aveugle si quelqu'un en avait effectué un

remémorant cette époque, je me suis demandé pourquoi la nouvelle vague de changements d'infrastructure conteneurisés ne fonctionne pas de la même manière. Pourquoi ne pas créer un cluster Mesos ou Kubernetes en un week-end ou deux et envoyer un mémo aux développeurs avec pour objet : « Bienvenue dans le futur de l'infrastructure ? De rien ! » ?

La réponse, comme nous le savons tous, est que la conteneurisation ne fonctionnera pas sans l'implication et l'achat des développeurs. Les développeurs doivent créer des applications pour une configuration conteneurisée, mais les conteneurs, avec des API comme Kubernetes exposées tout au long du cycle de vie des logiciels, obligent les développeurs et les opérateurs à modifier leur façon de travailler et de communiquer entre eux. Si un cluster brillant de 70 000 nœuds exécute Tumbleweed au lieu d'applications métiers, c'est parce que les outils que nous avons créés pour cette nouvelle transition ne répondent pas à ce changement organisationnel fondamental et essentiel, à savoir le maillage entre les développeurs et les opérations. La réalité passionnante, c'est que la mise en place d'une infrastructure conteneurisée est de plus en plus facile, car il existe de nombreuses solutions open source qui vous permettent de fonctionner avec un cluster Kubernetes. Si vous utilisez déjà l'un des principaux fournisseurs de cloud, il vous suffit de quelques clics pour avoir votre propre cluster conteneurisé, géré et facturé à la minute. Les avantages de la gestion d'une infrastructure conteneurisée sont visibles pour les équipes opérationnelles : serveurs à configuration unique (plus de « flocons de neige »), haute disponibilité et résilience intégrées, et meilleure utilisation des ressources, pour n'en citer que quelques-uns. Les développeurs voient également l'intérêt de fonctionner dans une configuration conteneurisée : une plus grande influence sur l'environnement d'exécution, un meilleur contrôle des bibliothèques et des dépendances, et une réduction de l'écart entre les environnements de production et de développement, en sont quelques-unes. Chaque partie de cette équation (développeurs et opérations) a ses propres fournisseurs, outils et projets open source pour les aider à passer à un monde conteneurisé, mais cela ne suffit pas. Nous n'avons toujours pas le cadre permettant aux développeurs et aux équipes opérationnelles de travailler ensemble pour en faire un succès. Il existe tout simplement très peu d'outils et de technologies, voire aucun, qui facilitent cette communication.

Nous sommes tous tellement concentrés sur nos domaines d'innovation individuels, du réseau au stockage et à l'orchestration, que nous pouvons perdre de vue la réalisation de leurs objectifs commerciaux par nos clients. Dans un tel environnement, les intégrateurs de systèmes, les sociétés de conseil et de services professionnels s'en sortent bien, car elles sont les seules à se concentrer sur le résultat et la fourniture tout au long de la chaîne d'approvisionnement logicielle ; mais ce n'est pas durable. Les technologies qui obligent les clients à payer autant à des sociétés de conseil pour les faire fonctionner ne seront pas des technologies révolutionnaires. Regardons les choses en face : si la virtualisation nécessitait la présence permanente de McKinsey sur les listes de paie pour fonctionner, il n'y aurait pas

Pour que nous puissions tous bénéficier d'une technologie révolutionnaire telle que la conteneurisation des infrastructures, nous devons adopter une approche plus large que nos outils à usage unique ou nos principaux domaines d'intervention et repenser la façon dont nous créons des produits pour ce secteur. C'est différent de la révolution de la virtualisation et du cloud, et plus vite nous nous en rendrons compte, meilleurs seront les avantages pour nos clients

Devops n'est pas simplement un ensemble d'outils fragmentés ou un projet de « transformation numérique » sophistiqué, c'est une méthode qui permet de travailler en collaboration entre les fonctions, grâce à la technologie. Par conséquent, toute technologie destinée au marché DevOps, en particulier en matière de conteneurisation, doit avant tout intégrer un état d'esprit de collaboration continue. Alors, créons tous des produits dans cette optique afin d'entamer et de poursuivre une conversation entre les développeurs et les opérateurs.

Ce billet a été publié pour la première fois ici