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 l'utiliseront pas. Peux-tu 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 entreprise célèbre. Bien qu'il s'agisse d'un exploit impressionnant à accomplir, 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 fait part d'expériences similaires et nous voulions tous savoir pourquoi il en était ainsi. Après tout, si tant de ressources sont gaspillées dans notre industrie, nous prenons tous de grands risques en ne comprenant pas le problème et en ne le résolvant pas. Dans le cas contraire, la prochaine vague d'utilisateurs pourrait commencer à douter de la capacité des conteneurs à aider leur entreprise, et nous devrions tous commencer à peaufiner notre CV

Je dois être honnête : je suis un développeur, un ingénieur et un technologue qui adore créer des produits et utiliser les dernières technologies. Donc, dans ma quête pour trouver une réponse à cette question sur les 70 000 nœuds, j'ai d'abord cherché les technologies utilisées. Est-ce que Mesos n'était pas la bonne technologie ? A-t-il été mis en œuvre de la mauvaise façon ? Ont-ils utilisé un code source ouvert ou un code source fermé ? Y avait-il un SI impliqué ? Des questions comme celles-ci me sont d'abord venues à l'esprit. Avec le recul, je pense que ce n'étaient probablement pas les bonnes questions

La réponse m'est venue lorsque je me suis souvenu d'un jour de ma carrière il y a 15 ans : assis à 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, qui était à l'époque la société spécialisée dans les infrastructures virtualisées. Je n'étais qu'un développeur à la banque, mais ni mon patron, ni même le patron de son patron, n'étaient invités à aucun des dîners-steakhouse organisés presque chaque semaine par les employés de VMware. Les commerciaux 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 transfert a eu lieu quelques week-ends

Puis, un lundi matin, les services dont mon équipe était responsable fonctionnaient sur des machines virtuelles au lieu des anciens 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'avons pas vraiment pu faire la différence entre l'ancienne et la nouvelle configuration : tout était pareil. Nos serveurs de machines virtuelles se comportaient et ressemblaient à de « vrais » serveurs. Je suis sûr que nous n'aurions pas été en mesure de faire la différence dans un test en double aveugle si quelqu'un l'avait effectué

remémorant cette époque, je me suis demandé pourquoi la nouvelle vague de changements d'infrastructure conteneurisés ne fonctionnait 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 une note 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'adhésion des développeurs. Les développeurs doivent créer des applications pour une configuration conteneurisée, mais les conteneurs, avec des API telles que Kubernetes exposées tout au long du cycle de vie du logiciel, 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étier, c'est parce que les outils que nous avons conçus 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é est intéressante : la mise en place d'une infrastructure conteneurisée est de plus en plus facile, car il existe une multitude de solutions open source qui vous permettent d'être opérationnel avec un cluster Kubernetes. Si vous utilisez déjà l'un des principaux fournisseurs de cloud, il vous suffit de quelques clics pour disposer de votre propre cluster conteneurisé, géré, entretenu et facturé à la minute. Les avantages liés à 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 utilisation améliorée 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) dispose de ses propres fournisseurs, outils et projets open source pour les aider à faire le nécessaire pour passer à un monde conteneurisé, mais cela ne suffit pas. Nous ne disposons toujours pas du cadre permettant aux développeurs et aux opérateurs de travailler ensemble pour en faire un succès. Il existe tout simplement très peu, voire aucun, d'outils et de technologies 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 obtiennent de bons résultats, car ils sont les seuls à se concentrer sur le résultat et la fourniture tout au long de la chaîne d'approvisionnement logicielle ; mais cela 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 qu'elle fonctionne, le cloud n'existerait pas

Pour que nous puissions tous bénéficier d'une technologie révolutionnaire telle que la conteneurisation des infrastructures, nous devons envisager plus largement que nos outils à usage unique ou nos principaux domaines d'intérêt et repenser la façon dont nous concevons des produits pour ce secteur. Cela est différent de la révolution de la virtualisation et du cloud, et plus tôt nous nous en rendrons compte, plus nos clients en bénéficieront

Devops n'est pas simplement un ensemble d'outils fragmentés ou un projet de « transformation numérique » sophistiqué, c'est une méthode de collaboration entre les fonctions, rendue possible par la technologie. Par conséquent, toute technologie destinée au marché du DevOps, en particulier en matière de conteneurisation, doit avant tout aborder l'état d'esprit de collaboration continue. Concevons donc tous des produits dans cet esprit afin d'entamer et de maintenir une conversation entre les développeurs et les opérateurs.

Cet article a été publié pour la première fois ici