Aller au contenu
edixos
Tous les services

PROTOCOL_ID: XP-06 CLASS: CONTROL_PLANE_ENGINEERING

Services Crossplane

Nous construisons le control plane, puis formons votre équipe à le tenir.

Difficulté: 3 / 3

Services Crossplane — Nous construisons le control plane, puis formons votre équipe à le tenir.
Vue d'ensemble

Vue d'ensemble

Crossplane transforme l'infrastructure en API Kubernetes. Au lieu d'une file de tickets et d'une page de wiki, vos développeurs déclarent une ressource, et votre équipe plateforme dispose d'un control plane qui la réconcilie. L'idée est simple. La tenir en production, sur plusieurs clouds, avec la bonne frontière d'abstraction, ne l'est pas.

C'est sur cette frontière que la plupart des projets Crossplane échouent. Trop peu de composition et vous avez publié des primitives cloud brutes avec des étapes en plus. Trop de composition et chaque nouveau besoin impose de modifier une composition que personne ne comprend. Nous avons tracé cette ligne sur de vraies plateformes, y compris en écrivant un provider pour une API qui n'en avait pas, et nous apportons l'expérience plutôt qu'une architecture de référence.

Deux façons de travailler ensemble. Nous construisons le control plane avec vous, ou nous formons vos ingénieurs à le construire eux-mêmes. La plupart des équipes veulent les deux, dans cet ordre, et c'est pourquoi ce sont des missions distinctes plutôt qu'un forfait unique.

Schéma d'une voie balisée du commit à la production

Schéma illustratif, hors télémétrie réelle

Outils de cet engagement

Outils de cet engagement

  • Crossplane
  • Kubernetes
  • Argo CD
  • Kyverno
  • Terraform
  • Helm
Trajectoire de livraison

De l'audit à la production

  1. 01

    Évaluation de pertinence

    Déterminer si Crossplane est la bonne réponse à votre cas. Parfois non, et nous le disons avant toute signature.

  2. 02

    Conception de l'abstraction

    Décider ce que vos développeurs déclarent et ce qui reste masqué. Ce choix détermine tout ce qui sera construit ensuite.

  3. 03

    Construire ou former

    Basculer vers une mission de delivery, un parcours de formation, ou les deux, selon où votre équipe veut que la connaissance réside.

  4. 04

    Transfert

    Laisser votre équipe capable d'étendre le control plane sans nous appeler. C'est cela le livrable, pas les compositions elles-mêmes.

Spécification technique

Écosystèmes, outillage et livrables

Écosystèmes cibles
  • AWS, GCP, Azure, OVHcloud, Scaleway
  • Clusters Kubernetes existants ou cluster de control plane dédié
  • Parcs hétérogènes où aucun provider ne couvre tout
Outillage
  • Crossplane
  • Kubernetes
  • Argo CD
  • Kyverno
  • Terraform
  • Helm
Livrables
  • Un control plane que vos développeurs utilisent vraiment
  • Des compositions et XRD que votre équipe sait lire et étendre
  • Le runbook opérationnel qui va avec
Prérequis
  • Un cluster Kubernetes que vous acceptez de traiter comme de l'infrastructure
  • Des accès cloud dimensionnés pour le provisioning
  • Un référent plateforme capable d'arbitrer la frontière d'abstraction
Missions

Les façons de travailler ensemble

Réponses directes

Questions fréquentes

Avons-nous vraiment besoin de Crossplane, ou Terraform suffit-il ?

Terraform suffit tant que les changements d'infrastructure restent ponctuels et portés par un petit groupe. Crossplane prend son sens quand les développeurs doivent provisionner eux-mêmes et qu'il faut réconcilier le résultat en continu. Notre première phase est une évaluation de pertinence, et si la réponse est non, nous le disons avant toute signature.

Faut-il commencer par le conseil ou par la formation ?

La plupart des équipes veulent les deux, en général dans cet ordre : nous construisons le premier control plane avec vous, puis nous formons le groupe élargi à l'étendre. Ce sont des missions distinctes plutôt qu'un forfait, pour que vous puissiez vous arrêter après l'une ou l'autre, ou commencer par la formation si vos ingénieurs préfèrent construire eux-mêmes.

Quels clouds couvrez-vous ?

AWS, GCP, Azure, OVHcloud et Scaleway, sur des clusters Kubernetes existants ou un cluster de control plane dédié. Les parcs hétérogènes où aucun provider ne couvre tout sont le cas normal plutôt que l'exception, et quand le provider nécessaire n'existe pas encore, nous l'écrivons.

Notes techniques

La preuve par la production

Soumettez-nous votre problème de plateforme le plus difficile

Réserver un échange