Il est clair depuis plusieurs années que la conteneurisation est la nouvelle norme pour l’infrastructure informatique des entreprises. Une enquête menée par Red Hat en collaboration avec CCS Insight a révélé que 91 % des développeurs estiment qu’il est hautement prioritaire de transférer les applications et les charges de travail vers des conteneurs. Cependant, si la gestion du cycle de vie d’un conteneur est facile, lorsqu’il s’agit de gérer des milliers, voire des millions de conteneurs, les équipes doivent déployer un système d’orchestration de conteneurs. De loin, l’environnement de solution le plus courant pour l’orchestration est Kubernetes, utilisé par jusqu’à 83 % des organisations qui exécutent des conteneurs.
Cependant, lorsque nous parlons de Kubernetes à un niveau élevé, nous le simplifions souvent à l’extrême en l’assimilant à un système qui permet l’utilisation de conteneurs, ce qui ne correspond pas à la réalité. Kubernetes est plutôt une solution qui répond à certains défis centraux concernant la gestion des ressources et l’orchestration entre les conteneurs.
Si cela fait de Kubernetes un outil nécessaire à l’exploitation des conteneurs dans votre organisation, il ne suffit pas à faire fonctionner un environnement de conteneurs. Outre Kubernetes, une plate-forme de conteneurs nécessite un registre de conteneurs, un moteur de conteneurs, des capacités de stockage, une infrastructure de réseau, des moteurs d’exécution, une journalisation et une surveillance, ainsi que de nombreux autres éléments d’infrastructure. Tout cela doit reposer sur un système d’exploitation sous-jacent, ainsi que sur d’autres infrastructures et processus, ce qui est essentiel si une équipe souhaite réaliser l’intégration continue/livraison continue (CI/CD) pour permettre, accélérer et appliquer les pratiques DevOps.
Ainsi, lorsqu’il s’agit de « déployer Kubernetes », nous entendons généralement par là le déploiement d’une solution qui inclut tous les éléments ci-dessus, c’est-à-dire que vous vous engagez à faire bien plus que d’exécuter Kubernetes seul. Il y a deux façons de procéder : soit vous choisissez une distribution gratuite ou commerciale qui s’est chargée de ce travail, soit vous construisez tout à partir de zéro et vous le faites vous-même. En général, je trouve que cette dernière solution est déconseillée.
>Voir aussi : Tirez les leçons du battage médiatique autour du chou frisé : ne vous précipitez pas sur Kubernetes.
Le choix d’une distribution est plus efficace
Lorsque vous choisissez une « distribution » Kubernetes établie et reconnue, vous choisissez effectivement une solution qui est livrée prête à l’emploi avec tout ou partie des éléments nécessaires pour orchestrer et gérer les conteneurs à l’échelle. Dans une distribution Kubernetes (« distro »), quelqu’un d’autre a pris le temps de développer, de tester et d’intégrer tous les composants nécessaires à votre infrastructure de conteneurs.
Cela permettra à vos équipes de se concentrer sur la valeur ajoutée de leur travail : le développement et la livraison d’applications. Avec la certitude que cela fonctionnera dès le départ, et que cela permettra à votre équipe de se concentrer sur l’exécution de ses rôles quotidiens, les distros peuvent être une option très séduisante pour la plupart des entreprises. En vous associant au bon fournisseur, vous pouvez libérer la puissance des conteneurs et de Kubernetes sans avoir à en gérer toute la complexité.
En outre, « aller distro » vous donne accès à de nombreuses sources d’assistance. Par exemple, une communauté d’utilisateurs pour une distro établie peut soutenir votre propre équipe en fournissant un pool de connaissances pour le dépannage et la planification. Les distros qui disposent d’un support payant peuvent aller plus loin et vous mettre directement en relation avec les créateurs pour vous aider à libérer la puissance de votre environnement Kubernetes.
Ainsi, une distro offre une voie plus rapide et plus fiable pour déployer votre plateforme de conteneurs. Il n’y a qu’un seul inconvénient nominal à cela qui pousse certaines personnes à se détourner des distros et à opter pour une solution DIY – le spectre de la dépendance vis-à-vis du fournisseur.
Le mythe du « verrouillage » des distros Kubernetes
La raison la plus courante pour laquelle une équipe évite une distro Kubernetes et préfère le bricolage est la peur du verrouillage. Compte tenu de la rapidité avec laquelle le paysage informatique des entreprises évolue, de nombreuses équipes se sentent obligées de s’assurer que leur environnement de conteneurs est aussi flexible que possible, ce qui les incite à choisir le DIY. Le raisonnement est le suivant : si la plate-forme de conteneurs d’une équipe est DIY, elle ne dépend pas de l’architecture d’un seul fournisseur et peut donc pivoter rapidement si nécessaire.
Cela peut cependant être une vision à court terme. En vérité, il est impossible d’échapper à l’enfermement dans une certaine mesure : la question est de savoir avec qui vous êtes enfermé. Un environnement Kubernetes bricolé ne fait que remplacer l’enfermement avec un fournisseur par l’enfermement avec l’équipe qui a développé cette solution bricolée, surtout si cette solution comporte un code inhabituel ou des solutions de contournement, ou n’est pas largement documentée.
Si vous disposez d’une petite équipe et que vous perdez le chef de projet de votre plateforme de conteneurs bricolée, vous avez de gros problèmes – vous étiez effectivement lié à cette personne. Alors qu’un fournisseur peut garantir la continuité du support avec une distro Kubernetes, une solution DIY n’a rien de tel.
Les distros fournissent un pipeline clair de mises à jour et d’améliorations, alors que si vous optez pour le DIY, ce sera à votre équipe de travailler continuellement pour rester à la pointe de l’industrie. En fin de compte, ce qui compte, c’est de fournir des applications aux clients, et si une infrastructure sur mesure entrave cet objectif, alors c’est un problème.
>Voir aussi : Comment Kubernetes s’étend à l’apprentissage machine (ML)
Le bricolage est préférable pour les affaires de niche
Plus tôt, j’ai comparé la construction d’une plateforme de conteneurs DIY à la réinvention de la roue en interne. Mais c’est probablement plus analogue à réinventer l’automobile, étant donné qu’une solution DIY nécessitera que vous ayez une équipe extrêmement qualifiée avec un haut degré de connaissances spécialisées dans une variété de domaines, y compris le stockage, le réseau, la sécurité et la surveillance.
Au lieu que votre équipe se concentre sur les livrables qui génèrent de la valeur, c’est-à-dire sur la réalisation de métriques orientées métier, la mise en œuvre de DIY Kubernetes l’oblige à porter son attention sur quelque chose qui n’a pas d’impact de premier ordre sur la capacité à atteindre les objectifs métier. L’investissement en temps et en capital pour reproduire le travail déjà effectué par une distribution est considérable, et comme mentionné ci-dessus, il comporte ses propres risques.
Bien sûr, il y a des cas où les équipes ont un avantage compétitif dans un environnement DIY. Bien que ces cas soient de plus en plus rares au fur et à mesure que les distros sont publiées et arrivent à maturité. Mais votre équipe devrait être en mesure d’identifier facilement de tels cas, étant donné qu’elle exploite probablement des charges de travail ou une architecture très spécialisées ou peu orthodoxes. Toutefois, il existe désormais une série de distributions qui couvrent la grande majorité des cas d’utilisation de Kubernetes et des conteneurs, y compris ceux qui se situent à l’extrémité la plus « niche » du spectre : si ce que vous faites et exécutez est si exceptionnel que vous n’êtes pas couvert par la diversité des distributions, votre équipe devrait être en mesure de vous le dire dès le départ.
Étant donné qu’une distro peut garantir un déploiement plus rapide de votre plateforme de conteneurs, qu’elle est plus exigeante en termes de sécurité et qu’elle fournit un pipeline de support clair, il est très difficile de justifier une solution DIY sur le marché actuel. Plutôt que de demander à votre équipe de passer du temps à recréer une infrastructure de conteneurs déjà disponible, il est presque toujours préférable qu’elle se concentre sur la création des applications dont votre organisation a besoin pour atteindre ses objectifs commerciaux.
Chuck Svoboda est directeur senior mondial des services GTM chez Red Hat.
Relié :
Voici pourquoi Kubernetes est une compétence très demandée… Alors que de plus en plus d’entreprises adoptent le système de gestion de logiciels open-source de Google, la demande de personnes talentueuses possédant des compétences Kubernetes augmente rapidement.
Exploitation de Kubernetes : la prochaine frontière de la cybersécurité. Discussion sur les plus grands défis de cybersécurité à prendre en compte autour de Kubernetes.