Notre retour (Build & Deploy) sur Devoxx France 2024

Sylvain METAYER - May 30 - - Dev Community

Après les retours de nos collègues, nous allons faire les notres sur la partie Build & Deploy de l'édition 2024 de Devoxx France.

Et comme chaque année, le moins que l'on puisse dire, c'est qu'il y avait du choix, avec plusieurs dizaines de conférences sur les façons de packager et déployer nos applications ! Sans plus attendre, voici les sujets qui nous ont marqué avec @cfarges et @jtama dans cette catégorie.

GatewayAPI, 10 ans de maturation pour une nouvelle API Kubernetes

Cette année Kévin Davin est venu nous parler de la Gateway API. <3

En effet, avec pas mal de recul, le constat est clair : la ressource Ingress n'est pas suffisante. Elle prend en charge trop de responsabilité, n'est pas suffisamment spécifique, laissant chacune de ses implémentations faire différent choix pour la même solution (manque de portabilité), et ne rend pas non plus suffisamment de service.

La Gateway API est orientée rôle avec plusieurs kinds:

  • La GatewayClass:: Pour le provider, celui qui connait le réseau
  • La Gateway :: Pour le cluster operator, celui qui connait le cluster 🤷
  • Les GRPCRoute / HTTPRoute:: Pour les développeurs, ceux qui connaissent les applications.

Chaque personne ayant ses compétences, ses connaissances, ses responsabilités, et ses kind.

Cette api va suffisamment loin pour empiéter largement sur une partie des services offerts par les service mesh (dont le traffic splitting).

Replay

Multi Kubernetes, Multi Régions, Au-secours !

Aurélien Moreau et Nicolas Lavacry présentent, au travers d'un REX avec pour exemple une entreprise fictive, les besoins de leur nouvelle entreprise : CASDAL. Cette dernière a en effet 2 marchés : un marché américain, et un français. Comment gérer l'hébergement de cette application ?

On découvre alors comment déployer un environnement Kubernetes sur plusieurs régions, et le besoin de créer plusieurs clusters pour assurer une latence faible, Kubernetes n'aimant en effet pas les latences si un continent sépare plusieurs noeuds. Leur démo, parfaitement maitrisée permet de nous montrer l'envers du décor et des outils/méthodes pour garantir qualité de service, latence faible et l'intégrité de nos données !

Replay

Notre dépendance à l'Open Source est effrayante. SLSA, SBOM et Sigstore à la rescousse

Cette conférence, très intéressante, nous montre à quel point nous dépendons de logiciels/dépendances tierces dans nos applications, sur lesquelles nous n'avons pas la main. Cela signifie-t-il pour autant qu'il faut les utiliser sans valider leur intégrité, pour éviter qu'un intermédiaire vienne injecter du code malveillant lors d'une étape de packaging de notre application ?

Abdellfetah Sghiouar nous présente alors des outils sur lesquels nous pouvons nous appuyer pour garantir la tracabilité de nos applications, tel que cosign pour signer nos images avant de les déployer dans notre cluster, ou encore SBOM pour lister tous les paquets utilisés dans notre application.

Replay

Au cœur de la ruche eBPF!

J'avais déjà entendu parler plusieurs fois d'eBPF, sans vraiment savoir ce dont il s'agissait. Cette conférence était donc l'opportunité pour moi de creuser un peu le sujet ! Bien que très technique, Mohammed Aboullaite a bien expliqué le fonctionnement d'un module du kernel et l'évolution d'eBPF. Je ne pense pas avoir l'usage dès demain d'écrire mon propre module kernel, mais je comprends mieux toute la "hype" autour de ça et la plus-value d'eBPF afin de pouvoir simplifier la distribution d'un nouveau module, tout en ayant des performances natives et en gardant la même sécurité.

Replay

Le cauchemar des attaquants : une infrastructure sans secret

Thibault Lengagne nous montre comment s'appuyer sur Vault et Boundary afin de supprimer la plupart des mots de passes
de nos environnements tout en conservant une approche "Secure by design" et avoir une traçabilité complète des différents accès aux composants applicatifs.

Avec une architecture Zero-Credentials, on dispose d'un seul mot de passe par utilisateur qui permettra d’accéder à travers Boundary
à nos applications. L'association de Boundary et Vault permet de créer des identifiants temporaires et de garder une traçabilité complète des accès aussi bien en environnement de développement que jusqu'à la production.

Thibault nous montre une solution d'architecture et les bonnes pratiques associées à ces concepts. A travers plusieurs petites démo, on commence à avoir envie de déployer ça dans nos environnements après avoir vu la taille de l'équipe grandir.

Fini les rotations de mot de passe à n'en plus finir, on a un accès et le reste est géré par les politiques définies dans le code source de notre infrastructure.

Replay

Check-list ultime pour rendre vos app cloud native

Dans cette conférence Katia Himeur revient sur les différents contextes qui peuvent nous amener à déplacer nos applications sur le "cloud".

Elle nous rappelle que la définition du "cloud" peut être vastement différente suivant nos interlocuteurs. La complexité, la pléthore de solutions disponibles (plus de 2000 outils disponibles chez la CNCF par exemple) et la diversité des fournisseurs doivent être pris en compte lors d'un projet cloud, que ce soit pour une nouvelle application
ou le portage d'un existant.

Entre la méthodologie et le REX, la conférence de Katia est une mine d'informations et d'inspiration sur la manière d'aborder ce type de projet.

Les points présentés se situent autant au niveau de la technique que de l'humain, avec l'onboarding des équipes et la conduite du changement. Les principaux points durs de ces projets sont pris en compte, serait-ce la recette ultime ?

Replay

Le mot de la fin

Merci à @onepoint pour nous permettre de participer chaque année à ce moment privilégié !
N'hésitez pas à aller regarder les autres articles publiés par nos collègues sur les autres thèmes !

Retrouvez notre série d'articles sur Devoxx :

  1. Intro
  2. Frontend
  3. Data/IA
  4. Backend
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .