Comment les conteneurs modifient l'évolutivité
Le terme « échelle du nuage » est souvent utilisé à tort et à travers. Il est souvent utilisé en marketing pour impliquer une échelle VRAIMENT GRANDE par opposition à, je suppose, l'échelle traditionnelle pas aussi grande mais toujours significative.
Mais tout comme il existe des éléments de vérité cachés dans les mythes et les légendes, il y a une part de vérité dans la manière dont le terme « échelle des nuages » est utilisé.
La vérité est que le cloud (et désormais les conteneurs) ont modifié les fondements sous-jacents de l’évolutivité. Ce changement trouve son origine dans les différences fondamentales entre les stratégies de mise à l’échelle verticale et horizontale. Durant la première décennie du siècle, nous avons fonctionné presque exclusivement sur la notion que l’échelle verticale était le meilleur moyen d’atteindre les vitesses et les flux dont nous avions besoin. Cela signifiait plus de bande passante, plus de puissance de calcul et plus de mémoire. Plus de ports. Densité plus grande. Traitement plus rapide.
Mais avec l’avènement de l’ère du cloud, l’accent s’est déplacé vers l’échelle horizontale. Nous avons toujours besoin de davantage de bande passante, de puissance de calcul et de traitement, mais nous avons appris à répartir ce besoin. Nous avons encore besoin de plus de matériel, nous l’assemblons simplement à partir de plusieurs sources plutôt que d’une seule entité monolithique.
C’est la façon dont les ressources sont assemblées qui change la donne. Et ne vous y trompez pas, le jeu a changé grâce aux conteneurs.
L’échelle dépend aujourd’hui du plan de contrôle. La vitesse de l’API utilisée pour lancer et désactiver les ressources est peut-être plus importante que la vitesse du service d’équilibrage de charge lui-même. La vitesse de découverte de services dans un environnement où les ressources sont lancées et retirées en quelques minutes devient primordiale pour transmettre les requêtes à une instance disponible.
Plus de la moitié (52 %) des conteneurs ont une durée de vie inférieure à cinq minutes selon le Sysdig Container Usage Report 2019 :
- 22% <= 10 secondes
- 17% <= 1 minute
- 15% <= 5 minutes
Près de la moitié (42 %) exploitent entre 201 et 500 instances de conteneurs. Pour maintenir la précision, le plan de contrôle met fréquemment à jour les composants. Bien plus fréquemment que le cloud, et certainement bien plus fréquemment que ce que l’on observe avec les applications monolithiques.
La vitesse à laquelle le contrôleur d’entrée (le mécanisme d’équilibrage de charge) est mis à jour pour refléter l’ensemble actuel des ressources disponibles devient alors une capacité critique. Car si c’est une erreur, une demande d’un consommateur pourrait être dirigée vers une ressource qui n’existe plus ou qui héberge un service complètement différent. Dans tous les cas, le résultat est une réponse plus longue car la demande est redirigée vers une ressource disponible. Le consommateur doit attendre plus longtemps pour obtenir une réponse et peut choisir de partir.
Tout cela indique que la vitesse du plan de contrôle est un facteur bloquant dans l’évolutivité des applications déployées dans un environnement conteneurisé.
En fin de compte, cela signifie que l’échelle du plan de contrôle est un problème. La conception de l'API est un problème. Les mécanismes par lesquels les demandes et les mises à jour de l’API sont authentifiées et autorisées constituent un problème.
Le plan de contrôle est aujourd’hui au cœur de la scène en matière d’évolutivité. Un plan de contrôle robuste et évolutif n’est pas un atout. C'est un MUST RFC aujourd'hui.