Tech Radar - Secure

Adopt

ArgoCD

ArgoCD est une plateforme de Continuous Delivery (CD) GitOps qui permet le déploiement de manière déclarative d’applications dans des clusters Kubernetes.

ArgoCD est un outil open source de Continuous Delivery (CD) spécifique à Kubernetes. Il permet, suivant une démarche GitOps, de déployer des ressources dans des clusters en utilisant un ou plusieurs repositories Git comme source de vérité. L’utilisation d’ArgoCD est centrée autour d’une Custom Resource appelée Application.

Dans un manifeste Application, il est possible de définir une multitude de paramètres, comme le repository source des ressources déployées, le namespace et le cluster Kubernetes de destination ou encore la stratégie de réconciliation à adopter. ArgoCD supporte plusieurs types de sources pour déployer des ressources dans Kubernetes : charts Helm, applications Kustomize, fichiers Jsonnet ou encore de simples manifestes.

Pour subvenir à des besoins plus avancés, la Custom Resource ApplicationSet et son contrôleur associé permet de générer plusieurs Applications ArgoCD à partir d’un unique manifeste. En utilisant les generators et les templates d’ApplicationSet, il est alors possible de déployer plusieurs applications dans plusieurs clusters Kubernetes, tout ceci dans une spécification centralisée !

C’est une plateforme qui trouve son intérêt dans le fait que la gestion des applications et des ressources dans Kubernetes peuvent mener à des erreurs humaines ou des incohérences. Par son fonctionnement, ArgoCD se veut simple à utiliser et à configurer : ce qui est défini dans votre repository Git représente ce qui est déployé dans votre cluster Kubernetes. En effet, il bénéficie d’une fonctionnalité qui lui permet de vérifier l’état des ressources à intervalle régulier, afin de le réconcilier automatiquement si nécessaire. Par conséquent, c’est un outil sécurisant tant pour les développeurs que pour les administrateurs.

ArgoCD se veut aussi modulaire : au-delà des ressources Kubernetes, vous pouvez gérer et mettre à jour automatiquement les versions d’images de conteneurs qui sont déployées dans votre cluster via l’ajout d’ArgoCD Image Updater, qui suit les mêmes principes GitOps. En utilisant ArgoCD Notifications, il vous est également possible d’obtenir du monitoring et de l’alerting sur le déploiement de vos applications, bien que cette fonctionnalité soit encore immature selon nous.

La grande force d’ArgoCD réside dans son interface utilisateur, qui permet en un clin d’œil de comprendre l’état actuel des ressources, leur statut de synchronisation avec le repository source ou encore l’état des Pods associés à l’Application.

En quelques clics seulement, nous arrivons vite à comprendre qu'une Application peut déployer plusieurs ressources, comme un Service ou un Deployment. À son tour, un Deployment provoque la création d’un ou plusieurs Pods, ce qui est également pris en compte dans l’interface. Il est même possible de cliquer sur le Pod en question et d’en visualiser les logs ! Pratique, non ?

Pour ces raisons, ArgoCD est devenu chez Padok le standard vers lequel se tourner lorsqu’il s’agit de déployer des applications dans Kubernetes. Chez nombre de nos clients, l’implémentation d’ArgoCD a permis aux développeurs de mettre un pied dans le monde de l’infrastructure, en utilisant un environnement rassurant et une utilisation au quotidien qui s’avère simplissime.

Integrated CI/CD

La CI/CD intégrée regroupe les services tels que GitHub Actions et GitLab CI. Ils sont directement incorporés dans les plateformes éponymes, au plus proche du code.

La CI/CD (Continuous Integration / Continuous Delivery ou Continuous Deployment) représente les pratiques d'automatisation des étapes de mise en production d'une application. Cela va englober par exemple les tests, le build, la release et le déploiement de l’application. Jenkins, CircleCI ou TeamCity sont des exemples d’outils qui permettent de construire des pipelines de CI/CD. On les désignera ici comme "externes" car elles n'hébergent pas le code source de l'application sur laquelle les pipelines se basent.

