Tech Radar Cloud - Resilient

Adopt

Caas

Les services de "Container as a Service" permettent de se rapprocher du "Serverless" sans fondamentalement impacter la façon dont vous organisez ou développez vos applications.

Aujourd'hui la plupart des Cloud Providers proposent une offre CaaS (e.g. CloudRun sur GCP, AWS Lambda/ECS sur AWS, ACS sur Azure). Celle-ci est adaptée aux équipes ne nécessitant pas une customisation importante. Elle permet un gain important en coûts de maintenance et d'hébergement de par certaines de leurs features (e.g. le scale à 0).

Utiliser un service CaaS aujourd'hui peut être une première grande étape dans la modernisation de vos applications ou la création d'une nouvelle application.

Le CaaS apparaît comme une vraie alternative à :

Kubernetes, de par sa complexité de mise en place et de maintenance
Serverless, de par la transformation architecturale qu'il implique

Un autre avantage du CaaS est qu'il est par définition moins vendor-lock que d'autres services d'hébergement. Votre application est ainsi packagée via un standard du marché (une image OCI) et peut potentiellement être déployée sur n'importe quel service supportant ces images OCI, comme un futur cluster Kubernetes.

Nous avons pu observer plusieurs comportements via l'utilisation de ces services : soit ils sont complètement adoptés et conviennent parfaitement aux besoins de nos clients, soit ils manquent de customisation et ceux-ci sont naturellement poussés vers l'utilisation de Kubernetes. Ce n’est plus une problématique aujourd’hui, mais il y a de cela 1 an, Cloud Run ne supportait pas le fait que le CPU soit “always allocated” et nous ne pouvions pas l’utiliser pour des applications ayant des processus en background.

Ces services sont devenus incontournables et nous les recommandons. Si l'utilisation d'un Cloud Provider n'est pas une option, il est toujours possible de construire votre propre CaaS en utilisant des technologies open source comme Knative.

Kubernetes

Kubernetes est l’actuel standard de la communauté pour des déploiements scalables d’applications conteneurisées.

Déployer une application en production implique de résoudre un certain nombre de défis technologiques, comme par exemple :

Assurer la reproductibilité des déploiements
Pouvoir adresser plusieurs réplicas de son application pour en assurer la résilience
Pouvoir adapter la capacité de traitement en fonction de la charge
Pouvoir incorporer à son déploiement des composants externes à moindre coût (i.e. sans avoir tout une série de scripts de déploiement supplémentaires à maintenir)

Avant Kubernetes et l’ère des conteneurs, on aurait utilisé une armée de scripts bash ou python, des playbooks Ansible ou encore un setup pour assurer le déploiement de l’application. Tout ça est aujourd’hui remplacé élégamment par une pipeline de CI, pour produire des images de conteneurs et des Charts Helm pour le déploiement.

On aurait également utilisé un système de VIP à mettre en place à part pour le load balancing. C’est aujourd’hui pris en charge :

Nativement par Kubernetes pour le load balancing interne du cluster
Via des intégrations aux Cloud Providers pour le load balancing externe
Via des extensions comme MetalLB sur une infra on-premise

La gestion de la capacité de traitement ainsi que l’installation d’outils externes est également facilitée via l’utilisation de son interface en YAML et des différents outils qui en ont émergé comme Kustomize ou Helm.

Il faut tout de même tenir compte de la maintenance de Kubernetes, qui induit une certaine charge, même lorsqu’on utilise le service managé d’un Cloud Provider. Un CaaS sera plus léger à maintenir, mais moins extensible. Il n’est en effet souvent pas possible d’installer des contrôleurs additionnels sur les CaaS.

Nous recommandons donc Kubernetes à tous nos clients qui ont la capacité de le maintenir et cherchent à mettre en place une plateforme extensible sur laquelle déployer facilement des applications à grande échelle.

PCA

Un plan de continuité d'activité, ou PCA, est le pattern d’architecture cloud le plus pragmatique pour assurer une forte résilience, il exploite les forces des clouds providers.

