Operable

Description quadran Operable

Adopt

12Datadog

Datadog est SaaS payant d’observabilité des infrastructures Cloud. Il surveille la performance et la santé des applications, permettant de détecter et résoudre rapidement les problèmes.

Leader du marché* dans le domaine de l’observabilité, Datadog propose un catalogue complet de solutions d’observabilité, de monitoring et d’alerting. Il facilite la détection et la résolution rapide des problèmes, améliore la collaboration inter-équipes et optimise l'utilisation des ressources pour les entreprises de toutes tailles.

Datadog offre une solution de monitoring complète en intégrant à la fois les approches whitebox et blackbox :

En whitebox, Datadog permet une surveillance granulaire des métriques internes des applications et des infrastructures, facilitant la détection précoce des anomalies et l'optimisation des performances.
En blackbox, Datadog simule les interactions des utilisateurs finaux pour identifier les problèmes de disponibilité et de performance externe, garantissant ainsi une expérience utilisateur optimale.

Cette double approche assure une couverture exhaustive, permettant de détecter et de résoudre les problèmes à tous les niveaux de votre stack technologique.

Nous adoptons Datadog pour sa facilité d’utilisation et son provider Terraform qui nous permet d’automatiser notre gestion de l’alerting par client et de la maintenir facilement, et enfin pour son offre de monitoring qui s'adapte à toutes les infrastructures et technologies applicatives.

Datadog est un outil simple d’utilisation avec une interface intuitive, offrant de nombreuses intégrations permettant de s’adapter aux différentes infrastructures. Si toutefois l’outil semble trop cher, vous pouvez vous tourner vers des solutions d’observabilité open source telles que Prometheus ou la stack ELK, qui nécessitent néanmoins plus de configuration et de maintenance.

*source: Gartner

13Grafana

Grafana est une plateforme de visualisation open source pour tous vos environnements cloud.

Grafana est un outil de visualisation open source créé par l’entreprise éponyme, Grafana Labs. Il permet aux utilisateurs de créer des dashboards dynamiques et personnalisables pour surveiller et analyser les metrics liées à votre infrastructure. Grafana prend en charge une large gamme de sources de données, permettant aux utilisateurs de centraliser et de visualiser leurs données à partir de divers systèmes. Voici quelques-unes des sources de données les plus populaires prises en charge par Grafana :

Prometheus : Pour la surveillance des systèmes et des services.
Elasticsearch : Pour la recherche et l'analyse de journaux.
InfluxDB : Pour le stockage et l'analyse de séries temporelles.
Loki : Pour la surveillance des journaux avec une approche scalée.
Base de données (MySQL, Postgres, TimescaleDB, ...)
Cloud provider (AWS, Cloudwatch, GCP Monitoring, Azure Monitoring, ...)

Son interface utilisateur intuitive vous permet ensuite de regrouper les différentes données sous forme de graphiques en temps réel, jauges, diagrammes en barre pour ne citer que ceux-là.

Grafana est un incontournable du monitoring pour vos clusters Kubernetes, très facile à installer et configurer grâce à son chart Helm. Si vous ne voulez pas avoir la responsabilité de gérer votre outil de visualisation, pas de soucis, il existe une offre SaaS Grafana Cloud.

Avec l’essor des architectures en microservices et de l’utilisation du cloud pour créer des environnements complets et complexes, nous recommandons Grafana à tous nos clients qui veulent une alternative open source à Datadog, que ce soit pour les équipes opérationnelles ou les équipes de développement.

14KPIs d'infrastucture (RED Method)

La méthode RED optimise la surveillance des KPIs de l’infrastructure pour ne conserver que les plus critiques afin d'améliorer les performances.

La méthode RED (Rate, Errors, Duration) est une approche pour surveiller et améliorer les performances des infrastructures. Elle repose sur trois indicateurs clés de performance (KPIs) essentiels pour évaluer l’efficacité des systèmes : le taux (Rate), les erreurs (Errors) et la durée (Duration).

Le taux mesure le nombre de requêtes ou d'opérations traitées par le système sur une période donnée. Ce KPI est crucial pour comprendre la charge de travail que le système peut supporter et pour identifier les périodes de pic d’activité. Une analyse de ce taux permet de prévoir les besoins en ressources et d’ajuster la capacité en conséquence. Les erreurs quantifient le nombre de requêtes qui échouent ou de problèmes rencontrés par le système. Suivre ce KPI est vital pour maintenir la fiabilité et la stabilité des infrastructures. Une augmentation des erreurs peut indiquer des failles dans le système, des problèmes de configuration ou des défaillances matérielles. Identifier et résoudre rapidement ces erreurs permet de minimiser les interruptions de service et d’améliorer l’expérience utilisateur.

La durée mesure le temps moyen nécessaire pour traiter une requête ou une opération. Ce KPI est essentiel pour évaluer la performance et l’efficacité du système. Un temps de traitement plus long peut signaler des goulets d'étranglement ou des inefficacités dans les processus. En optimisant la durée, on peut réduire la latence et améliorer la réactivité des applications, ce qui est crucial pour les utilisateurs finaux.

