Pour les développeurs, l’une des choses les plus passionnantes à propos de Docker – et de la révolution des conteneurs au sens large – était la façon dont il améliorait l’expérience des développeurs.
Les images de base ont réduit la vitesse d’échappement nécessaire pour les nouveaux projets. Les environnements portables en bac à sable réduisent les brouillages cauchemardesques « ça tourne sur ma machine ». Docker a été construit du point de vue d’un développeur, et cela se voit.
Il toujours montre. Docker est en tête de sa catégorie dans les résultats de l’enquête annuelle de StackOverflow pour les outils de développement « les plus appréciés » et « les plus recherchés ».
Mais quelque chose s’est passé sur le chemin de la domination mondiale actuelle des conteneurs. Dans le but d’exécuter des applications conteneurisées complexes à grande échelle, les systèmes d’orchestration comme Kubernetes ont adopté une perspective opérationnelle globale. Cela avait du sens, mais cela a coûté cher aux développeurs. Et avec la maturité et l’omniprésence croissantes de Kubernetes, il est plus clair que jamais qu’il existe une meilleure solution.
tu as été assimilé
Kubernetes a ses racines dans le système de gestion de cluster interne « Borg » de Google – pas un outil centré sur le développeur à la manière de Docker, mais une bonne excuse pour une métaphore étendue ringard.
Dans Star Trek, les Borgs sont un peuple/paradigme cybernétique qui assimile toute forme de vie qu’ils rencontrent dans un système cohérent, cohérent et rationalisé. D’où le nom du système de Google : si vous êtes un opérateur d’infrastructure informatique, toute cette assimilation et cette normalisation sonnent plutôt bien. Vous voulez traiter les composants et les applications de la même manière que le Borg traite les êtres vivants : intégrez-les dans votre système comme un ensemble d’abstractions communes que vous pouvez gérer de manière standardisée.
C’est formidable d’un point de vue opérationnel. Mais les besoins et les priorités des systèmes d’orchestration à grande échelle ne sont pas les mêmes que ceux des êtres humains qui écrivent du code. Ainsi, pour les développeurs, même les concepts de base de Kubernetes peuvent sembler étrangers, comme s’ils provenaient d’un tout autre type d’esprit. Pods, nœuds, ReplicaSets… tout cela semble même vaguement science-fictionnel. Mais ce type de méconnaissance conceptuelle n’est rien comparé à la façon dont Kubernetes demande aux développeurs de réapprendre ce qu’ils pensaient savoir sur, par exemple, l’utilisation du stockage persistant. Et ce n’est vraiment rien comparé aux tracas permanents des manifestes YAML ou à l’inefficacité de la boucle de développement interne de Kubernetes.
Une boucle gênante
La boucle de développement interne est le cycle de travail quotidien d’un programmeur donné, de l’écriture aux tests en passant par le débogage du code. Si vous écrivez et testez simplement du code Node ou Python sur votre machine locale, pour un déploiement sur un serveur traditionnel, votre boucle interne est assez simple : écrivez le code, exécutez-le et corrigez les problèmes. Rincer et répéter.
Mais si ce même code doit être conteneurisé et déployé via Kubernetes, vous avez maintenant plusieurs étapes supplémentaires : créer une image de conteneur, la télécharger dans un registre, créer une ressource Kubernetes, exécuter le conteneur, puis déboguer tout problème qui survient. (ce qui peut être un problème de code pur ou résulter de configurations incorrectes de Kubernetes). Oh, et vous aurez besoin d’un cluster de développement qui correspond à l’environnement de production pour faire tout cela.
C’est beaucoup. Le simple fait est qu’une boucle de développement Kubernetes standard n’est pas adaptée au bonheur ou à l’efficacité des développeurs. Du point de vue d’un développeur, il s’agit d’un processus sous-optimal.
Le point ici n’est pas que « Kubernetes est trop difficile » ou « les développeurs détestent Kubernetes ». (Les développeurs sont un groupe diversifié avec beaucoup d’opinions différentes, mais l’enquête annuelle de StackOverflow suggère que, dans l’ensemble, ils ne le font pas.) La boucle que je viens de décrire n’est pas la seule expérience possible pour les développeurs Kubernetes, mais elle est l’expérience par défaut si vous utilisez simplement Kubernetes prêt à l’emploi.
Heureusement, Kubernetes peut être tellement meilleur.
Plus que ce qui est dans la boîte
Même si Kubernetes semble étranger et inaccessible, il fournit les moyens de résoudre ses propres problèmes de courbe d’apprentissage. En raison de sa soif d’assimilation, Kubernetes est également, fondamentalement et de manière cruciale, conçu pour s’étendre. Et son extensibilité géniale nous permet d’abstraire même la propre complexité de Kubernetes.
L’écosystème natif du cloud regorge d’outils open source qui s’associent pour rendre Kubernetes plus riche et plus convivial :
- Knative : un projet de déploiement sans serveur sur Kubernetes, apportant la simplicité et la convivialité du sans serveur pour les développeurs à une plate-forme open source indépendante du cloud.
- Lagoon : une plate-forme de développement d’applications Web qui crée des environnements de développement à partir des mêmes images que la production, simplifiant la parité entre les environnements.
- Argo : une suite d’outils CI/CD permettant aux développeurs d’utiliser Git comme source unique de vérité, une approche populaire appelée « GitOps ».
- Prometheus : un système d’observabilité avec des API riches qui se connectent à tout, de l’interface utilisateur graphique Lens pour Kubernetes à la plate-forme de visualisation Grafana en passant par les systèmes CI/CD, aidant à tenir les développeurs informés de ce qui se passe dans un cluster.
Nous effleurons à peine la surface ici – Kubernetes regorge d’outils open source incroyables pour faciliter la vie des développeurs.
Les développeurs n’ont pas à être absorbés par un paradigme entièrement nouveau. Il s’agit simplement de donner la priorité à l’expérience des développeurs et de tirer parti de l’expertise cloud native et de l’écosystème de plus en plus riche. Connaître les bons outils et les moyens de les configurer n’est pas anodin, mais c’est là que les opérateurs entrent en jeu – et pour les organisations aux ressources limitées, les offres DevOps-as-a-service peuvent aider à fournir de meilleures expériences de développement avec un minimum de tracas à la fin de l’op.
Les fans de Star Trek savent que la menace Borg résiste grâce aux connaissances acquises auprès des personnes assimilées. Pour les développeurs, Kubernetes ne doit pas du tout être une menace, et avec les bons outils et les bonnes connaissances de la communauté cloud-native, il a le pouvoir de rendre le développement encore plus simple et plus puissant que jamais.