Un plan de continuité d’activité consiste à garantir la disponibilité d’une infrastructure en cas de désastre et est essentiel pour toute infrastructure qui veut maintenir un niveau de disponibilité élevé et proposer une expérience utilisateur sans interruption. Avant de concevoir une architecture et d’envisager de mettre en place un PCA, il faut estimer un Recovery Time Objective (RTO) et un Recovery Point Objective (RPO) pour son application.

L'objectif de temps de récupération (RTO) est le délai maximal acceptable entre l'interruption de service et la restauration du service.
L'objectif de point de récupération (RPO) est la durée maximale acceptable depuis le dernier point de récupération de données

Les Clouds Providers publics proposent plusieurs façons de garantir un PCA. Par exemple :

Les régions AWS sont localisées dans des pays. Il peut y en avoir plusieurs par pays, et elles sont sous-divisées en zones de disponibilités.
Des zones de disponibilités regroupent plusieurs centres de données. Ces centres de données hébergent les ressources du Cloud Provider.

En fonction des objectifs, l’application sera hébergée sur :

Une zone de disponibilité au sein d’une région
Plusieurs zones de disponibilité au sein d’une région, ce qui est l’approche la plus commune
Plusieurs zones de disponibilité au sein de plusieurs régions. Cela garantit la plus haute disponibilité, mais c’est aussi la plus dure à maintenir, car il faut garantir la cohérence des données entre plusieurs régions tout en gardant un temps de réponse bas.

Chez Padok, nous recommandons la mise en place de PCA et non de PRA, plan de reprise d’activité, suite à un désastre. En effet, ceux-ci sont coûteux à tester, il en découle rarement des leviers activables et nous sommes convaincus qu’il est surtout primordial qu’ils soient effectués à l’échelle du Cloud Provider.

KEDA

Open source, KEDA permet de scaler les ressources déployées dans Kubernetes en se basant sur des évènements externes.

S’assurer que les infrastructures puissent supporter la charge rapidement est un de nos objectifs principaux en tant que DevOps. Il est cependant difficile de scaler nos ressources en anticipation car nous nous appuyons généralement sur la consommation de CPU et de RAM. C’est là que KEDA (Kubernetes Event-Driven Autoscaling) facilite grandement cette tâche.

KEDA est un composant qui étend les fonctionnalités d'autoscaling de Kubernetes en se basant sur les événements.

Il permet de surveiller :

les files d'attentes
les flux de données
les systèmes de messagerie

La surveillance de ceux-ci permet de déclencher le scaling des applications en fonction de la charge événementielle de nombreux services tels que : Kafka, RabbitMQ, Azure Service Bus, AWS SQS, PubSub. Il est donc possible de commencer le scaling d’une ressource lorsqu’un grand nombre de messages arrive en amont d’un flux par exemple, ou même de scaler à 0 lorsqu’aucun message n’est présent.

KEDA est un excellent choix pour l'autoscaling événementiel. Il existe des alternatives telles que les solutions propriétaires offertes par les Cloud Providers comme AWS Lambda, Azure Functions ou Google Cloud Functions. Toutefois, KEDA se distingue par son approche open source et sa compatibilité avec Kubernetes.

Nous vous proposons donc un outil puissant et flexible pour la gestion de l'autoscaling événementiel dans Kubernetes. Nous vous recommandons de l’utiliser si vous cherchez une solution pour gérer efficacement l'évolutivité de vos applications conteneurisées basée sur les événements.

Synthetic Monitoring

Technique de surveillance de vos applications qui consiste à simuler un utilisateur réel avec des robots pour détecter des dysfonctionnements.

Le Synthetics Monitoring est une technique de surveillance de vos applications qui consiste à simuler un utilisateur réel avec des robots pour détecter des dysfonctionnements. Elle s’oppose à la technique classique, mais révolue, qui consistait à vérifier la disponibilité de l’infrastructure. Cette méthode ne fait plus sens dans des architectures cloud fortement distribuées, où l’auto healing est présent by design.

Généralement, on s’attachera à tester en priorité les chemins critiques d’une application. C’est le parcours utilisateur qui représente la plus forte valeur business. Par exemple, pour un site de vente en ligne, il s’agira du tunnel d’achat :

recherche d’un produit
ajout au panier
paiement

Ce test permettra de s’assurer que vos clients peuvent réellement acheter sur votre site. Il a aussi le mérite de valider que vos services backend, comme la caasrecherche, le stockage des sessions, etc sont tous opérationnels au moment du test.

D’un simple appel à une API backend au parcours à plusieurs étapes, de nombreux outils vous permettent de mettre en place du Synthetics Monitoring. Que ce soit des outils payants comme Datadog, NewRelic ou DynaTrace ou bien des outils open source comme Blackbox Exporter (Prometheus Stack), le choix est vaste. Veuillez toutefois noter qu’il est préférable d’exécuter ces scénarios depuis l’extérieur de l’infrastructure afin de vous positionner comme un “vrai” client à votre application et ainsi détecter aussi des dysfonctionnements (coupure, latence) réseau.

Attention cependant aux dépendances externes : elles peuvent générer des alertes sans que vous puissiez agir. Néanmoins, il apparaît important d’être au courant si l’un de vos fournisseurs est indisponible. Dans ce cas-là, on vous recommandera d’avoir des procédures spécifiques pour traiter ces évènements et d’implémenter dans vos applications un système de circuit breaker. Votre application se mettra en maintenance automatiquement et vous pourrez avoir un traitement spécifique lors de vos astreintes. On peut imaginer n’être alerté que si le service est inaccessible plus de 1 heure.

Le monitoring de vos applications doit être un standard dans votre cycle de développement. Comme la sécurité ou la performance, il faut une étape consacrée à la mise en place d’une surveillance du bon fonctionnement de vos services. Ne négligez pas non plus la maintenance et l’évolution. Vous ne devriez jamais passer en production sans avoir des sondes en place pour être avertie en cas de dysfonctionnement. Il n’y a rien de plus frustrant que d’être prévenu par vos clients sans vous en être rendu compte avant.

On vous recommandera d’ailleurs une approche “automatique” en créant des sondes pour chaque application déployées. C’est ce que nous faisons sur nos projets avec la flexibilité de l’API Kubernetes et des outils comme Blackbox exporter ou Datadog via Crossplane. Ainsi, aucun de nos projets ne passe en production sans avoir le monitoring adéquat validant que le service est bien rendu.

Le Synthetic Monitoring est indispensable pour vous assurer que votre application est opérationnelle. Vous ne devriez pas envisager une mise en production sans ce type de surveillance.

Trial

Karpenter

Karpenter est un node autoscaler pour Kubernetes. Il se différencie de ses pairs en proposant de créer sa configuration d'autoscaling au sein même du cluster.

Dans le monde du node autoscaling pour Kubernetes, deux solutions majeures existent aujourd’hui :

Une technologie gérée par son Cloud Provider, notamment GKE et son mode Autopilot
Kubernetes Cluster Autoscaler (KCA), que l’on va déployer dans son cluster, encore très utilisé pour AWS EKS

AWS est le dernier grand Cloud Provider ne fournissant pas de fonctionnalité d’autoscaling managé. Leur réponse à ce manque a été le développement de Karpenter.

Contrairement à KCA, Karpenter ne va pas se reposer sur le Cloud Provider pour la création de node groups, il va la gérer lui-même au moyen de CRDs. Associé à un outil de GitOps tel qu’ArgoCD, Karpenter apporte une flexibilité à la configuration de ses node groups, absente jusque-là.

Dès lors qu’au moins un pod se retrouve dans l’état Pending sans que le scheduler Kubernetes ne puisse l’affecter à un node, Karpenter va provisionner la juste capacité capable d’accueillir cette charge de travail. Cela peut se traduire par un ou plusieurs nodes aux caractéristiques suffisantes.

En plus de cela, Karpenter embarque des fonctionnalités très intéressantes :

le TTL pour les nodes : permet de renouveler les nodes de son infrastructure, notamment pour les mettre à jour en continu
la consolidation : Karpenter calcule régulièrement les conséquences de la suppression d’un node, qui est engagée si la taille du cluster s’en retrouve réduite
le drift-detection : le marquage dynamique de nodes dont la configuration n’est plus alignée avec son provisioner associé

