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.
Avec l’avènement de l’ère du cloud, l’attention s’est portée sur l’échelle horizontale. Vous avez toujours besoin de plus de bande passante, de puissance de calcul et de traitement, mais vous savez désormais répartir ces besoins. Vous avez encore besoin de matériel, mais vous l’assemblez désormais à partir de plusieurs sources au lieu d’une entité monolithique unique.
La manière dont on organise les ressources bouleverse tout. Et croyez-le, tout a changé avec l’arrivée des conteneurs.
Aujourd'hui, l’échelle repose sur le plan de contrôle. La rapidité de l'API pour lancer et retirer les ressources compte souvent plus que celle du service d’équilibrage de charge lui-même. Dans un environnement où les ressources se déploient et s'arrêtent en quelques minutes, la rapidité de la découverte des services devient essentielle pour acheminer les requêtes vers 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 rapidité avec laquelle vous mettez à jour le contrôleur d’entrée (le mécanisme de répartition de charge) pour qu’il reflète l’ensemble actuel des ressources disponibles devient une capacité essentielle. Si vous vous trompez, une requête de consommateur peut être envoyée vers une ressource qui n’existe plus ou qui héberge un service totalement différent. Dans tous les cas, la redirection vers une ressource disponible allonge le temps de réponse. Vous devez patienter plus longtemps et le consommateur risque d’abandonner.
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.