Services d'applications natives de conteneurs

Un nombre croissant de services d’application font partie intégrante d’une architecture cloud native. C'est en partie la raison pour laquelle nous constatons un déplacement de la responsabilité des services d'application des opérations informatiques vers DevOps.

Nous suivons plus de 30 services d'application différents dans notre recherche sur l'état des services d'application . Il y en a d’autres, et chaque année nous révisons la liste pour déterminer ce qu’il faut supprimer et ce qu’il faut ajouter.

Pour 2020, nous avons regroupé plusieurs services d’applications dans des catégories plus larges. Par exemple, le pare-feu réseau, l'antispam, l'IPS/IDS et l'atténuation du spam ont été regroupés dans des « services de sécurité communs ».  Nous avons choisi cette approche pour deux raisons. Premièrement, parce que six années de données ont indiqué des regroupements de services d’application avec des taux de déploiement très similaires. Deuxièmement, parce que nous voulions faire de la place aux services d’applications émergents et ne voulions pas submerger notre base de répondants déjà très patiente.

Ces services d’application émergents sont presque exclusivement des services d’application natifs de conteneurs. Ceux-ci sont généralement, mais pas toujours, déployés dans le cadre de l’environnement d’exploitation requis pour fournir une application cloud native. Pensez au contrôle d’entrée, à la découverte de services et au maillage de services. Les passerelles API sont également souvent étroitement couplées aux applications cloud natives, bien que leur utilisation soit largement alignée sur toute application basée sur API.

Compte tenu de leur importance croissante dans la fourniture d’applications cloud natives modernes et des taux de déploiement incroyables que nous constatons, il semble que ce soit le bon moment pour donner un aperçu de ces champions des approches cloud natives.

Contrôle d'entrée

État du déploiement des services d'application 2020 : Contrôle d'entrée

Le contrôle d'entrée est un concept introduit dans le monde Kubernetes pour découper et analyser les requêtes HTTP. Il permet aux opérateurs de mapper facilement un URI à un service Kubernetes spécifique. Cela permet le routage des requêtes entrantes (ingress) vers la bonne instance de microservice.

Ce n’était pas un concept nouveau. Les lecteurs assidus se souviendront que je vante souvent les vertus du routage HTTP (couche 7), notamment en tant que composant architectural conçu pour aider à des stratégies de mise à l’échelle plus efficaces. Si vous ne vous en souvenez pas ou si vous venez de nous rejoindre, ce discours est un bon rappel : Alors vous pensez que vous pouvez évoluer ?

Ce qui est nouveau, c'est la façon dont les « cartes » sont gérées. Les contrôleurs d’entrée doivent être mis à jour de manière dynamique en fonction des conditions actuelles à l’intérieur d’un cluster de conteneurs. Cela signifie qu’un contrôleur d’entrée doit avoir une visibilité sur l’état actuel d’un cluster. Cela signifie l'intégration avec les composants Kubernetes appropriés via son API opérationnelle.

Cette intégration est ce qui relie le contrôle d'entrée à l'environnement et l'intègre ainsi dans l'architecture de l'application. Un contrôleur d'entrée entièrement fonctionnel est intrinsèquement « natif du conteneur » car il fait partie de l'infrastructure requise pour faire évoluer et exploiter une application cloud native. 

Découverte de services

État du déploiement des services d'application 2020 : Découverte de services

Un fait intéressant à propos des 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 signifie nécessairement que les « conteneurs » sont en constante évolution. Les dernières données de Sysdig montrent des flux croissants, avec 39 % des conteneurs vivant moins d'une minute et 54 % vivant moins de 5 minutes.

Le problème avec cela est que d’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 à l'intérieur du cluster de conteneurs et servent de « source faisant autorité » pour les services. Les parties intéressées peuvent interroger ce composant pour découvrir comment se connecter et communiquer avec un service donné. En gardant une trace des services en temps réel, le composant de découverte de services gère la volatilité d'un cluster et permet à d'autres composants, tels que le contrôle d'entrée, de fonctionner correctement. 

Maillage de services

État du déploiement des services d'application 2020 : Maillage de services

Le service mesh est probablement le plus controversé des services d’application natifs de conteneurs. Non pas en raison de sa valeur conceptuelle, mais en raison des préférences de mise en œuvre. Les maillages de services sont conçus pour résoudre les problèmes de visibilité, d’échelle et de sécurité au sein des clusters de conteneurs. Ils sont implémentés en tant que proxys hyperconnectés (side-car ou par application) et offrent une variété de fonctionnalités pour les développeurs et les opérateurs.

Un service mesh n’est pas un service d’application que vous trouverez en dehors d’un cluster de conteneurs. Tout comme la découverte et le contrôle d’entrée, un service mesh est intimement intégré à l’environnement du conteneur. Cela en fait également un service d'application natif de conteneur. 

Services d'applications natives de conteneurs

Nous (l’industrie et le monde des entreprises) n’avons jamais catégorisé les services applicatifs de cette manière auparavant. Bien sûr, nous classons les éléments en fonction de leur utilisation principale : sécurité, disponibilité, performances, mobilité et identité. Mais il s’agit de catégories d’utilisation larges, et aucune n’est propre à une architecture d’application.

Mais l’intégration et les dépendances à une architecture cloud native peuvent rendre nécessaire de le faire pour ces services d’application (et tous les autres qui pourraient apparaître à l’avenir). C’est parce que la croissance de l’un (le service d’application) indique clairement la croissance de l’autre (l’architecture de l’application) – et vice-versa. Il s’agit d’une situation unique, dans laquelle les services d’application et les applications sont si intimement liés que les deux connaîtront des taux de déploiement très similaires. 

De la même manière que nous faisons la distinction entre les applications mobiles IOS et Android, nous pouvons trouver utile d'étiqueter les services d'application conçus pour fonctionner uniquement dans un environnement conteneurisé comme « natifs du conteneur » par rapport à ceux qui fonctionnent partout ailleurs.

Quelle que soit la manière dont nous les catégorisons, ils sont définitivement en hausse, tout comme les applications qui en dépendent.