Intro: Bonjour à tous. Et merci d'être venu à notre conférence sur le Platform Engineering et Kubernetes. Mais Laurent et moi on se pose la question:
Vous êtes venus parceque que vous avez vu que Platform Engineering fait partie des tendances technologiques 2023, d'après Gartner ?
markdown-link-check-disable
markdown-link-check-enable
Vous êtes venus parceque que vous avez vu que le Platform Engineering faisait partie des pratiques au tout début de leur vie sur le cycle de l'efferscence Gartner ?
Ou même, vous avez vu passer dans votre fil d'actualité que DevOps était mort, et comme votre titre sur votre badge est "DevOps", vous vous demandez par quoi vous allez le remplacer.
markdown-link-check-disable
markdown-link-check-enable
markdown-link-check-disable
markdown-link-check-enable
Si vous vous posez ces questions, et bien vous êtes dans la bonne salle. Aujourd'hui, Laurent et moi même allons vous parler de l'ingénierie de plateformes (platform engineering), et comment et pourquoi Kubernetes peut fournir de solides fondations. Je m'appelle Olivier Jacques, et je suis architecte Cloud & DevOps à AWS. Je m'appelle Laurent Gil, ... Laurent et moi, nous avons participé à la construction de plateformes, Laurent continue à le faire à Atos, et moi-même j'aide les clients d'AWS à construire leur propre plateforme. La plus grosse que nous ayons construit accueillait jusqu'à 30,000 builders et consistait à leur fournir tout ce qu'il faut pour définir, développer, tester, déployer et opérer les applications de notre entreprise. Cette plateforme - qui nous survécu puisque nous avons quitté l'entreprise depuis - comportait du Kubernetes, mais pas que. Et nous aurons l'occasion d'en reparler tout au long de cette présentation, car, il s'agit bien ici d'un retour d'expérience, et de convictions forgées au fur et à mesure depuis 2017.
Je voulais remettre ici cette citation de Dr Werner Vogels, CTO d'AWS. "You Build it, you run it". C'est important, car c'est comme cela que nous opérons à AWS. Cela dit, tout n'est pas dit dans ces 6 mots. Pour opérer ainsi, les ingénieurs d'AWS ont besoin de plateformes. Pour construire et opérer les plus de 200 services distincts que compose AWS à ce jour, notre plateforme est bien évidemment AWS lui-même. Mais pas seulement. Nous avons aussi des plateformes construites au dessus d'AWS, par nos équipes, pour améliorer la productivité de nos équipes, standardiser, sécuriser, éviter de ré-inventer la roue, et surtout innover du mieux suivant ce que nos clients nous demandent. Et c'est là que le Platform Engineering entre en jeu.
Les plateformes ne sont pas nouvelles. Par exemple, dans le monde de l'automobile, les plateformes ont révolutionné la façon dont les constructeurs automobiles développent et commercialisent leurs véhicules. Volkswagen a lancé sa plateforme MQB en 2012. Cette plateforme a permis à Volkswagen de réduire le temps de développement de ses véhicules de 30% et de réduire les coûts de développement de 20%. Nous devons pouvoir utiliser ce concept dans le monde du cloud. Sauf que... voyons la suite.
Les standards ne réduisent pas la créativité, mais ils la boostent. Se mettre d'accord sur certains standards permet de booster la créativité.
!!!! - Permet de changer le paradigme de pipeline (push pipeline devient pull pipeline) !!!! - Bénéficie d'un écosystème très large permettant le monitoring, l'observabilité, la sécurité
Et si les ressources étaient de type infrastructure ou encore des applications internes à l'entreprise.
Présentation de l'écosystème qui fait de k8s un outil de choix pour réaliser une plateformz
Réalisé au niveau de l'API via des webhooks
(ex: renseigner une base de référence d'application à partir de resources de type déploiment)
## Habituellement - Cycle de vie infra séparé du cycle de vie de l'application - Packagé séparément - Utilise des languages différents => charge cognitive - Dépendance entre pipeline (ex: storage, database, DNS,...) - un pipeline pour l'infrastructure - un pipeline pour l'applications ## Avec Kubernetes comme plateforme - K8s et sa capacité à être étendu via des controlleurs résoud ces problèmes. - un seul pipeline pour l'**infrastructure + application**. - atomicité du déploiement - **universal control plane**
- sécurité: - Sur un pipeline push les agents de l'orchestrateur ont souvent des droits étendus. Sur un pipeline pull, c'est l'environnement cible qui a des droits sur la CI. - Pipeline push scale mal à travers plusieurs clusters - YAML syntax permet d'utiliser le patterne app of app, ce qui permet de démarrer tout un cluster à partir d'un application bootstrap (mettre un example argocd)
Developers should be able to deploy and run their apps and services end to end. “You build it, you run it”. True DevOps.