Karpenter se présente donc aujourd’hui comme une alternative très intéressante à KCA lorsque l’on utilise AWS EKS. Notons que Karpenter devrait être compatible avec d’autres Cloud Providers dans le futur. Cependant, le développement de l’outil est très rapide et il est jeune à l’échelle de ce qui existe déjà. Nous recommandons donc de se documenter rigoureusement avant de l’implémenter en production.

k6 est un framework de load testing kube, natif et extensible.

k6 est un framework extensible de load testing développé par Grafana Labs. Il permet de tester la résilience de votre infrastructure face à des pics de charge sur des parcours critiques.

k6 utilise Javascript comme langage de scripting. Il est donc facile pour les développeurs d'être owners des scripts à lancer contre leur application. k6 a lui été développé en golang : il n’y a donc aucune inquiétude à avoir sur la performance.

k6 utilise par défaut InfluxDB pour enregistrer les métriques, mais il est possible de les envoyer dans un Prometheus. Ceci est rendu possible grâce à xk6, le système d’extension de l’outil. C’est ce dernier qui nous a conquis chez Padok. Vous pouvez ajouter facilement des fonctionnalités : module MQTT pour l’IoT, RabbitMQ, event-driven, browser tests et bien d’autres !

k6 se dote aussi d’un opérateur Kubernetes, encore en phase expérimentale et qui n’embarque pas par défaut de système de master/worker. Chaque réplica de k6 envoie les métriques brutes dans votre système de stockage sans ajouter aucune logique. Cela nous a posé des problèmes en envoyant des métriques dans Prometheus. Et ce sera à vous de maîtriser Grafana afin d’en faire ressortir les données qui vous intéressent. De plus, pour utiliser des extensions avec l'opérateur, il faudra construire vos images de runners les intégrant.

Cependant, pour de simples tests HTTP, lancer k6 en local ou depuis une VM sera suffisant pour des tests sporadiques. Il existe aussi une GitHub Actions pour l'intégrer directement dans vos pipelines de CI. C’est aussi possible en utilisant l'opérateur, mais cela nécessitera du développement supplémentaire pour intégrer son utilisation.

k6 nous semble aujourd’hui être la solution de tests de charge la plus prometteuse pour toutes vos infrastructures cloud et Kubernetes. Mais l’utiliser à sa pleine puissance nécessite un peu de travail.

Locust

Locust est un outil permettant de mesurer la performance de votre application web.

Locust fait partie de la famille des outils dit de "Load testing", il permet de décrire des scénarios d'usage de vos applications web et ensuite de les faire jouer par de nombreux utilisateurs virtuels.

Réaliser ces tests permet de :

Gagner en confiance sur l'évolution de la performance de votre application
Vérifier que votre infrastructure actuelle est suffisante pour tenir une charge plus importante
Identifier les différents bottlenecks de votre application

La force de Locust réside dans sa simplicité d'utilisation mais également de mise à l'échelle avec son modèle d'agent central et de workers qui permettent d'atteindre de manière quasi illimité le seuil de performance que vous voulez vérifier.

Les scénarios sont très simples à écrire et si vous êtes familier avec Python vous n'aurez que très peu de difficultés à écrire vos premiers tests.

Locust vous mettra également entre les mains une UI présentant des dashboards de performance en temps réel ainsi qu’un contrôle sur les tests en cours (Arrêt/Marche).

Il existe de nombreux outils de test de charges sur le marché mais Locust est aujourd'hui l'un des plus simples et nous vous conseillons de l'essayer au même titre que k6.

Assess

Nomad

Nomad est un orchestrateur de tâches.

L'orchestrateur de tâches est devenu l'un des piliers de l'infrastructure moderne. Kubernetes étant le plus connu, on peut rapidement se persuader que c'est la seule alternative viable et qu'il faut l'adopter par défaut.

C'est un choix que de nombreuses entreprises font car la gestion de conteneurs avec Kubernetes est très mature. Cependant, l'infrastructure d'une grande part des entreprises est hétérogène (conteneurs, VM, webservices…) et serait très coûteuse à conteneuriser. Elles peuvent alors se tourner vers Nomad.

Nomad est un orchestrateur de tâches généraliste créé par Hashicorp. En plus de gérer des conteneurs, Nomad est doté de drivers supportant des tâches sous la forme de machines virtuelles, de simples scripts, d'applications Java et d’autres. Se présentant comme un simple binaire, Nomad est léger et simple d'installation.

