tadata
Retour à l'accueil

Platform Engineering : Construire des Plateformes Developpeurs Internes

#platform-engineering#devops#developer-experience#kubernetes

Le platform engineering est la discipline de construction et de maintenance de plateformes d'infrastructure en self-service qui permettent aux équipes de développement de livrer des logiciels plus rapidement. Il est ne du constat que "you build it, you run it" ne passé pas a l'échelle sans les bonnes abstractions.

Pourquoi le Platform Engineering

ProblèmeSolution Plateforme
Chaque équipe reinvente ses pipelines de déploiementGolden paths standardisés
Les developpeurs attendent des tickets ops pour l'infrastructureProvisionnement en self-service
Sécurité et conformité inconsistantesGarde-fous intégrés dans la plateforme
Surcharge cognitive sur les developpeursComplexité abstraite
Shadow IT et prolifération d'outilsOutillage curate et supporté

Plateformes Developpeurs Internes (IDPs)

Une IDP est la somme de toutes les technologies et outils qu'une équipe plateforme fournit aux developpeurs :

Capacites essentielles :

  • Provisionnement d'infrastructure : bases de données, files d'attente, stockage -- en self-service
  • Gestion d'environnements : creer, cloner et detruire des environnements a la demande
  • Pipelines de déploiement : CI/CD standardisé avec les bonnes pratiqués intégrées
  • Observabilite : dashboards pre-configures, logging et alerting
  • Catalogue de services : decouvrir et consommer les APIs et services internes
  • Documentation : documentation technique centralisee, recherchable et a jour

La Plateforme comme Produit

Les équipes plateforme les plus performantes traitent leur plateforme comme un produit interne :

  • Les utilisateurs sont les developpeurs -- comprendre leurs besoins via des interviews et sondages
  • Roadmap produit -- prioriser les fonctionnalités selon les pain points developpeurs
  • SLAs -- definir des engagements de disponibilité et de support
  • Onboarding -- première expérience fluide avec golden paths et templates
  • Boucles de feedback -- check-ins réguliers, enquetes NPS, office hours
  • Mesurer l'adoption -- suivre l'utilisation, pas juste la disponibilité

Paysage des Outils

OutilCategorieCe qu'il fait
Backstage (Spotify)Portail developpeurCatalogue de services, docs, scaffolding, écosystème de plugins
CrossplanePlan de contrôle infrastructureProvisionner des ressources cloud via des CRDs Kubernetes
HumanitecOrchestrateur de plateformeSpecification de workload basee sur Score, config dynamique
PortPortail developpeurPortail developpeur interne avec actions self-service
KratixFramework de plateformePlateforme-as-a-product composable sur Kubernetes
Terraform/OpenTofuIaCProvisionnement d'infrastructure avec modules comme briques

Team Topologies et Équipes Plateforme

Le modèle Team Topologies (Skelton & Pais) definit quatre types d'équipes :

  • Équipes stream-aligned : livrent de la valeur sur un produit ou service
  • Équipes plateforme : fournissent des capacites self-service aux équipes stream-aligned
  • Équipes enabling : aident les équipes stream-aligned a adopter de nouvelles pratiqués
  • Équipes sous-systèmes complexes : possedent des domaines complexes necessitant une expertise spécialisée

L'objectif de l'équipe plateforme est de réduire la charge cognitive sur les équipes stream-aligned. La plateforme doit rendre la bonne chose facile et la mauvaise chose difficile.

Golden Paths

Les golden paths sont des chemins opines et supportés pour les tâches de développement courantes :

  • Template de nouveau service : repo pre-configure avec CI/CD, observabilite et manifests de déploiement
  • Provisionnement de base de données : création en un clic avec sauvegardés, monitoring et contrôle d'accès
  • Création d'environnement : lancer un environnement complet depuis une PR pour les tests
  • Réponse aux incidents : exécution automatisee de runbooks depuis le portail developpeur

Les golden paths sont recommandés, pas imposés -- les équipes peuvent devier, mais elles perdent le support plateforme.

Modèle de Maturité

NiveauDescription
1 - Ad hocPas d'équipe plateforme, chaque équipe géré sa propre infrastructure
2 - StandardisePipelines CI/CD partagés, templates de base, documentation partielle
3 - Self-serviceLes developpeurs peuvent provisionner l'infrastructure sans tickets
4 - OptimiseDecisions plateforme data-driven, gouvernance automatisee, forte adoption
5 - ProduitLa plateforme a une roadmap, des SLAs, de la recherche utilisateur et de l'amélioration continue

Ressources

:::

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.