En combinant ces trois indicateurs, la méthode RED offre une vue d’ensemble des performances des infrastructures, permettant aux équipes techniques de détecter rapidement les problèmes, de planifier les améliorations et d’assurer une performance optimale : un outil indispensable pour une gestion proactive.

15Kustomize

Kustomize simplifie la gestion des déploiements complexes dans Kubernetes.

Kustomize permet de gérer les configurations des ressources pour Kubernetes via des fichiers YAML, avec une syntaxe facile à utiliser. Il permet également de gérer des configurations complexes pour des applications multi-environnements en appliquant des configurations en série.

En effet, Kustomize applique des patchs et overlays sur une configuration de base. Cela permet de gérer des configurations complexes plus simplement qu’avec Helm où il faut redéfinir un fichier de values à chaque fois. Le tout en gardant votre code aussi DRY que possible !

De plus, Kustomize génère automatiquement de nouveaux secrets Kubernetes chaque fois que vous modifiez un champ de données (data field) dans le fichier de configuration. Cette fonctionnalité permet de maintenir la sécurité des secrets tout en simplifiant vos rollbacks.

Cependant, Kustomize est plus difficile à appréhender pour des personnes n'étant pas familières avec les ressources Kubernetes et leur déclaration en YAML. C’est aussi un outil moins flexible que Helm en termes de personnalisation : il n’est pas possible d’intégrer de logique via du templating par exemple.

Kustomize est donc un outil puissant pour la gestion des configurations de déploiement dans Kubernetes, avec une syntaxe simple qui complète parfaitement Helm.

16OpenTelemetry

OpenTelemetry et son collecteur facilitent la collection de métriques, logs et traces au moyen de standards et de configuration unifiée.

À l'ère du Cloud et de Kubernetes, les infrastructures qui font vivre les services que l'on utilise aujourd'hui sont bien souvent distribuées. Les bénéfices en termes de scalabilité et de résilience ne sont plus à démontrer, mais cela peut nuire à la compréhension globale du système.

Il est donc indispensable de mettre en place un bon niveau d'observabilité.
Il existe 3 grands types de données :

Les métriques, pour créer des dashboards présentant les données numériques générées par l'infrastructure ;
Les logs, pour analyser le comportement des composants qui traitent l'information ;
Les traces, pour pouvoir suivre le parcours des requêtes au travers de l'infrastructure et ses composants.

OpenTelemetry a été créé pour faciliter la mise en place de cette observabilité de manière unifiée grâce à ses librairies et outils. L'intérêt d'OpenTelemetry réside dans la génération, la collection et l’export de données d'observabilité vers n'importe quel backend tel que Jaeger, Datadog, NewRelic ou encore Prometheus.

OpenTelemetry propose notamment des SDK dans les langages de programmation les plus utilisés. Cela permet aux développeurs de faire remonter des données qui peuvent être très utiles au debug. Cependant, ce qui nous intéresse ici est le collecteur OpenTelemetry.

Le collecteur se déploie sous forme de process ou container (sur une VM, ou dans Kubernetes) et fait le pont entre l'infrastructure et les backends d'observabilité. Pour chaque type de donnée, il est possible de définir source(s), transformation(s) et destination(s) et de les combiner dans un système intuitif de pipelines.

Il est intéressant de noter que la documentation de certains composants peut être cachée dans des repositories GitHub qui ne sont pas faciles à trouver. Cependant, la facilité d'opération et la forte activité autour du développement d'OpenTelemetry nous a convaincus de le placer dans le ring Adopt.

17Prometheus Operator

Prometheus Operator déploie et gère la stack technique autour de Prometheus afin de monitorer un cluster Kubernetes.

Prometheus est l’outil de référence pour la métrologie sur les architectures Kubernetes. Le déploiement et la gestion sont particulièrement simplifiés grâce à Prometheus Operator tout en ajoutant d’autres composants annexes, mais non moins nécessaires, qui permettent d’améliorer l’opérabilité de votre plateforme :

alerting avec AlertManager
monitoring HTTP avec Blackbox Exporter
visualisation des métriques avec Grafana

L’installation de Prometheus dans votre cluster Kubernetes se fait en une seule commande. Il est possible d’avoir accès à toutes les métriques de votre cluster en quelques minutes et de commencer vos premières analyses grâce aux tableaux de bord génériques installés dans Grafana. L’opérateur Prometheus permet de déclarer dans l’API Kubernetes votre configuration Prometheus via les CRDs (Custom Resource Definition).

Les CRDs vous offrent la possibilité d’automatiser le déploiement du monitoring, en ajoutant la configuration Prometheus dans vos charts Helm. Ainsi, vos applications pourront être monitorées par défaut, sans avoir besoin d’éditer la configuration de Prometheus.

Toutefois, le problème majeur de Prometheus n’est pas réglé par l’opérateur : proposer une vue consolidée et centralisée dans des architectures multi-environnements et multi-clusters. Vous devrez alors déployer des composants qui permettent de faire le lien entre les différents déploiements : un Grafana central et des solutions comme Thanos pour augmenter la rétention des données.

