Services d'application pour les applications Kubernetes : Même chose, nouveau

Il y a un long chemin à parcourir entre le dépannage de VMS VAX et l'écriture de microservices sans serveur (même si avec l'annonce du support COBOL dans AWS Lambda lors de re:Invent, le premier tour de la lemniscate informatique pourrait être terminé).

Beaucoup de choses ont changé en cours de route. Il me semble que j’avais pu pirater des scripts en Perl et que j’étais agacé par un système d’exploitation qui vous permettait de changer de répertoire vers un endroit qui n’existait pas (bonus : il vous permettait de le créer une fois que vous y étiez). Il semble désormais que l’on puisse passer autant de temps à décider de l’approche à adopter pour résoudre un problème qu’à le résoudre réellement. Et c'est fantastique. La gamme d’architectures, le rythme de développement, les opportunités numériques et la libération de la créativité des développeurs que tous les nouveaux jouets nous offrent sont formidables. Peu importe de quel côté de l’arche de proscenium vous vous trouvez, les développeurs et les consommateurs profitent de nouvelles et meilleures applications à un rythme et avec des fonctionnalités qui relevaient de la science-fiction il n’y a pas si longtemps.

Les conteneurs et leur gardien vigilant Kubernetes en sont un exemple pertinent. La technologie des conteneurs a incontestablement été un accélérateur clé de l’explosion du développement d’applications.

Cette semaine dans la ville ensoleillée de Seattle (à 10h46 le jour de la rédaction [Mise à jour – il faisait toujours beau à 13h36]), plus de 8 000 personnes se sont réunies pour discuter, écouter et en apprendre davantage sur Kubernetes et d’autres technologies liées à l’open source. Le mélange de conversations, d’apprentissage pratique et de stimulants constitue la soupe primordiale de l’innovation. Pendant que vous lisez ceci, 12 nouvelles idées géniales (et 37 terribles) auront été imaginées.

Certaines de ces applications changeront des vies, certaines innoveront en matière d’architecture, certaines feront évoluer les interfaces utilisateur, et certaines ne seront probablement qu’une autre façon d’illustrer à quel point je suis déconnecté de la culture des jeunes.

Mais quelques besoins vont unir ces diverses applications et les frameworks qu’elles utilisent. Les solutions peuvent sembler différentes, mais il existe des éléments critiques que chacun doit résoudre :

Échelle – Si vous voulez réussir, vous devez être capable de le devenir en cours de route (et probablement de revenir en arrière de temps en temps).

Stabilité – Toutes les applications ont besoin d'un niveau de stabilité approprié – depuis « réussir la démonstration sur scène » jusqu'aux exigences de disponibilité potentiellement mortelles.

Sécurité – Il existe des personnes malveillantes, et parfois elles attaqueront vos applications. La complexité des systèmes modernes semble étendre sans cesse la surface d’attaque dont vous devez vous soucier.

Observabilité – Voir c’est croire, ce qui est doublement important lorsqu’il y a un problème. Transférer rapidement les bonnes informations de la couche OSI aux bonnes personnes peut vous aider à moins échouer, à récupérer plus rapidement et à rendre le monde « vous le construisez, vous l'exécutez » un peu plus confortable.

Ces besoins ne sont pas vraiment uniques, mais ils restent les préoccupations fondamentales qui doivent être prises en compte par chaque application bien conçue, idéalement avant qu’ils ne deviennent un problème et avant qu’une ligne de code ne soit écrite.

Mon estimé employeur, F5 Networks, a bâti une entreprise de plusieurs milliards de dollars répondant à ces besoins, et honnêtement, nous sommes plutôt bons dans ce domaine (mais je dirais que). Nous appelons les choses que nous fabriquons pour répondre à ces besoins des services applicatifs . Services applicatifs qui sécurisent le trafic applicatif, l'inspectent, le dirigent. Services d'application qui orientent les clients vers le bon endroit, services d'application qui extraient, transmettent et affichent la télémétrie d'application clé. Il s'agit des services de base qui ont permis à nos clients de maintenir leurs applications opérationnelles. Il s'agit du type de services dont les applications continuent d'avoir besoin, peu importe où et comment elles sont créées.

Comment revenir à un argumentaire de vente ?

Jusqu'ici, c'est un « vieux grincheux qui essaie de me convaincre que sa technologie à l'ancienne est toujours d'actualité ». OK, voici donc ce qui s’est retourné, s’est tordu dans l’air et a atterri à l’envers. Commençons par le plus important : La façon dont les services sont déployés.

L’une des technologies habilitantes à l’origine de l’adoption de plateformes et de pratiques de travail a été les systèmes qui relient l’intention à l’action de manière automatisée et intégrée. Les services d’application doivent faire partie de cette chaîne, ce qui représente un changement plus fondamental qu’un simple changement dans les temps d’exécution.

Parfois, les services doivent être injectés dans des composants existants, comme la visibilité et le contrôle exceptionnels qu'Aspen Mesh ajoute à Istio . Alternativement, des outils de connexion comme F5 Container Connector peuvent lier des environnements à des services, de sorte que lorsque des pods Kubernetes sont ajoutés ou supprimés, ils peuvent être sécurisés, mis à l'échelle et observés.

Idéalement, le code permettant de créer les services d’application doit exister dans le même référentiel que le code de cette application et être déployé de la même manière. Les définitions de services d'application (par exemple un service de pare-feu d'application Web) doivent exister sous forme de code et être traitées comme du code. Ainsi, une modification de définition de service et une validation dans la gestion du code source produisent un déploiement de pare-feu d'application Web de production sans autre intervention humaine. Dans les dernières nouvelles, Melaine Cebula d'Airbnb, qui parle vite, a décrit exactement ce modèle lors de sa conférence de mercredi à Kubecon, lorsqu'elle a décrit le maintien de tous les composants d'un service - y compris les définitions d'infrastructure - dans un seul projet (ainsi qu'une cinquantaine d'autres choses intéressantes qu'ils font pour faciliter la vie des développeurs d'applications).

Ce changement dans l’instanciation des services (associé à la disparition bienvenue des longues files d’attente de tickets informatiques) est spectaculaire et évident.

Le deuxième changement est peut-être un peu plus banal, mais toujours critique. L’un des avantages de Kubernetes et des conteneurs est la portabilité entre les environnements. Votre microservice géré par Kubernetes s'exécutera partout où un moteur de conteneur pris en charge s'exécute (indice : partout), et les mêmes services d'application doivent également être présents, et non pas « à peu près les mêmes » ou « faire la même chose d'une manière différente avec une interface légèrement différente ». Le même. Cela signifie que le nombre d’endroits où nous devons nous déployer augmente constamment.

La nécessité de travailler de la même manière et aux mêmes endroits que tous vos déploiements Kubernetes actuels et potentiels est devenue un principe directeur pour F5.

C’est absolument essentiel, car nos clients comptent non seulement sur nous pour maintenir leurs applications existantes à l’échelle et sécurisées, mais ils doivent également savoir que nous protégerons et observerons les applications qui sont – au moment où j’écris ces lignes – considérées comme une molécule de caféine malveillante se liant à un récepteur d’adénosine chanceux ayant besoin d’un coup de pouce après le déjeuner.