Adossé à Consul (solution de Service Mesh d'HashiCorp), il est possible de complètement fédérer ses applications, peu importe la forme qu'elles ont. Cela procure à Nomad une bonne extensibilité et une capacité d'adaptation à l'existant que n'a pas Kubernetes. La migration vers un orchestrateur est donc beaucoup moins coûteuse que s'il fallait conteneuriser toutes ses applications.

Nos réserves portent principalement sur son manque d'intégration avec les Cloud Providers existants ainsi que son adoption moins grande par la communauté par rapport à Kubernetes. Nous considérons cependant que c'est un outil qu'il faut considérer si vous avez une infrastructure on-premise volumineuse ou que vos ressources à allouer à l'orchestration de vos tâches sont limitées.

Database Operators

Opérateurs Kubernetes facilitant le déploiement, la maintenance et la sauvegarde de bases de données.

Déployer une base de données dans Kubernetes en utilisant les moyens classiques (généralement, un StatefulSet associé à un volume) pose rapidement des problèmes qui ont été adressés par les services managés :

Comment assurer une sauvegarde régulière des données ?
Comment gérer le scaling en cas d'augmentation de la charge ?
Comment s'assurer que les mises à jour se déroulent bien ?

Sans outillage intégré, toutes ces problématiques doivent être résolues par des programmes externes. La maintenance devient coûteuse et très propice à l'erreur. Associée à l'impact d'un incident sur ce type de service, le parti pris est souvent celui du "set it up and forget about it", ce qui amène lui aussi son lot de problèmes.

Les opérateurs Kubernetes pour les bases de données répondent à ce genre de problématiques. Comme tout opérateur, ils vont généralement se présenter sous la forme de déploiement associé à des CRDs. Les CRDs, dans ce cas, seront généralement des objets "Cluster", "Database", "Backup", "User" etc.

Ils rendent la configuration d'une base de donnée déclarative, contrairement aux scripts qui sont généralement utilisés pour les initialiser. Ils vont aussi permettre d'automatiser de nombreuses opérations telles que les mises à jour, la programmation de sauvegardes, la restauration de données à partir de sauvegardes, le pooling de connexions ou le monitoring.

Chez Padok, nous avons déjà utilisé l'opérateur MySQL créé par Bitpoke afin de facilement créer des environnements à la volée dans Kubernetes. L'opérateur avait pour fonction de créer une base de données temporaire à partir d'un backup, pouvant servir à l'exécution de tests d'intégration. La performance de cette solution est intéressante car la BDD démarre rapidement contrairement à un service managé, et elle est au plus proche de l'application qui l'utilise.

Nous recommandons l'utilisation d'un opérateur de BDD dans ce cas d'utilisation. Pour une utilisation en production, assurez-vous de la maturité de l'opérateur et réalisez une estimation de coûts (un service managé peut devenir très cher par rapport à un bon opérateur). Si vous n'avez pas de contrainte particulière, nous recommandons toujours l'utilisation d'un service managé par votre Cloud provider.

Hold

Gatling

Gatling est un système de load testing, avec une version open source et une version entreprise payante.

C'est un système d’injection de tests de charge à la fois clé en main et customisable via l’implémentation de scénarios en langage scala (en langage scala, java, kotlin ou no-code).

Un des avantages de Gatling vient de son interface qui vous présentera nativement la liste des jobs d’injection réalisés ou en cours, ainsi que les métriques clés qui vous permettront d’analyser les résultats, comme par exemple :

La consommation RAM et CPU du client d’injection afin de s’assurer que les tests sont représentatifs
Le temps de réponse du serveur
Les calculs de percentils

La mise en place de Gatling Enterprise via la marketplace AWS est aisée. La version open source s'installe aussi facilement sur n'importe quelle machine virtuelle.

Gatling a une version open source, largement utilisée, cependant le setup pour faire des tests clusterisés reste payant et le montant peut être élevé.

C’est pour ces deux raisons que notre préférence va aujourd’hui vers k6, un outil moins mature mais totalement open source et qui s’intègre mieux aux stacks techno de nos clients.