Même si d’autres solutions existent, comme Datadog (payant), Prometheus reste le standard de facto de la communauté pour Kubernetes et demeure un bon choix pour opérer vos clusters. L’opérateur apporte un atout supplémentaire : il vous permet d’industrialiser le monitoring.

18Renovate

Renovate permet d’automatiser la mise à jour (Patch Management) des dépendances externes (librairies) de l’infrastructure et des applications.

Le Patch Management est un enjeu crucial pour la sécurité d'une plateforme. Nos infrastructures et applications, utilisant des composants externes souvent open source, nécessitent des mises à jour régulières pour corriger failles de sécurité et bugs. Avec le rythme rapide des mises à jour et l'augmentation des dépendances, tout maintenir à jour est un défi.

Renovate est un outil open source de gestion de dépendances qui automatise la mise à jour des packages dans vos projets. Il analyse vos fichiers de configuration de dépendances (tels que package.json, pom.xml ou build.gradle) et génère automatiquement des pull requests pour les mises à jour de packages nécessaires. Renovate est compatible avec une variété de gestionnaires de packages, notamment npm, yarn, pip, Maven et NuGet, ce qui le rend facilement adaptable aux différents langages de programmation. Il permet aussi d'analyser les dépendances de votre infrastructure en supportant les chart Helm, les images Docker et les modules Terraform. Vous pouvez l'utiliser avec les Git Provider majeurs.

Hautement configurable, il s’adapte parfaitement aux workflows de développement de nos projets. Il s’intègre via des tâches de CI ou en tant que cronjob dans un cluster Kubernetes afin d’optimiser les traitements avec du cache dans Redis. Ce sera un mode de déploiement qui permettra de scale plus facilement en déployant plusieurs “instances” de Renovate (cronjob Kube) pour répartir la charge et adapter son fonctionnement. Avec une exécution journalière et le merge automatique des changements (quand la CI est valide), nous automatisons une partie de la correction des failles de sécurité en appliquant automatiquement les patchs.

Renovate permet de suivre les évolutions de nos dépendances à prendre en compte pour les maintenir à jour (via la liste des Merge Request/Pull Request ouvertes).

Renovate nous permet de réduire le toil du Patch Management et de dégager du temps pour travailler sur des améliorations qui apporteront plus de valeur au business de nos clients.

19Terraform

Aujourd’hui Terraform est l’outil d’IaC qui domine le marché, même si Opentofu n’est pas loin. Il permet de provisionner et de manager des ressources sur tous les Cloud Providers.

Nous avons créé des centaines d'infrastructures sur plusieurs Clouds Providers et nous avons utilisé à chaque fois Terraform. Un outil d’IaC
est essentiel pour se lancer dans le cloud, car il facilite la collaboration, mais aussi l’opérabilité d’une infrastructure.

Terraform rayonne par différentes fonctionnalités qu’il propose :

L’utilisation de modules qui permettent de définir des ensembles de ressources qui répondent à un besoin précis et de pouvoir les réutiliser facilement.
Le state Terraform qui permet de suivre le cycle de vie de chaque ressource.
La compatibilité avec plusieurs clouds et systèmes grâce aux providers. Par ex : AWS, OVH ou encore Github.

Nous savons que des outils IaC sont proposés par les clouds providers comme : CDK AWS, cloudformation ou même ARM pour Azure. Mais leur vendor lock-in et leur manque d'interopérabilité nous ont fait pencher pour Terraform.

Même s’il est le leader dans l’IaC pour gérer une infrastructure, il est nécessaire d’avoir un cadre pour la code base. Nous avons convergé chez Theodo Cloud sur un pattern WYSIWYG (What You See Is What You Get) qui aide à l’uniformisation du code et la collaboration*.

Les points à retenir sont :

Organiser les states Terraform par rapport à un besoin métier.
Créer des modules qui répondent à un besoin complexe ou reproductible.
Ne pas hésiter à factoriser le code quand l’infrastructure évolue.

Terraform est l’outil de référence aujourd'hui pour construire et maintenir une infrastructure dans le cloud. Des outils tels que Terragrunt améliorent encore davantage sa capacité à gérer l'infrastructure at scale en proposant des fonctionnalités permettant d'éviter la redondance de code, appelée DRY (Don't Repeat Yourself).

Il ne faut pas négliger les outils de qualité syntaxique et de maintenabilité : terraform fmt, tfllint, tfautomv ou terraform-docs et guacamole.

* https://padok-team.github.io/docs-terraform-guidelines

20Terragrunt

Terragrunt est un outil à combiner avec Terraform qui vous aide à améliorer la maintenabilité et la scalabilité de vos codebases.