D’un autre côté, GitHub et GitLab sont aujourd’hui les plus grosses plateformes pour le développement git collaboratif avec environ 130 millions d'utilisateurs combinés. Tout développeur visite quotidiennement ces plateformes afin de coder de nouvelles applications, approuver une pull request ou dépiler des issues.

Ces deux plateformes proposent aujourd’hui leur propre moteur de CI/CD : GitHub Actions et GitLab CI. Au moyen de fichiers YAML, il est très rapide de créer des pipelines d’automatisation qui vont faire gagner beaucoup de temps de développement. Le free tier de ces plateformes est en plus assez généreux, donc aucun besoin de payer ou créer une infrastructure dédiée si votre équipe de développement est petite.

Ce sont des outils qui aujourd’hui comprennent très probablement toutes les fonctionnalités dont vous pouvez avoir besoin. Si vos contraintes sont vraiment spécifiques, il est toujours possible de s’abonner à un accès premium qui donnera accès à des fonctionnalités avancées.

Au-delà de ça, les deux solutions sont auto-hébergeables. Le système de runners de GitLab CI dans Kubernetes est particulièrement bien rôdé. Il rend possible la construction rapide d’une plateforme d’exécution de jobs extensible à l’infini. Cependant, nous vous mettons en garde contre l’hébergement de vos runners si vos besoins ne s’y prêtent pas. Les coûts en maintenance et en calcul peuvent exploser. En outre, en tant que fonction clé du cycle de vie d’une application, une CI/CD instable peut rendre très difficile la vie de vos développeurs.

Malgré cela, nous recommandons à tous nos clients de se tourner vers l’une de ces deux plateformes pour créer leur CI/CD. Leur intégration au plus près du code les rendent extrêmement versatiles et réduisent énormément la boucle de feedback.

ELK

La stack ELK (Elasticsearch Logstash Kibana) propose une solution complète pour la gestion des logs et des performances de vos applications.

La stack ELK (Elasticsearch, Logstash, Kibana) est la suite populaire d'outils open source, développés par l'équipe Elastic, qui permet de stocker, indexer, visualiser et analyser les logs et performances de vos applications et de vos outils.

La stack permettra de répondre à plusieurs des enjeux des architectures et des applications modernes :

Centralisation des logs applicatifs et d’infrastructure
Visualisation en temps réel
Suivi des performances de vos applications et de vos outils (APM)
Mise en place de dashboard métier avec Kibana
Détection d’anomalies et mise en place d’alerting

La suite peut être complexe à déployer et à maintenir. Une bonne expertise des différents outils est nécessaire sur le long terme pour mettre à jour et faire évoluer la plateforme par rapport à vos besoins. Outre le coût de la maintenance, la suite complète pourra demander beaucoup de ressources (CPU, RAM et espace disque) en fonction de la quantité (historique) de logs que vous allez traiter.

Dans ce contexte, on ne saurait trop vous recommander d’utiliser l’opérateur Kubernetes ELK pour déployer la stack. La gestion n’en sera que facilitée, notamment pour des déploiements modestes. Sur le long terme, vous devrez vous appuyer sur des compétences techniques solides, pour mettre en place des configurations avancées sur la gestion de vos logs (rotation, sauvegarde, purge, etc).

Le jeu en vaut la chandelle, car une fois en place, c’est un formidable outil qui améliorera l’expérience et l’efficacité de vos développeurs pour produire des applications de meilleure qualité.

La stack ELK est un outil puissant, exigeant techniquement, qui tiendra toutes ses promesses à long terme, à condition d’avoir les compétences techniques nécessaires. C’est un choix plus flexible et évolutif que les outils natifs des Cloud Provider qui pourraient représenter une alternative intéressante au départ, mais qui seront très rapidement limités.

Helm

Helm est une solution de packaging pour le déploiement d’applications conteneurisées dans Kubernetes.

Lorsque vous utilisez Kubernetes pour déployer vos applications, le nombre de manifestes (fichier de configuration de ressource Kubernetes) rédigés pour les ressources à créer augmente mécaniquement. Plusieurs complications vont naturellement émerger :

