Services applicatifs natifs pour conteneurs

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Un nombre croissant de services applicatifs font partie intégrante d’une architecture cloud native. C’est notamment pour cette raison que la responsabilité de ces services passe progressivement des équipes d’exploitation informatique aux équipes DevOps.

Nous suivons plus de 30 services applicatifs différents dans le cadre de notre étude « État des services applicatifs ». Il en existe davantage et, chaque année, nous réexaminons la liste afin de déterminer lesquels retirer et lesquels ajouter.

Pour 2020, nous avons regroupé plusieurs services applicatifs au sein de catégories plus larges. Par exemple, le pare-feu réseau, la protection antispam, les systèmes IPS/IDS et la lutte contre le spam ont été réunis sous l’appellation « services de sécurité courants ». Nous avons retenu cette approche pour deux raisons. Premièrement, parce que six années de données ont fait apparaître des groupes de services applicatifs présentant des taux de déploiement très similaires. Deuxièmement, parce que nous souhaitions faire de la place aux nouveaux services applicatifs sans surcharger davantage les répondants, qui font déjà preuve d’une grande patience.

Ces services applicatifs émergents sont presque exclusivement des services applicatifs natifs des conteneurs. Ils sont généralement, mais pas toujours, déployés dans le cadre de l’environnement d’exploitation nécessaire à la mise à disposition d’une application cloud native. On peut notamment citer le contrôle des entrées, la découverte de services et le maillage de services. Les passerelles d’API sont elles aussi souvent étroitement liées aux applications cloud natives, bien que leur utilisation concerne plus largement toute application reposant sur des API.

Compte tenu de leur importance croissante dans la mise à disposition d’applications modernes et cloud-native, ainsi que des taux de déploiement exceptionnels que nous observons, le moment semble bien choisi pour apporter quelques éclaircissements sur ces fers de lance des approches cloud-native.

Contrôle des entrées

Déploiement de l’édition 2020 de State of Application Services : contrôle des entrées

Le contrôle d’entrée est un concept introduit dans l’univers Kubernetes pour répartir et traiter les requêtes HTTP. Il permet aux opérateurs d’associer facilement un URI à un service Kubernetes spécifique. Les requêtes entrantes (ingress) peuvent ainsi être acheminées vers l’instance de microservice appropriée.

Ce concept n’était pas nouveau. Les lecteurs assidus se souviendront que je vante souvent les mérites du routage HTTP (couche 7), notamment en tant que composant architectural conçu pour favoriser des stratégies de mise à l’échelle plus efficaces. Si vous ne vous en souvenez pas ou si vous venez de nous rejoindre, cette conférence vous permettra de vous rafraîchir la mémoire : Alors, vous pensez savoir gérer la montée en charge ?

Ce qui est nouveau, c’est la manière dont les « cartes » sont gérées. Les contrôleurs d’entrée doivent être mis à jour dynamiquement en fonction des conditions actuelles au sein d’un cluster de conteneurs. Cela signifie qu’un contrôleur d’entrée doit avoir une visibilité sur l’état actuel du cluster. Il doit donc être intégré aux composants Kubernetes appropriés par l’intermédiaire de son API opérationnelle.

C’est cette intégration qui relie le contrôle des entrées à l’environnement et l’intègre ainsi à l’architecture de l’application. Un contrôleur d’entrées pleinement fonctionnel est par nature « natif pour les conteneurs », car il fait partie de l’infrastructure nécessaire pour faire évoluer et exploiter une application cloud native.

Découverte de services

État du déploiement des services applicatifs en 2020 : découverte de services

Un fait intéressant concernant les applications cloud natives est la durée de vie de leurs composants. La nature dynamique de l’évolutivité au sein d’un cluster de conteneurs implique nécessairement que les « conteneurs » sont en constante évolution. Les dernières données de Sysdig montrent une accélération de cette évolution, 39 % des conteneurs ayant une durée de vie inférieure à une minute et 54 % une durée de vie inférieure à 5 minutes.

Le problème, c’est que les autres composants doivent pouvoir trouver ces conteneurs.

C’est la raison d’être du composant de découverte de services. Ces composants s’exécutent au sein du cluster de conteneurs et font office de « source faisant autorité » pour les services. Les parties intéressées peuvent interroger ce composant afin de savoir comment se connecter à un service donné et communiquer avec lui. En assurant le suivi des services en temps réel, le composant de découverte de services pallie la volatilité d’un cluster et permet à d’autres composants — tels que le contrôle des entrées — de fonctionner correctement.

Maillage de services

État des services applicatifs 2020 – Déploiement : maillage de services

Le maillage de services est probablement le plus controversé des services applicatifs natifs pour conteneurs. Non pas en raison de sa valeur conceptuelle, mais des préférences en matière d’implémentation. Les maillages de services sont conçus pour résoudre les problèmes de visibilité, de mise à l’échelle et de sécurité au sein des clusters de conteneurs. Ils sont implémentés sous forme de proxys hyperconnectés — soit en side-car, soit par application — et offrent diverses fonctionnalités aux développeurs comme aux opérateurs.

Un maillage de services n’est pas un service applicatif que l’on trouve en dehors d’un cluster de conteneurs. À l’instar de la découverte de services et du contrôle des flux entrants, un maillage de services est étroitement intégré à l’environnement de conteneurs. Il s’agit donc également d’un service applicatif natif pour les conteneurs.

Services applicatifs natifs pour les conteneurs

Nous (le secteur et le « nous » de l’entreprise) n’avions encore jamais classé les services applicatifs de cette manière. Bien entendu, nous les classons selon leur usage principal : sécurité, disponibilité, performances, mobilité et identité. Mais il s’agit de grandes catégories d’usage, dont aucune n’est propre à une architecture applicative.

Mais l’intégration à une architecture cloud native et les dépendances à son égard pourraient rendre cette catégorisation nécessaire pour ces services applicatifs (ainsi que pour tous ceux qui pourraient apparaître à l’avenir). En effet, la croissance de l’un (le service applicatif) indique clairement celle de l’autre (l’architecture applicative), et inversement. Il s’agit d’une situation unique, dans laquelle les services applicatifs et les applications sont si étroitement liés que leurs taux de déploiement seront très similaires.

De la même manière que nous distinguons les applications mobiles iOS et Android, il pourrait être utile de qualifier de « natives pour les conteneurs » les services applicatifs conçus pour fonctionner uniquement dans un environnement conteneurisé, par opposition à ceux qui fonctionnent partout ailleurs.

Quelle que soit la manière dont nous les catégorisons, ces services sont incontestablement en plein essor, tout comme les applications qui en dépendent.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie