Le platform engineering : qu'est-ce que c'est et comment l'implémenter dans son organisation ?
Télécharger en tant que PPTX, PDF0 j'aime41 vues
Le document présente les offres et services d'Eleven Labs, soulignant le concept de 'platform engineering' comme solution pour améliorer l'autonomie des équipes de développeurs tout en réduisant la complexité des infrastructures. Il explore également des exemples de mise en œuvre de plateformes de développeurs internes dans différentes structures, allant des PME aux grandes entreprises, et discute des défis et des meilleures pratiques associés à ce processus. Enfin, le document aborde l'importance de comprendre les besoins réels des utilisateurs et d'anticiper les évolutions technologiques lors de la conception de telles plateformes.
Le platform engineering : qu'est-ce que c'est et comment l'implémenter dans son organisation ?
- 1. ELEVEN LABS, C’EST ? 1 12 100 15 M€ 50+ ans d’existence de la fusée elevenienne astronautes actuellement dans la fusée de chiffres d’affaires clients de tous secteurs : média, e- commerce, presse, banque… PARIS 102 rue du Faubourg Saint-Honoré 75008 Paris France NANTES 40, rue la Tour d'Auvergne 44200 Nantes France MONTRÉAL 1155, Metcalfe St Suite 1500 Montréal, QC H3B 2V Canada 7 OFFRES DE SERVICES Développement web & mobile DevOps & adaptation continue du SI Data Management Stratégie et Pilotage Produit Design & User Experience Architecture SI & Data Coaching Agile
- 2. UX Design 101 Introduction à l’UX Design Platform Engineering : La grande réponse à la vie, l’univers, et tout le reste
- 3. Qui suis-je ? DevOps / Platform Engineer @ Eleven Labs graillus 𝕏 @grailloute Robin Graillon
- 5. Il y a fort longtemps…
- 6. DevOps à la rescousse !
- 7. DevOps
- 8. Mais il y a un couac
- 9. DevOps : The new Full Stack
- 10. Ça ne va pas en s’arrangeant…
- 12. L’utopie DevOps
- 13. DevOps : Le bilan ● Les équipes sont plus autonomes Mais : ● Elles ont mal à maîtriser le nombre grandissant de technologies ● Augmentation exponentielle de l’entropie ● Sécurité : modèle du “least privilege” compromis ● Le DevOps est souvent mal implémenté
- 15. Objectifs du Platform Engineering ● Rendre les équipes de développeurs autonomes (You build it, you ship it, you run it) ● Limiter la charge mentale liée à la multiplication des technos ● Limiter les dépendances inter-équipes ● Normaliser, standardiser les pratiques ● Garantir l’application des règles de sécurité
- 16. Internal Developer Platform ● Une plateforme en temps que service (PaaS) interne ● Pensée comme un vrai produit sur mesure ● Point d’entrée unique où sont disponibles toutes les infos (docs, statut des services, etc.) ● Couche d’abstraction pour masquer la complexité de l’infrastructure ● Répond aux besoins des équipes en utilisant les standards de l’entreprise (conventions, sécu, etc.)
- 18. Self-service INTERNAL DEVELOPER PLATFORM VM Instance Database DNS Kubernetes CRD Container Registry CI/CD Pipeline Développeurs Test Environnement Application Astro “J’ai besoin d’un environnement de test pour mon application Astro Délivre un environnement
- 19. Service Catalog
- 20. En résumé Côté équipes produit : ● Meilleure autonomie ● Plus besoin d’expertise sur les détails d’implémentation de l’infra ● Plus besoin d’accès administrateur sur les ressources de l’infra Côté équipes infra : ● Meilleur contrôle des implémentations = uniformisation ● L’infrastructure peut être remaniée sans casser le contrat d’interface ● Centralisation des compétences SecOps/FinOps ● Mutualisation des ressources
- 21. Platform Engineering : Oui, mais…
- 22. Platform Engineering : Oui, mais… ● Concevoir, développer et maintenir la plateforme a un coût ● Ce surcoût est-il toujours justifié, même pour une structure de taille modeste ? ● Le cas échéant, puis-je adapter les pratiques à mon organisation ?
- 23. Oui, le Platform Engineering peut s’adapter à toutes les structures
- 24. Infra Plan et Dev Mo on Dev Moo n Exemple 1 : Système Planétaire Type : PME/Startup (moins de 50 techs) Contraintes : ● Peu de ressources disponibles ● Pas assez de budget pour équipe plateforme dédiée
- 25. Ce qui compte ● Un point d’entrée unique, pour tous ● Documentation facile à trouver, et à jour ! ● La “plateforme” devient le réflexe de tout le monde (consultation + contribution)
- 26. Internal Developer Platform Starter Pack Support : Confluence, Notion, Mkdocs Contenu : ● Documentation ○ Procédures courantes ○ Best Practices ○ Troubleshooting, Runbooks ● Recensement des apps et leurs URLs par environnement ● Liens utiles (outils, repository de templates) Templates : ● Modules Terraform ● Templates de pipelines CI/CD Services: ● Pipelines/Workflows en libre service
- 27. Infra Star Prod uct Team Platfo rm Team Exemple 2 : Système Solaire Type : Entreprise moyenne à grosse / ScaleUp (50 à 500 techs) ● Plusieurs équipes infra : Core, Data, Cloud ● Équipes produit plus nombreuses Contraintes: ● Responsabilités réparties sur plusieurs équipes ● Budget plateforme limité Prod uct Team
- 29. Internal Developer Platform Support : SaaS (Port) ou Self-hosted (Backstage) Contenu : ● Catalogue de services ● État de mes services ● Déploiements/configuration Templates : ● Templates de repositories ● Charts Helm ● Libs Services: ● Storage bucket ● Secret Management API: ● Interface “click click”
- 30. Infra Black Hole Prod uct Team Platfo rm Team Exemple 3 : Galaxie Type : Très Grosse Structure (500+ techs) ● Communication très difficile (ticketing) ● Dépendances entre équipes infra ● Grande diversité des services Prod uct Tea m Platfo rm Team Infra Team Platfo rm Team Infra Team Prod uct Team Prod uct Team Prod uct Team Prod uct Tea m Prod uct Prod uct Team Prod uct Tea m P u T
- 31. Organisation
- 32. Internal Developer Platform : Modèle haut de gamme Support : Backstage ou recette maison ● Interface 100% sur mesure ● Chaque platform team intègre son module Services: ● VMs, K8S Clusters ● Plusieurs niveaux de HA API : ● APIs REST ● CLIs ● Libs ● Modules Terraform (pour l’API)
- 33. Ce qu’il faut retenir Faites en fonction de vos moyens, l’idéal reste le même Le Platform Engineering c’est avant tout un changement de mentalité et d’organisation Particulièrement pertinent dans les moyennes et grosses structures
- 34. REX: Conception d’une plateforme évolutive basée sur des Contrôleurs Kubernetes
- 35. Le contexte ● Un grand groupe international (secteur financier) ● 100+ Dev teams réparties dans 4 Time Zones ● Gestion d’un parc de 500+ clusters Kubernetes dans le cloud ● 4000+ Requêtes de support par an ● 4 ingénieurs dédiés au support
- 38. Leçons ● Besoin mal compris dès le départ ● Manque de feedback temps réel aux utilisateurs ● Techniquement pas fiable ● Utilisateurs perdus en cas de problème
- 40. Comment on s’y est pris
- 41. L’équipage de choc ● 1 Product Manager : Vision produit ● Développeurs Front End : Développement du portail en React ● Platform Engineers : Conception et implémentation de la plateforme
- 42. Récolte des besoins ● Étape la plus importante ● Aller auprès des équipes ● Analyse des tickets de support récurrents ● Aller chercher dans l’historique des mails ● Ce qui nous prend trop de temps au quotidien et qui doit être automatisé
- 43. Conception du produit ● Conception pour avec les équipes, définition de l’API ● Expérience utilisateur : simplicité, efficacité ● Fait pour durer : robuste et maintenable dans le temps ● Évolutif : Anticiper les changements de technos ou d’organisation ● Rester pragmatique : ne pas mettre la barre trop haut
- 44. Planification ● Découper en fonctionnalités ● Ne pas tenter de livrer tout d’un coup ● Prioriser les “quick wins” ● Focus sur les fonctionnalités à forte valeur ajoutée ● Roadmap
- 45. Conception Technique Nos contraintes : ● Rétrocompatible avec l'infrastructure existante ● Ne pas bloquer la gestion du parc legacy ● Se concentrer sur la valeur : Ne pas réinventer la roue Bonus : ● API Orientée état ● Architecture modulaire pour pouvoir travailler à plusieurs équipes
- 47. Pourquoi pas Kubernetes ? "Kubernetes is a platform to build platforms" - Kelsey Hightower
- 48. Kubernetes
- 50. Une API extensible ● Déclarer facilement nos propres ressources d’API avec CustomResourceDefinitions (CRDs) ● Implémenter nos propres contrôleurs avec notre logique métier ● Auto-découverte des CRDs installées dans le cluster ● Interopérabilité (OpenAPI v3 schema)
- 52. Un écosystème riche ● Outillage plug & play: ArgoCD, Crossplane, etc. ● Libs disponibles dans les principaux langages (Python, Go, Java, etc.) ● Frameworks: controller-runtime, operator SDK
- 53. Et aussi ● Gestion des permissions fine (RBAC) ● Multi-tenancy (Namespaces) ● Admission Webhooks : validation & mutation ● Monitoring (stack Prometheus)
- 55. Comment implémenter un contrôleur ? (et c’est pas si compliqué)
- 56. Operator SDK ● Génère le code boilerplate de l’opérateur ● Génère les CustomResourceDefinitions ● Génère les manifests pour déployer
- 57. Implementation des CRD ● Compléter les types pré-générés ● Gestion de la validation via annotations ● Génération des CRDs via simple commande
- 58. ● Plus qu’à ajouter la logique métier ● Écosystème Go très complet sur l’outillage DevOps ● Gestion d’erreurs : Requeue, Status Conditions ● On oublie pas les tests unitaires à compléter Implementation du controleur
- 59. Résultat
- 60. Rappel des étapes de développement ● Implémenter le code ● Tests ● Documentation ● Tests ●Tests ●DOCUMENTATION
- 61. Déploiement ● Communication ● Rollout progressif / Double run ● Monitoring ● Rollback en cas de problème
- 62. Recommencer ● Iterations rapides ● Récolter du feedback en continu ● Ressenti des équipes > métriques techniques pures ● Communication nouvelles releases
- 63. Bilan
- 64. Résultats (attendus) ● Moins de demandes de support ● Plus de temps passé sur des nouvelles fonctionnalités ● Nos services sont utilisés (moins de shadow IT) ● Nos utilisateurs sont contents ● Nos utilisateurs se contentent des permissions read-only sur l’infra
- 65. Challenges rencontrés ● Comprendre les vrais besoins ● Gestion du parc existant (rétrocompatibilité) ● Gestion du drift ● Éviter les abstractions mal faites ● Ne pas casser le contrat d’API
- 66. Pro Tips ● Utiliser des outils et pratiques standard ● Avoir un dev senior dans l’équipe ● Versioning / Release management ● Ne négligez pas le monitoring
- 67. La suite ● Implémenter d’autres contrôleurs ● GitOps ● Remplacer Terraform par Crossplane ? ● Résilience : que se passe-t-il en cas de perte du control plane ? ● Gouvernance : qui est responsable du cluster de Management ?
- 68. Questions ?
- 69. Merci !
Notes de l'éditeur
- #2: Est-ce que le PE peut résoudre vos problèmes ? Et comment ? On va voir si tout le monde a intéret à l’implémenter dans son organisation Comment l’implémenter avec un REX sur comment on a mis en place un plateforme internet basée sur des opérateurs Kubernetes On détaillera les étapes de conception,
- #3: jai commencé dev, puis devops et aujourdh'ui platform eng j'ai travaillé chez tel et tel clients de différents tailles
- #5: TODO: delete slide
- #19: Talsk de Clément
- #34: Comment on s’y est pris, conception, pk on a choisi kube, et comment implementer un controleur