je ne mentirai pas Assis dans un avion au départ de Valence, j’avoue avoir été surpris par la taille de Kubecon Europe cette année. Pour ma décharge, je n’étais pas le seul à avoir semblé surprendre les organisateurs de la conférence et les exposants, comme en témoigne le manque notable d’eau, (me dit-on) de t-shirts et (à divers endroits) de taxis.
Les keynotes étaient pleines à craquer et il y avait un véritable buzz de la part des participants qui semblaient se diviser en deux camps : les jeunes et cool et les plus matures et habillés sobrement.
La plupart de mon temps est consacré à des réunions en tête-à-tête, des conférences d’analystes / de presse et à marcher dans les stands, je ne peux donc pas commenter les sessions techniques. Tout au long de l’article, cependant, il y avait un réel sentiment que Kubernetes concerne désormais le comment, pas le si. Pour une raison ou une autre, les entreprises ont décidé de tirer parti de la création et du déploiement d’applications distribuées basées sur des conteneurs.
Curieusement, cela n’était pas considéré comme une épée magique capable de tuer les dragons des systèmes anciens et d’ouvrir la voie à la transformation numérique. Le Kool-Aid était aussi absent que l’eau. En fin de compte, les entreprises ont accepté que d’un point de vue architectural et pour les applications en général, le modèle Kubernetes est à peu près disponible actuellement en tant que norme ouverte non propriétaire et bien prise en charge qu’elles peuvent prendre en charge.
Les options basées sur la virtualisation et les piles de plates-formes sont trop lourdes ; Les architectures sans serveur sont plus adaptées à des cas d’utilisation spécifiques. Donc, si vous voulez créer une application qui sera évolutive, vous devez viser l’objectif de Kubernetes.
Adopter Kubernetes peut être une évidence, mais comment l’adopter ne l’est certainement pas. Le défi n’est pas avec Kubernetes lui-même, mais avec tout ce qui doit être contourné pour rendre les applications résultantes prêtes pour l’entreprise.
Par exemple, ils doivent fonctionner dans des environnements de conformité ; Les données doivent être gérées, protégées et livrées dans un environnement qui ne se soucie pas trop de l’état ; Des outils d’intégration sont nécessaires avec les systèmes externes et hérités ; Les pipelines de développement doivent être en place, solides et axés sur la valeur ; Les opérations informatiques ont besoin d’une vision claire de ce qui est en cours d’exécution, tandis qu’une nomenclature et la santé des clusters individuels ; et la reprise après sinistre est indispensable.
Kubernetes ne fait pas ces choses, ouvrant la porte à un écosystème de fournisseurs de solutions et de projets open source (souvent soutenus par la CNCF). Je pourrais plonger dans ces domaines du service mesh, GitOps, de l’orchestration, de l’observabilité et de la sauvegarde, mais le point plus large est qu’ils évoluent et fusionnent tous autour des besoins. À mesure que les performances augmentent, les obstacles à l’adoption diminuent et le nombre de cas d’utilisation potentiels augmente.
Tout cela amène l’industrie à un point intéressant. Ce n’est pas que les outils ne soient pas prêts : les organisations déploient déjà avec succès des applications sur Kubernetes. Cependant, dans de nombreux cas, ils font plus de travail que nécessaire, les développeurs ont besoin d’une connaissance approfondie des environnements cibles, les interfaces doivent être intégrées au lieu d’utiliser des API tierces, les outils de gestion d’ordre supérieur (comme AIOps) doivent être personnalisés. plutôt que d’honorer les normes de fonctionnement de Kubernetes.
Bien que des solutions existent, elles ont tendance à provenir de fournisseurs relativement nouveaux qui sont des acteurs de fonctionnalités plutôt que de plates-formes, ce qui signifie que les organisations d’utilisateurs finaux doivent choisir judicieusement leurs partenaires, puis créer et maintenir elles-mêmes des plates-formes de développement et de gestion plutôt que d’utiliser des outils pré-intégrés. vendeur unique.
Rien de tout cela n’est un problème en soi, mais cela crée des frais généraux pour les utilisateurs, même s’ils bénéficient plus tôt de l’adoption du modèle Kubernetes. La valeur de l’avantage du premier arrivé doit être mise en balance avec l’investissement en temps et en efforts dans l’état actuel des outils : comme une agence de voyage m’a dit un jour : « Nous voulons être le meilleur site de voyage au monde, pas la meilleure plateforme au monde ingénieurs. »
Ainsi, Kubernetes est peut-être inévitable, mais il deviendra également plus facile, permettant aux organisations d’appliquer l’architecture à une gamme toujours plus large de scénarios. Pour les organisations qui n’ont pas encore fait le pas vers Kubernetes, le moment est peut-être encore venu de faire une preuve de concept, bien que SIP ait navigué à certains égards, peut-être concentrer le PoC sur ce que ses pratiques et structures de travail sont des moyens, plutôt que de déterminer si les concepts fonctionnent du tout.
En attendant, et peut-être le plus important, c’est le moment idéal pour les organisations d’explorer les scénarios Kubernetes qui fonctionnent le mieux, en collaborant avec les fournisseurs et en examinant les modèles architecturaux afin d’identifier les résultats éprouvés pour ceux spécifiques à forte valeur. qui sont susceptibles d’être par industrie et par domaine (je pourrais entrer plus en détail, mais ai-je mentionné que je suis dans un avion ? ).
Kubernetes est peut-être une affaire conclue, mais cela ne signifie pas qu’il doit être pleinement adopté avant que certains détails périphériques ne soient réglés.
La publication Avis de KubeCon Europe 2022 est apparue en premier sur Germanic Nachrichten.