le code va devenir très volumineux et coûteux à maintenir
gérer les dépendances de son application Kubernetes telles que l'association d'un pod à son service demandera de créer de la logique
il en est de même pour gérer des dépendances applicatives telles que le fonctionnement conjoint de son application avec Redis, une BDD ou un reverse proxy
versionner un ensemble de ressources Kubernetes en une seule application est très complexe
déployer une même application dans plusieurs environnements va demander de la duplication de code

Helm est un outil capable de répondre à tous ces problèmes. Son atout majeur réside en l’utilisation du moteur de templating du langage Go. Grâce à ce dernier, la création de manifestes Kubernetes est transformée en l’application de values (variables dépendant du contexte de déploiement) à des templates (manifestes Kubernetes agrémentées de balises de templating).

L’ensemble constitué des templates et du fichier de values par défaut constitue un chart. Un chart est versionné et peut être déployé dans un cluster Kubernetes (on déploie alors une release Helm). D’autres charts peuvent être déclarés en tant que dépendances, permettant ainsi de déployer des stacks applicatives complètes.

La CLI permet de déployer des charts locaux ou distants, étant donné que Helm apporte la possibilité de créer des registries de charts. Elle permet de déployer des versions précises, effectuer des mises à jour ou des rollbacks de ses applications. Nous utilisons des charts pour déployer Prometheus/Grafana, Cert-Manager, Cluster Autoscaler ou Nginx Ingress Controller entre autres.

Chez Padok, nous avons créé une librairie de charts Helm pour les applications que l’on utilise le plus souvent chez nos clients. Elle raccourcit de journées entières la mise en place d’ensembles complexes d’applications. Helm est donc un outil que nous recommandons à tous les utilisateurs de Kubernetes.

SemVer

Le Semantic Versioning est un système de versions dont les numéros, ainsi que leurs changements, donnent du sens aux modifications de code effectuées.

Le Semantic Versioning est un ensemble de règles qui dictent la façon dont les numéros de versions d’une application sont attribués. En suivant ces règles, vous pourrez facilement évaluer l’impact d’une mise à jour d’un composant dans votre infrastructure.

Cette convention propose de suivre le schéma MAJEUR.MINEUR.CORRECTIF pour toutes vos versions.

L'incrémentation MAJEURE signifie que des modifications incompatibles avec les versions précédentes ont été apportées. Il convient donc d'être prudent lors de la mise à jour.
L'incrémentation MINEURE signifie que de nouvelles fonctionnalités compatibles avec les versions précédentes ont été ajoutées. Mettre à jour vous permet d'utiliser ces nouvelles fonctionnalités sans avoir besoin de modifier votre configuration pour celles qui étaient déjà présentes.
L'incrémentation CORRECTIF signifie que des corrections de bugs et/ou de failles de sécurité ont été apportées. Mettre à jour ne modifie rien dans le fonctionnement de l'application ou de sa configuration.

Ce système peut être utilisé pour tout : API, Helm Chart, modules Terraform, etc. Et permet d’uniformiser votre gestion de version dans votre organisation. C’est aussi cette convention qui est utilisée par la communauté open source sur tous les outils et packages qu’elle propose. L’utiliser permet ainsi d’avoir une convention commune pour tous les outils que vous utilisez. Avec cet outil, fini la peur de la mise à jour et de la gestion des dépendances. Vous n'avez plus qu'à l'adopter !

Il existe aussi des outils, comme Semantic Release ou Release please, que vous pouvez facilement intégrer à vos pipelines de CI/CD pour vous aider à utiliser le SemVer.

Malheureusement, le SemVer n'est pas encore suffisamment utilisé, ce qui empêche de tirer pleinement parti de ses avantages. De plus, il est parfois mal utilisé (conventions non respectées) et cela accentue l’apparition de problèmes qu’il est censé régler.

Trial

Sentry

Sentry est un outil qui aide les développeurs à suivre les erreurs applicatives.