Terraform est le standard actuel de la communauté pour le déploiement as code de ressources cloud. Il dispose notamment de librairies pour la quasi- totalité des ressources des grands Cloud Providers. Cependant, des limitations qui lui sont propres pénalisent les équipes pour gérer une infrastructure à plusieurs, ou pour gérer de grosses infrastructures. Dans ce genre de cas, il est souvent nécessaire de découper le déploiement de Terraform en plusieurs modules (parfois appelés layers), afin de les simplifier ou d’éviter la concurrence lors de la modification d'un même state Terraform.

Or, ceci est vite très difficile à gérer car il devient nécessaire :

D’utiliser des remote states pour partager les outputs entre states;
De dupliquer ou sur-templatiser les configurations de backends qui ne sont pas nativement configurable dans Terraform;
De gérer les variables communes ou spécifiques des environnements via des fichiers et des liens symboliques.

Terragrunt vient se placer au-dessus, afin de créer et chapeauter des states Terraform autogénérés. On peut ainsi profiter des fonctionnalités accrues de Terragrunt pour lier les apply (layers) entre eux. Terragrunt permet donc d’avoir un meilleur lien entre layers, tout en se reposant ensuite sur les capacités reconnues de Terraform pour le déploiement.

Terragrunt utilise le même langage que Terraform, l'HashiCorp Configuration Language (HCL), avec des fonctionnalités supplémentaires pour l’utilisation à grande échelle. Cela facilite la formation des équipes et limite la sensation d’avoir un nouvel outil à maîtriser. L'utilisation de Terragrunt pour déployer des infrastructures en production nous a inspiré l'écriture de bonnes pratiques, dont le Context Pattern*.

D’autres outils essaient aujourd’hui de remplir ce besoin, mais Terragrunt a notre préférence car il parvient au résultat sans trop modifier l'utilisation de Terraform et en ajoutant des fonctionnalités puissantes.

*https://padok-team.Github.io/docs-terraform-guidelines/terragrunt/context_pattern.html

21Terraspace

Terraspace est un framework opinionné, orienté DRY et Layering pour démarrer rapidement un projet Terraform avec de bonnes pratiques et une structure recommandée.

