PROTOCOL_ID: XP-07 CLASS: CONTROL_PLANE_DELIVERY
Crossplane Consulting
We design and ship the control plane, alongside your engineers, not instead of them.
Difficulty: 3 / 3
Engagement overview
An engagement starts with the question most Crossplane projects skip: what should a developer have to know? Every composition you write is an answer to that. Get it right and a team ships a database by declaring six lines. Get it wrong and you have rebuilt Terraform with more YAML and a reconcile loop.
From there we build. Composite resource definitions that model your domain rather than the cloud vendor's, compositions that stay legible after the third requirement change, and provider configuration that survives credential rotation. Where the provider you need does not exist, we write one. We have done that for OVHcloud and documented the whole path publicly.
Delivery runs through GitOps, because a control plane that drifts is worse than no control plane. Argo CD reconciles the compositions, Kyverno holds the policy boundary, and every change your platform team makes is a reviewable commit. Your engineers pair with ours throughout, so the knowledge stays in your building when we leave.
Illustrative schematic, not live telemetry
Tools in this engagement
Tools in this engagement
- Crossplane
- crossplane-cli
- Argo CD
- Kyverno
- Kubernetes
- Go
From assessment to production
- 01
Domain modelling
Map what your teams provision today and which of it deserves an API rather than a ticket.
- 02
XRD and composition design
Define the developer-facing contract first, then the composition that satisfies it. Not the other way round.
- 03
Provider work
Configure upstream providers, or build a custom one where your platform depends on an API nobody has covered yet.
- 04
GitOps delivery
Wire reconciliation, policy and promotion so the control plane cannot drift away from what is in Git.
- 05
Production hardening
Failure modes, upgrade path, and what happens when a composition is wrong at three in the morning.
Ecosystems, tooling, and deliverables
| Target ecosystems |
|
|---|---|
| Tooling |
|
| Deliverables |
|
| Prerequisites |
|
Straight answers
Frequently asked questions
What do we actually have at the end of an engagement?
Composite resource definitions that model your domain, reviewed and documented compositions in your own repository, a GitOps pipeline with policy guardrails, and a custom provider where the ecosystem had a gap. The real deliverable is a team that can extend all of it without calling us.
Our cloud has no Crossplane provider. Can you write one?
Yes. We did it for OVHcloud and documented the whole path publicly, so you can read how we work before hiring us. Provider authoring is part of the delivery engagement whenever your platform depends on an API nobody has covered yet.
How do you stop compositions becoming unmaintainable?
By deciding the developer-facing contract before the composition that satisfies it, not the other way round. Every field you expose is a promise you maintain, so the boundary is drawn deliberately and defended. Delivery then runs through GitOps, with Argo CD reconciling and Kyverno holding the policy line, so nothing drifts away from Git.