Sentry est un outil qui aide les développeurs à suivre les erreurs applicatives. Ainsi, ils peuvent facilement, via son interface web, identifier et corriger les bugs dans leur code afin d’améliorer la qualité des services développés. Pour ce faire, il suffit d’installer le SDK de Sentry correspondant à votre langage de programmation comme Node.js, Python, Ruby, Go, Android et bien plus encore. Le SDK va capturer les erreurs ainsi que les exceptions, et fournir des informations détaillées sur la cause première de chaque erreur.

Depuis quelque temps maintenant, Sentry gagne en popularité en raison de sa capacité à fournir des informations exploitables pour améliorer la qualité du code et la fiabilité des applications. On l’utilise également pour suivre les métriques de performance des applications en temps réel, ce qui peut aider à identifier les SPOFs et les problèmes de scalabilité.

Pour intégrer Sentry dans votre écosystème, vous avez deux possibilités : utiliser la solution SaaS (payante) ou bien l’installer en self-hosted sur votre cluster Kubernetes par exemple. Nous vous recommandons fortement d’utiliser la solution SaaS qui in fine sera l’approche la plus rentable.

En effet, l’architecture applicative de Sentry est très complexe avec pas moins de 10 composants à gérer, bien qu’il soit déployé avec un Chart Helm développé par la communauté (et non Sentry). Afin de fournir un niveau de disponibilité acceptable du service, il vous faudra y dédier beaucoup de temps et d’énergie pour corriger les erreurs natives du produit et connues de l’éditeur. On est nombreux à s’être arraché les cheveux dessus, croyez-nous !

Chez Padok, nous conseillons donc la solution SaaS de Sentry pour aider vos développeurs à améliorer la qualité et la fiabilité des applications au quotidien.

Loki

Loki est l’outil de logging natif de la stack Grafana.

Loki est un outil de logging développé par Grafana Labs. Il permet de collecter les logs de vos applications déployées dans Kubernetes et de les remonter dans Grafana afin de pouvoir les query.

Cet outil de logging est très simple à installer dans vos clusters Kubernetes. Il est déjà packagé dans le chart prom-stack de la communauté : vous n’avez qu’une option à activer et le tour est joué, quasiment aucune configuration supplémentaire n’est requise. Si vous vous servez déjà de Grafana, vous pourrez créer des dashboards complets, qui mélangent à la fois les métriques et les logs de vos applications, pour les monitorer et déboguer… Rien de mieux pour rendre vos développeurs complètement autonomes sur la gestion de leur application !

Il est aussi possible de mettre en place de la rétention de logs sur le long terme en envoyant l’historique dans des buckets. Cependant, l’outil n’est pas optimisé pour faire de la recherche sur des logs anciens : la recherche directe dans les logs accessibles dans votre cluster Kubernetes est plus performante que la recherche dans des logs déjà enregistrés qui doivent être décryptés et indexés. De plus, le langage qui sert à requêter les logs internes à Loki, le LogQL, n’est pas le plus facile à appréhender et maîtriser. La syntaxe est différente des langages de requête traditionnels et nécessite de bien comprendre ce qu’est un range vector.

Si vous utilisez déjà Grafana pour faire vos dashboards et que vous cherchez une solution facile à mettre en place pour remonter les logs de vos clusters Kubernetes pour faire du debugging, Loki est fait pour vous ! Notez que l’outil n’est pas fait pour la rétention long terme de logs, et son système de requêtage nécessite un peu d’apprentissage.

Preview Environments

Les preview environments permettent aux développeurs de tester les changements dans un environnement réel afin de réduire le risque d’erreur et d’augmenter leur efficacité.

Les preview environments permettent aux développeurs de prévisualiser les changements sur une application avant de les déployer en production. Ces environnements sont souvent utilisés pour tester les nouvelles fonctionnalités ou les mises à jour de code, notamment l'interopérabilité entre les différents sous-systèmes en jeu, et pour s'assurer que tout fonctionne comme prévu. Cela permet de minimiser les risques d'erreurs et le temps nécessaire pour corriger les problèmes éventuels.