Terraspace est un framework DRY (Don't Repeat Yourself) conçu pour étendre les capacités de Terraform, l'outil d'IaC incontournable. L'un des principaux avantages de Terraspace est sa capacité à simplifier et à organiser le déploiement de ressources cloud à grande échelle. Alors que Terraform est puissant, il présente certaines limitations lorsqu'il s'agit de gérer de grandes infrastructures ou de travailler en équipe. Terraform nécessite souvent une gestion manuelle des modules et des configurations, ce qui peut entraîner des complexités.

Terraspace adresse ces limitations en fournissant une structure de projet claire et des conventions qui favorisent la réutilisation du code. Il introduit le concept de "stacks" et de "layers" pour regrouper et gérer les ressources liées telles que les environnements ou le cloud multi-région. Il facilite la gestion des secrets grâce à des intégrations avec les gestionnaires de secrets comme ceux d'AWS, Google ou Azure. Il propose également un fichier Terrafile qui permet de gérer simplement les dépendances des modules Terraform de manière centralisée.

Le HashiCorp Configuration Language (HCL) utilisé par Terraform est enrichi par Terraspace. Ce qui permet, de manière tout à fait optionnelle rassurez-vous, l'utilisation de Ruby pour écrire des configurations dynamiques ou tout simplement calculer une valeur ici et là.

En termes de formation des équipes, Terraspace offre une courbe d'apprentissage plus douce grâce à ses générateurs de code et à sa structure de projet cohérente et plutôt, il est vrai, "opinionée". Les développeurs peuvent rapidement monter en compétences et contribuer efficacement. De plus, les conventions DRY de Terraspace réduisent les erreurs et améliorent la maintenabilité du code.

Comme d'autres outils tels que Pulumi, Terraspace offre une bonne flexibilité grâce à son intégration avec un langage de programmation (Ruby), tout en maintenant une simplicité et une organisation structurée pour les grandes équipes.

En termes de formation des équipes, Terraspace offre une courbe d'apprentissage plus douce grâce à ses générateurs de code et à sa structure de projet cohérente et plutôt, il est vrai, "opinionnée". Les développeurs peuvent rapidement monter en compétences et contribuer efficacement. De plus, les conventions DRY de Terraspace réduisent les erreurs et améliorent la maintenabilité du code.

Trial

22Atlantis

Atlantis permet d'automatiser l’utilisation de Terraform via des pull requests. Elle permet d’avoir un workflow qui maintient la cohérence d’une infrastructure définie en IaC.

Atlantis est un outil open source qui permet d’automatiser les contributions à une code base Terraform, en permettant d’exécuter les commandes plan, apply et import directement dans la pull request. De ce fait, on peut voir le retour directement en commentaire. C’est une application qui peut être hébergée n’importe où et qui utilise le système de webhook de Github, Gitlab ou Bitbucket.

Cela permet de résoudre les problématiques de collaboration sur des grandes infrastructures, mais aussi d’avoir un historique des modifications faites.

Des workflows plus complexes permettent d’accélérer d’autant plus la DevX (Developer Experience) :

Autoplanning à chaque nouveau commit ou pull request qui permet rapidement d’avoir un état de l’infrastructure et de valider l’impact des changements apportés
Automerging pour merge la pull request si tous les plans sont fonctionnels

Cependant il reste encore des améliorations pour que cet outil devienne une référence :

Le serveur qui gère Atlantis détient les informations d'identification permettant d'accéder à votre infrastructure. Par conséquent, pour séparer l’accès à plusieurs infrastructures, il faut instancier plusieurs serveurs, ce qui peut rapidement devenir complexe.
Il est fortement limité par son architecture et la scaler n’est pas simple. Si vous avez des besoins d'infrastructure à grande échelle, d'autres solutions plus robustes et matures existent.

Atlantis est un outil prometteur, mais sa gestion complexe de droit et de scalabilité est la raison pour laquelle nous le mettons en ‘Trial”. Des features intéressantes, comme la détection de drift, sont planifiées dans sa roadmap et méritent de le garder dans le radar.

23Burrito

Burrito est un TACoS (Terraform Automation and COllaboration Software). Il gère le code Terraform à grande échelle avec une approche GitOps et orientée Kubernetes.

Avec une connexion au dépôt de code et une interface centralisée, Burrito offre des workflows d'automatisation pour le code IaC et détecte les désynchronisations entre le code et l'existant grâce à des exécutions régulières et automatiques. Il fournit aussi un tableau de bord avec un historique des changements et des informations supplémentaires (coût de l'infrastructure, vulnérabilités, bonnes pratiques...).

Les leaders actuels dans ce domaine sont Spacelift, Terraform Cloud, Scalr et env0. Bien qu'efficaces, ces solutions ont un coût d'entrée conséquent d'environ 200 euros par mois, car leur niveau gratuit ne permet pas de gérer efficacement de grandes infrastructures.

Burrito est une solution open source orientée Kubernetes, développée par Theodo Cloud, visant à être ArgoCD pour Terraform. Burrito fonctionne avec du code Terraform & Terragrunt. Ses fonctionnalités principales sont :

• Visualiser un aperçu des modifications d’une PR/ MR sur GitHub / GitLab ;

• Automatiquement appliquer le code d’infrastructure définissant le dépôt de code comme source de vérité (GitOps) ;

• Visualiser l’état de son code via son interface.

Cette solution, déjà implémentée chez certains de nos clients, facilite et automatise la gestion de code Terraform sur de grandes infrastructures cloud à moindre coût en capitalisant sur un cluster Kubernetes.

Terraform est massivement utilisé pour la gestion d’infrastructure cloud, mais son utilisation à grande échelle pose les problèmes suivants :

Difficulté à proposer un flux efficace de contribution, incluant la revue de code, les tests et les aperçus sur une pull request/merge request.
Complexité à monitorer les modifications effectuées sur chaque layer.
Difficultés à détecter les modifications apportées à l’infrastructure en dehors du code et qui désynchronisent le code avec l'existant.

24Custom Kubernetes Operators

Les opérateurs custom permettent d’automatiser des tâches dans Kubernetes en ajoutant des fonctionnalités à son API.

Kubernetes est très populaire en tant qu'orchestrateur de containers. Mais c’est avant tout une API extensible. Créer vos propres opérateurs permet d’ajouter de nouvelles ressources à l’API de Kubernetes et d’en étendre les fonctionnalités.

En créant votre opérateur, vous allez définir des Custom Resource Definitions (CRDs). Le code de l'opérateur tire parti du pattern de réconciliation de Kubernetes afin de déclencher des événements dans votre cluster à chaque ajout, modification ou suppression d’une instance de CRD. Cela peut aider à automatiser des tâches répétitives (réduire votre toil), et à ajouter des fonctionnalités personnalisées à des applications. Si vous vous servez de Kubernetes, vous utilisez sans doute quotidiennement des opérateurs custom comme cert-manager ou ArgoCD.

Dans le cadre d’un SaaS par exemple, chaque nouveau client nécessite la création d’un nouveau tenant. Un opérateur permet d’automatiser la création de toutes les ressources nécessaires juste en déclarant un nouvel objet dans votre cluster Kubernetes !

Cependant, la création d’un opérateur peut s'avérer compliquée : il faut maîtriser le fonctionnement de Kubernetes ainsi que le cycle de vie et différents edge cases de ce que vous voulez automatiser. Et tester tous les cas d’application n’est pas une mince affaire.

Il est important de noter que vous pouvez écrire vos opérateurs dans n'importe quel langage de programmation : Java, Rust... et même Ansible. De notre côté, nous recommandons l’utilisation de Golang : vous trouverez énormément de ressources pour vous aider et l'opérateur-sdk de Red Hat permet de bootstrapper votre code très efficacement.

La création d'un opérateur peut offrir de nombreux avantages aux équipes DevOps travaillant avec Kubernetes. Cependant, cela peut également être complexe et nécessiter une certaine expertise en programmation et en Kubernetes.

25Excalidraw+

Excalidraw+ est l'édition Premium d'un outil de whiteboarding SaaS qui peut servir à la fois aux techs et aux biz pour partager des schémas.

Excalidraw+ permet d’obtenir en 2 clics une page blanche sans limite (“Scène”) sur laquelle on peut dessiner des formes comme sur un tableau. Les scènes sont regroupées en “Collections” auxquelles on peut donner des droits par équipes, au sein d’un workspace.

Le gros point fort d’Excalidraw+ est dans sa simplicité. Seules des formes élémentaires (ex : rectangles, cercles, flèches, zones de texte) et une capacité de mise en forme restreinte (ex : couleurs, 4 tailles de police) sont possibles dans l’affichage par défaut. L'utilisateur aventurier pourra ajouter des formes provenant de librairies collaboratives, telles que des logos de services Cloud pour illustrer ses schémas d'architecture.

Il en résulte une meilleure collaboration au quotidien, basée sur beaucoup de représentations graphiques et des schémas d’architecture plus à jour, car l’effort à produire pour les maintenir est minimisé.

Excalidraw+ permet de faire tout type de schéma, et de collaborer efficacement à distance avec un support visuel. Si vous avez besoin de faire un schéma et ne savez pas où le faire, il n’y a donc pas à hésiter. Vous pouvez essayer la version gratuite sur excalidraw.com. Chez Theodo Cloud, l'utilisation était majoritairement faite par les équipes tech pour réaliser des schémas d'architecture. Nous avons depuis vu les équipes business se saisir de l'outil pour profiter de ses capacités à tout schématiser facilement.

Comme pour la dernière édition, nous souhaitons signaler les limitations suivantes :

Gestion des droits trop large, par exemple :

Il faut être administrateur pour pouvoir gérer les droits
On ne peut donner des droits sur des dossiers qu’à des équipes
Un utilisateur ne peut être membre que de 6 équipes à la fois
On ne peut pas créer de sous dossiers

Absence de SLA affichés (même si l’application est globalement toujours disponible)
Impossibilité de choisir la localisation du stockage des données

Nous maintenons donc Excalidraw+ en Trial.

26Kubernetes Gateway API

Kubernetes Gateway API gère l’accès aux services Kubernetes depuis l’extérieur du cluster.

Lorsque l’on veut exposer des services Kubernetes à l’extérieur de notre cluster, notre réflexe est d'utiliser les ressources de type Ingress. Nous déployons donc des Ingress Controller comme ceux de Nginx, Traefik ou encore Kong qui vont avoir leurs propres annotations pour diriger le trafic et gérer les Ingress rattachés à eux. Généralement, les développeurs ainsi que les Ops en charge du cluster travaillent sur ces mêmes ressources, créant parfois des perturbations.

Afin de mieux séparer le rôle de chacun pour gérer l’exposition des services applicatifs, un nouveau concept est apparu depuis peu : Kubernetes Gateway API. Il permet aux Ops de mettre en place une gateway globale au niveau du cluster (cross-namespace) et qui a pour point d’entrée un load balancer de type L4 ou L7.

Les développeurs sont alors autonomes pour créer leurs propres HTTPRoutes dans leurs namespaces. À noter que ces ressources apportent nativement plus de fonctionnalités, comme le header-based matching ou le traffic weighting.

Kubernetes Gateway API est encore relativement nouvelle, mais gagne en popularité en raison de sa capacité à simplifier la gestion des routes dans les environnements Kubernetes complexes. Elle offre aussi une meilleure visibilité et un meilleur contrôle sur les gateways, facilitant la détection des erreurs et des problèmes de sécurité.

Chez Theodo Cloud, nous trouvons cette technologie très prometteuse pour les équipes qui veulent simplifier la gestion des routes dans les environnements Kubernetes. À mesure que cette technologie continue de mûrir, elle devrait gagner en popularité et devenir la référence, quitte à remplacer les Ingress.

Assess

27Grafana Mimir

Grafana Mimir implémente une API Prometheus et propose nativement de stocker vos métriques sur un bucket.

Prometheus est le standard open-source pour la collection de métriques d'infrastructure. Son API est implémentée par de nombreux composants que vous avez sûrement déjà déployés dans votre infrastructure.

Certaines contraintes d'un environnement cloud-natif rendent l'utilisation de Prometheus difficile dans certaines situations :

Aucun moyen de stocker ses métriques en dehors d'un disque attaché à Prometheus
Prometheus va récupérer les métriques de vos services, l'inverse étant découragé par ses mainteneurs
Pas de multi-tenancy pour cloisonner vos métriques en fonction de leur émetteur

Grafana Mimir implémente une API Prometheus et intègre tous les éléments ci-dessus.
Accompagné d'une autre technologie telle que le collecteur OpenTelemetry pour récupérer les métriques et les lui envoyer, il est possible de construire un puits centralisé de données pour toute votre infrastructure.

L'architecture de Mimir est distribuée par nature : chaque fonction (ingestion, query, compactor...) dispose de son microservice que l'on peut mettre à l'échelle indépendamment lorsqu'on le déploie sur Kubernetes. Il s'intègre naturellement bien avec Grafana pour créer une stack d'observabilité cohérente et opérant sur les mêmes standards. Il peut être aussi utilisé en tant que réceptacle de métriques pour une architecture Prometheus existante grâce à l'API Remote Write.

Essayez cet outil si les contraintes de Prometheus vous découragent ou pour collecter des métriques dans une infrastructure de type Hub & Spoke. Soyez vigilant sur l'utilisation de votre backend de stockage et à la consommation CPU/RAM de Mimir en cas de gros volume de données. Mettre en place un throttling sur les requêtes entrantes pourra aider.

28Crossplane

Crossplane est un outil d’infrastructure-as-code basé sur Kubernetes. Il permet de créer des ressources Cloud en utilisant des manifestes Kubernetes.

Crossplane est une technologie d’IaC développée par Upbound. Elle permet de déployer des ressources d'infrastructure en utilisant Kubernetes comme gestionnaire d'état. Son principe de fonctionnement est similaire à Config Connector de GCP ou AWS Controllers for Kubernetes.

Crossplane se déploie comme un opérateur dans Kubernetes. Pour l’utiliser afin de gérer son infrastructure, il faut déployer des providers qui packagent des CRDs représentant chaque ressource Cloud (exemple pour AWS : une instance EC2, un VPC, une Lambda...). La plupart des providers sont construits à partir de leurs analogues en Terraform.

Associé à des technologies de GitOps telles qu’ArgoCD, Crossplane peut se transformer #ShiftLeftSecurity en véritable plateforme de self- service Cloud. L’utilisation de YAML et d’attributs Kubernetes pour définir et relier toute son infrastructure est très intuitive. La connaissance minimale nécessaire pour commencer à utiliser Crossplane est nettement moins élevée que Terraform.

En outre, les compositions dans Crossplane (qui sont l'analogue des modules dans Terraform) permettent de mettre à disposition des équipes internes des CRDs personnalisées leur permettant de déployer facilement des parties complexes d’infrastructure (comme un bucket avec toute l’IAM associée).

L’outil s’est nettement amélioré sur l’année passée afin de pallier certains de ses défauts. Les providers ont par exemple été découpés pour limiter la consommation des contrôleurs associés et ne plus déployer de trop nombreuses CRDs. Les grosses fonctionnalités manquantes comme le dry- run et l’import de ressources ont aussi été ajoutées.

Cependant, Crossplane garde quelques défauts :

Modifier un champ immutable d’une ressource n’engendre pas son remplacement, il faut gérer manuellement ce cas de figure.
La dépendance à un cluster Kubernetes pour gérer son infrastructure implique une gestion impeccable de ce dernier.
Les compositions sont très complexes à gérer pour les non-initiés, mais indispensable pour maintenir un niveau de sécurité élevé sur son infrastructure dans un contexte multi-tenant.
De nombreux providers ne sont pas encore matures, ou sont en retard sur leur analogue côté Terraform.

Nous utilisons aujourd’hui Crossplane pour développer des plateformes self- service pour les développeurs, qui leur permettent de déployer de la même façon des ressources dans Kubernetes et dans le Cloud. L’outil continue à grandir et séduit de plus en plus, si bien qu’il pourrait rapidement devenir un concurrent sérieux des autres technologies d’IaC.

29Guacamole

Guacamole scanne votre code Terraform ou Terragrunt pour vous aider à détecter et corriger les mauvaises pratiques et les antipatterns, à la manière d’un linter.

Guacamole est la réponse au constat qu’il n'y a tout simplement pas d’outils de qualité de code relatif à l'IaC.

Beaucoup d’outils existent pour garantir sa sécurité (checkov, tfsec,...), tester le bon fonctionnement (terratest) et même tester le bon formatage du code (terraform fmt).

Mais aucun outil ne vérifie la sanité du code, c'est à dire s'il est compréhensible.

C’est dans cette optique que nous avons développé Guacamole.

Nous avons défini de bonnes pratiques d'IaC sur lesquelles nous nous sommes appuyés. Grâce à celles-ci, nous avons créé un outil capable d'effectuer une série de vérifications sur votre codebase :

• La structure d’un répertoire de code iaC ;

• Le nommage de ressources, variables,

• La configuration de provider Terraform ;

• La configuration des modules et de leur version ;

• La répétition de code.

Cet outil est toujours en cours de développement, mais nous l'utilisons sur nos codebases dans des pipelines de CI. Il nous permet de gagner du temps lors des code reviews ou tout simplement au quotidien en développant avec l’outil installé en pre-commit.

Nous le plaçons en assess, car les vérifications sont très opinionnées et auront du mal à s'inscrire dans des codebases existantes. Si vous commencez aujourd’hui un projet avec de l’IaC, nous recommandons de l’utiliser. Vous pouvez whitelister les vérifications non pertinentes pour vous. N'hésitez pas à remonter un bug ou une question en créant une issue GitHub*.

*https://github.com/padok-team/guacamole

30OpenTofu

OpenTofu est un fork de Terraform qui ajoute plusieurs fonctionnalités intéressantes, mais ne présente pas de fonctionnalité game changer justifiant une migration.

OpenTofu est un fork open source de Terraform lancé suite au changement de sa licence MPL (Mozilla Public License) vers BUSL (Business Source License) par Hashicorp. Ce changement a pour effet de restreindre les conditions d’utilisation de Terraform. Pour certains usages il est nécessaire d’acquérir une licence entreprise pour exploiter Terraform. Notamment dans le cas des outils qui utilisent Terraform et le revendent avec des fonctionnalités supplémentaires.

Même si ce changement de licence n’affecte pas tous les clients, cela est néanmoins un changement de paradigme important pour la suite de Terraform, pour lequel Hashicorp encourage l’utilisation de son outil payant Terraform cloud.

OpenTofu amène des fonctionnalités encore jamais implémentées par Terraform, mais suit aussi les nouvelles apportées par Hashicorp en les reproduisant sans recopier le code (pour éviter les soucis de plagiat).

Les nouvelles fonctionnalités d’OpenTofu sont notamment :

• Le chiffrement end- to-end du state ;
• l’option -concise qui permet de retirer tout le bruit pour un apply ;
• L’utilisation de variables et locals autorisée sur les modules sources et les configurations de backend.

OpenTofu montre une promesse intéressante pour l'avenir, spécifiquement grâce à sa communauté active et à son développement open source.

Cependant, pour les utilisateurs déjà bien ancrés dans l'écosystème Terraform, il manque peut-être une innovation majeure qui les inciterait à abandonner un outil éprouvé au profit d'un autre en plein développement.

En résumé, OpenTofu représente une alternative solide avec des fonctionnalités enrichies, mais sans offre révolutionnaire. Elle reste un choix
à considérer attentivement en fonction des besoins spécifiques et des contraintes de chaque organisation.

31Pulumi

Pulumi est un outil d’IaC qui offre de nombreuses possibilités, mais n’est pas encore le premier choix pour construire son infrastructure en IaC.

Terraform est peut-être le leader sur l’IaC mais Pulumi est un concurrent sérieux avec une approche utilisant des langages comme Python ou GO. Cela permet d’écrire du code conditionnel plus facilement, chose complexe en Terraform.

Pulumi propose 2 fonctionnalités qui se différencient des autres outils IaC :

Les providers natifs qui sont automatiquement mis à jour en fonction de l’API officielle des Clouds Providers.
La gestion de secrets par chiffrement, qui permet d’écrire des données sensibles directement dans le code. En effet, elles sont chiffrées avec des clés venant de providers comme AWS KMS, Hashi Vault ou encore Cloud Kms et déchiffrées au run time juste-à-temps.

Utiliser Pulumi est un bon compromis pour les équipes composées uniquement de développeurs et qui souhaitent rester sur un langage familier. Cela est avantageux, car les process de maintenance et les bonnes pratiques en place permettent de garantir une qualité de code importante.

Pour autant Pulumi vient avec des limitations.
• En fonction du langage, la gestion de dépendances avec par exemple les `node_modules` peut devenir volumineuse avec le scaling de la code base.

• La qualité du code est difficile à tracker. En effet, il n’y a pas de SAST (Checkov ou tfsec) pour Pulumi.

Si vous avez un besoin précis d’utiliser des langages comme le GO ou le Python dans votre stack, démarrer avec Pulumi sera plus simple. Cependant, Pulumi ne résout pas les défis fondamentaux de Terraform concernant la création, l'organisation et la maintenance du code IaC. Si vous utilisez déjà Terraform pour gérer votre infrastructure, ne migrez pas vers Pulumi.

32Terratest

L’infrastructure étant la base de toute application robuste, elle doit être testée ! Terratest répond justement à ce problème en étant l'une des rares librairies de test pour Terraform.

Terratest est la référence pour tester son code Terraform. Codée en Go, cette librairie permet d’écrire des tests unitaires pour Terraform et Terragrunt.

En effet, Terratest permet de déployer une infrastructure et de réaliser des tests sur :

Des appels HTTPS pour voir si des load balancers sont bien fonctionnels
Des requêtes API pour vérifier la réponse de l’api gateway
Des connexions SSH vers des serveurs bastion
Le bon statut d’une ressource
L’application d’un terraform apply sans erreur

Ce sont des tests qui deviennent essentiels pour des infrastructures grandissantes car des erreurs peuvent rapidement apparaître, dues à des changements de version de Terraform ou du provider, et surtout pour garantir la non- régression des fonctionnalités existantes.

Cependant, il existe des freins à son utilisation par les modules open sources maintenus par les Cloud Providers :

• La mécanique de conception du test pour valider le fonctionnement de l'infrastructure n’est pas un geste facile
et documenté

• La disponibilité d’un environnement pour réaliser ces tests engendre des coûts supplémentaires, même si c’est sur une courte période

Nous le positionnons en “Trial” car aujourd'hui ce n’est pas encore un standard de l’industrie. En note, nous l’avons également utilisé pour tester nos packages Helm et nous en sommes satisfaits !