Ces environnements améliorent aussi l'efficacité des développeurs qui peuvent travailler simultanément sur plusieurs fonctionnalités dans des environnements isolés, ce qui diffère d’un environnement staging “classique”. Ils peuvent être utilisés pour faciliter la collaboration entre les différents membres d'une équipe. Ils permettent aux développeurs de partager facilement les modifications qu'ils ont apportées, et de les tester ensemble avant de les publier.

Ces environnements peuvent être créés de différentes façons. Voici la méthode que Padok recommande aujourd’hui :

À chaque ouverture de PR sur une application, on déploie, en plus de la version “stable”, la version issue de la branche
Pour chaque nouvelle version déployée d’une application, on définit un header qui permet de router des requêtes dessus
Pour tester une PR, il suffit de faire des requêtes en utilisant ce fameux header

Cela fonctionne parfaitement dans un cluster Kubernetes, mais risque d'être plus compliqué à mettre en place sans. Et si cette méthode fonctionne parfaitement pour les applications fonctionnant en HTTP, nous n’avons pas encore de solution à proposer pour les applications event-driven.

Les preview environnements sont très utiles pour augmenter l'efficacité des développeurs de votre organisation. Cependant, ils sont un peu compliqués à mettre en place et à maintenir. Nous les recommandons donc principalement aux équipes en grande expansion.

DevSpace

DevSpace permet de créer des environnements de développement personnalisables et partageables dans un cluster Kubernetes.

Aujourd'hui, la moindre application ayant pour projet d'être mise en production à grande échelle requiert l'interaction de nombreux programmes différents. Si ce n'est pas un problème de déployer cette application dans le Cloud, c'est une autre paire de manches que de la lancer en local sur son ordinateur. Les exigences en puissance et en mémoire peuvent rapidement dépasser la capacité des ordinateurs personnels utilisés pour le développement.

DevSpace est une technologie qui vient à bout de ce problème, mais pas seulement. DevSpace se présente sous la forme d’une CLI dont l’utilisation doit être combinée avec un cluster Kubernetes. Le principe est simple : créer un pod dans le cluster, y installer toutes les dépendances nécessaires à son environnement de travail, puis s’y connecter.

DevSpace se configure au moyen d’un fichier YAML qui peut donc faire partie d’un repository de code et être partagé entre une équipe de développeurs. Cela permet, entre autres, d'homogénéiser les environnements de développements de chacun. L’utilisation d’un ordinateur plus ancien n’est alors plus un frein au développement, en plus de rendre facultatif l’installation des dépendances à votre projet.

Le développement de microservices conteneurisés se prête très bien à l’utilisation de DevSpace. On peut imaginer la mise en place d’un environnement de développement hybride, où il est seulement nécessaire de déployer son pod. Il pourra ensuite communiquer de manière transparente avec les microservices déjà présents dans le cluster.

Nous mettons cependant en garde face au coût d’entrée pour l’utilisation de cet outil. Contrairement à des outils managés comme GitHub Codespaces ou GitPod, de bonnes connaissances de Kubernetes sont nécessaires pour exploiter le plein potentiel de DevSpace. Il n’est donc pas accessible au premier venu.

Chez Padok nous aidons nos clients à migrer leurs applications vers Kubernetes. DevSpace est l’outil que nous recommandons dès lors que vous souhaitez y intégrer vos environnements de développement. C’est une solution open source, légère et puissante que vous devez essayer si votre contexte technique s’y prête.

Flagger

Flagger est un outil de déploiement de type canary, blue/green ou encore A/B pour vos applications hébergées sur Kubernetes.

Flagger est un outil qui permet de réaliser efficacement des déploiements progressifs de vos applications hébergées sur Kubernetes. Par exemple, vous pouvez valider et tester de nouvelles fonctionnalités de votre application sur un public restreint avant une mise en production à grande échelle. Ainsi, vous renforcez la maîtrise de vos releases en réduisant l’introduction de régressions ou bugs applicatifs.

Au vu de notre expérience, ces différents types de déploiements sont souvent évoqués dans les articles et bonnes pratiques à suivre, mais très peu mis en place. Pourquoi ? Cela nécessite une vraie maturité au niveau des pratiques de développement, comme avoir des stratégies de tests avancés (quality gates, tests E2E ,…) ou faire du feature flag.

En revanche, si vous cochez toutes les cases et que vous avez un réel besoin de déployer une nouvelle version de votre application de manière progressive, et qu'elle est déployée sur Kubernetes, Flagger est la solution idéale !

Selon la stratégie retenue, vous pourrez l’utiliser pour faire :

du canary release (déployer graduellement une nouvelle feature à vos utilisateurs) ;
du A/B testing (tester un nouveau changement sur un panel d'utilisateurs réduit pour voir comment ces derniers réagissent) ;
Blue/Green (déployer une nouvelle fonctionnalité en dupliquant la production d’un point de vue infrastructure) ;

Pour finir, il peut s’interfacer avec d’autres solutions comme Prometheus, Datadog ou Linkerd pour analyser des metrics et gérer de manière automatique les rollbacks en cas de problème. Ainsi, vous pouvez garantir vos SLOs, comme des taux de disponibilité supérieurs à 99,95%, pour l’ensemble vos parcours critiques.

Assess

Kubernetes native CI/CD

Les CI/CD Kube native sont des outils de CI/CD totalement intégrés à Kubernetes

L'extensibilité de Kubernetes via les CRDs (Custom Resource Definitions) a entraîné moult innovations dans de nombreux domaines, et la CI/CD n'y échappe pas. Même si ArgoCD pourrait rentrer dans cette catégorie, il est aujourd'hui spécialisé dans le déploiement sur Kubernetes et ne permet pas de répondre à la moitié de ce blip (la CI).

Nous voyons donc aujourd'hui émerger des outils basés sur Kubernetes qui se rapprochent des moteurs de workflow que nous utilisons/avons utilisé par le passé (e.g. Jenkins) et qui permettent de définir déclarativement des pipelines de CI/CD ou tout autre workflow dont vous auriez besoin.

Nous allons nous intéresser à 2 outils qui n'ont aujourd'hui pas tout à fait la même cible : Tekton et Argo Workflow.

Tekton est une extension (un opérateur) de Kubernetes permettant de définir des workflows via de nouvelles ressources (Task et Pipeline) et de déclencher ces workflows via n'importe quel type d'événement (EventListener et Trigger). Son intégration simple dans Openshift en fait un outil très utilisé pour la CI/CD et il peut être vu comme le successeur Kubernetes Native de Jenkins.

A l'instar de Tekton, Argo Workflow permet de réaliser sensiblement la même chose. Il est aujourd'hui principalement adopté par les équipes réalisant des traitements sur de la data (ETL) ou du machine learning.

Nous ne sommes pas encore complètement convaincus par ces approches pour remplacer entièrement les outils intégrés à vos providers git (e.g. Github Actions, Gitlab-CI) du fait de leur adoption déjà établie. Mais dans le cas où vous disposez d'une infrastructure hétérogène (e.g. VM-Based, Kubernetes etc.) ces outils vous permettront justement d'homogénéiser votre manière de tester et déployer.

Argo Rollout

Argo Rollout permet facilement de mettre en place des modes de déploiement complexes (Blue-Green / Canary)

Argo Rollout, à l'instar de Flagger, est une solution permettant de faire ce qu'on appelle communément du "Blue-Green Deployment" ou des "Canary Release". Ces modes de déploiement complexes n'étaient pas à la portée de toutes les organisations avant la création de ces outils, car ils nécessitent le développement d'un outil custom et ou la mise en place de workflows complexes via des outils comme Jenkins.

Sa mise en place, comme tous les outils de l'écosystème Argo, passe par Kubernetes et de nouvelles ressources (CRD Rollout). L'outil tire judicieusement partie du support pour les subressources sur les CRD introduit en Kubernetes 1.10 pour introduire une nouvelle ressource comparable en tout point à un Deployment (en utilisant la subressource / scale), mais en complexifiant les spécifications de la stratégie de mise à jour.

Ce faisant vous pouvez désormais écrire des “déploiements à étapes” en utilisant notamment :

Des étapes de scaling (Augmentation du nombre de pods dans la nouvelle version)
Des étapes de pause
Une analyse en background pour déterminer si le déploiement doit continuer (e.g une requête à Prometheus)

Pour les modes de déploiement complexes, nous privilégions Flagger car nous l’avons davantage éprouvé sur nos projets. Cependant, nous pensons qu’Argo Rollout a de l'avenir dans la réponse à cette problématique. Les deux outils tirent parti de l'intégration à leur écosystème respectif (FluxCD pour l'un, ArgoCD pour l'autre).

Cependant, mettre en place ce genre de modes de déploiement nécessite une maturité importante et un très bon système d'observabilité.

Backstage

Backstage est un outil couteau-suisse qui, si bien utilisé, peut devenir le point central de votre Internal Developer Platform (IDP).

Backstage est une technologie open sourcée en 2020 par Spotify dont le but est la création d'un portail développeur extensible pour votre plate-forme interne.

L'idée derrière Backstage est de devenir le point de passage "obligatoire" et unique pour interagir avec votre plate-forme interne. Dans sa version sans plugin additionnel, Backstage propose déjà plusieurs features intéressantes :

TechDocs qui permet d'agréger toutes les documentations au format Markdown dans votre instance Backstage
Software Templates qui permet la création de boilerplates pour démarrer de nouveaux services (e.g. Initialisation du repository)
Software Catalog qui permet de référencer les différents services/utilitaires que vous utilisez ou développez. Il peut par ailleurs agréger toutes les specs OpenAPI ou Swagger de vos services web.

La principale force de Backstage est liée à son extensibilité. De nombreux plugins ont été développés par la communauté (e.g. Une intégration avec ArgoCD) et il est totalement possible d'imaginer développer ses propres plugins afin de satisfaire les besoins internes.

Il ne convient cependant pas à toutes les organisations et n'est réellement utile qu'à partir du moment où votre équipe Tech/R&D dépasse les 50 personnes. Cette "taille critique" correspond au moment où suivre l’ensemble des évolutions de votre plate-forme commence à être très complexe.

Le premier gain que nous avons pu observer avec Backstage est la facilitation de l'onboarding des développeurs et des DevOps grâce à la centralisation de la documentation technique à un seul endroit. Ceci permet un gain important sur le KPI "Time to first PR" clé dans des équipes techniques conséquentes.

Nous sommes toujours en train d'observer les gains de Backstage sur des équipes tech de tailles différentes, et c'est pourquoi il reste pour le moment dans le cadran “Assess”.

Platform Engineering

Le Platform Engineering est une manière de concrétiser la philosophie DevOps 😉

A l’origine la promesse initiale du Cloud était de simplifier l’administration système en abstrayant sa complexité : si votre équipe comptait un développeur backend débrouillard, alors le NoOps était presque réalité ! Mais le nombre croissant de services (plus de 200 sur AWS) et de technologies, a créé une demande pour des compétences spécifiques. Pas de soucis me direz-vous, un ou plusieurs DevOps intégré(s) aux équipes de développement et le tour est joué !

Pourtant, le DevOps atteint aujourd’hui ses limites et les DevOps (re)deviennent malheureusement le goulot d’étranglement du delivery notamment car :

comme évoqué ci-dessus, les technologies et services sont de plus en plus complexes à utiliser
pour que l’adage “You build it, you run it” reste vrai, les développeurs ont un besoin d’expertise qui dépasse souvent leur champ de compétences

Certaines Digital Factory ont une démarche qui se rapproche du Platform Engineering car elles produisent des outils communs pour toutes les business units de leur groupe. Cependant ceci fonctionne difficilement car elles prennent superficiellement en compte les besoins des développeurs et sont plutôt incitées à massivement uniformiser et sécuriser.

Pour nous, le Platform Engineering consiste à considérer l’infrastructure comme un produit à destination des développeurs. Ceci a 3 implications :

collecter les besoins et feedbacks utilisateurs
déterminer les jobs to be done et performances critiques de l’infrastructure
repenser l’Operating Model. Nous vous conseillons de découper l’équipe DevOps en deux : une équipe Enabler livrant de nouveaux produits aux équipes tech, une équipe Operators assurant la fiabilité et la cohérence de la plateforme sous-jacente

Chez Padok, nous pensons que le DevOps est au service du développeur et, sans être révolutionnaire, le Platform Engineering va permettre de renforcer ce mindset là. Il est important que la communauté développe ou adapte des outils du monde du produit afin de passer d’un beau concept à une réalité. Un point d’attention cependant : le Platform Engineering devient intéressant passé une taille minimum des équipes de Devs et Ops.

Replibyte

Pour tester de nouvelles fonctionnalités avant de les intégrer dans son application, Replibyte permet de créer des données de test réalistes et anonymisées à partir de données de production.

Replibyte est un CLI open source développé par Qovery. Il est compatible avec les SGBD MongoDB, MySQL et PostgreSQL qui est actuellement le mieux supporté.

Les différentes fonctions de Replibyte sont :

la création de dumps de données et leurs sauvegardes locales ou distantes (S3) versionnées ;
la transformation de colonnes de données dans un format adaptable à leur contexte (faux email, faux numéro de téléphone, random…) ;
la restauration de ces dumps dans un container de test, ou dans une base de donnée cible ;

Étant une CLI, elle peut s’utiliser comme un outil de développement comme beaucoup d’autres, mais aussi être utilisée au sein d’un cronjob ou d’une pipeline de CD.

L'intérêt de Replibyte pour la création de données de test est double : d'une part, il facilite grandement la création de ces données, et d'autre part, en utilisant correctement l'outil, il est possible de garantir l'absence de données sensibles telles que des données d'identité ou bancaires.

En outre, la fonctionnalité de subsetting, permettant de réduire la taille d’une base de données en conservant l’intégrité des relations, ainsi que la légèreté du format CLI sont pour nous les facteurs différenciant de Replibyte.

Chez Padok, les tests que nous avons réalisés n’ont pas révélé le potentiel qui est avancé par les créateurs. Après une discussion avec eux, nous avons été rassurés sur le caractère anormal des mauvaises performances que nous avions obtenues. Nous avons ouvert une issue sur le repository de l'outil pour les aider à investiguer.

Nous restons donc confiants sur le fait que Replibyte deviendra incontournable au moyen d’optimisations de performance et d’un rythme de développement soutenu.

Hold

Jenkins

Jenkins est un orchestrateur de workflow très générique qui permet énormément de flexibilité, mais qui nécessite un gros effort de customisation.

Jenkins est avant tout un orchestrateur de workflows automatisés. Il permet de déclarer des projets dans lesquels il est possible de définir des suites d’actions, que l’on peut ensuite exécuter. Il est également possible de visualiser l’évolution dans le temps de l’état (“success”, “failure”, etc).

L’interface tout comme les mécanismes disponibles pour les workflows sont extrêmement personnalisables via des plugins. Cela vous permettra d’utiliser des variables matricielles pour les actions, d’avoir une météo du projet, des tableaux de bord, voire de pouvoir lancer des scripts généralistes pour réaliser des actions sur vos plateformes de test.

Jenkins s'intègre aussi nativement avec le langage Groovy pour aller plus loin dans la définition des workflows.

Parmi l’ensemble des possibilités, on peut donc en particulier définir des pipelines de CI/CD via notamment des plugins d’intégration avec des gestionnaires de version de code par exemple.

Cependant, nous recommandons en majorité à nos clients de se tourner plutôt vers les CI/CD intégrées (ex : GitHub Actions ou GitLab-CI). Ceux-là fournissent nativement toutes les fonctionnalités nécessaires au développement web moderne, et permettent de disposer d’une expérience plus clé en main. Cela nécessite beaucoup d’effort de customisation initiale, mais plus de stabilité à l’usage.

Par ailleurs, des outils de CI et / ou CD spécifiques à certains environnements (ex : ArgoCD pour des déploiements dans Kubernetes) réduisent l’intérêt d’un outil généraliste comme Jenkins, qui nécessite en plus sa propre maintenance.

Empowering