We recently announced some updates to the Crossplane project last week as part of our Control Plane Day with Crossplane, presented by Upbound (recordings available soon). We wanted to take the opportunity to explain these changes with a bit more detail and context so the community can better understand the intent and direction. At a high level, the announcements were:
- Charter expansion: The charter of the project was expanded to enable the project to support a broader range of scenarios and use cases.
- Upjet provider donation: The Crossplane steering committee voted to accept the donation of Upbound’s provider framework (Upjet) as well as key Crossplane providers for the major cloud providers.
The overall goal for both of these updates was to make the project more complete in its end-to-end support of building cloud native control planes and to increase widespread adoption of the Crossplane project.
An Easier to Use Crossplane
It’s critical to the success of the Crossplane project to be in touch with the reality of the experience the community has during their adoption journey. We’ve been receiving pretty consistent feedback that while people find Crossplane to be a powerful and reliable technology for building cloud native control planes, it can be a difficult path to start learning Crossplane and get to a successfully built production-ready control plane.
A major reason for this learning curve is the lack of supporting tools and experiences on top of core Crossplane that could accelerate the community’s attempts to successfully build platforms on Crossplane. These higher level experiences had not previously been a focus for the project as we started with a smaller scope to build the core APIs and machinery and make them highly reliable.
Now that Crossplane has matured to a state where it is used in many production environments, we can start tackling a broader focus. In an effort to address the usability gaps, the Steering Committee officially expanded the project charter with the addition of two high-level functional areas:
- Providers and other integrations to cloud and infrastructure offerings that enable resources to be provisioned and managed.
- Developer experience investments such as tooling, interfaces, and experiences that facilitate building, managing, and consuming a control plane.
We’ll discuss providers more deeply in the next section, so let’s focus on all of the developer experience improvements first. If you’ve used Crossplane over the last few years, you’ve probably had some frustrations while authoring your compositions or debugging an unhealthy resource in your control plane. The project is now poised to directly address these challenges and make Crossplane much easier to use with a set of exciting investments in developer tooling!
Let’s look at some of the highlights for the Developer Experience roadmap:
- CLI: The Crossplane CLI will get a wealth of new commands and functionality, such as diagnosing unhealthy resources and helping you test your compositions locally during development.
- Language Server: We’ll build a language server that deeply understands the Crossplane API and development process and can give you expert feedback to avoid errors and improve your compositions.
- Shift Left: In general, we’ll “shift left” the validation of your platform to make that as early in the development cycle as possible. Think about all the time you can save by being told about an error in your composition as you’re building it instead of when it’s behaving incorrectly on a live cluster in production!
Upjet and providers are now part of Crossplane
As previously announced by Upbound, they have donated to the Crossplane project their entire Upjet provider framework as well as key Crossplane providers for the major cloud providers. This is a big win for the community as that technology makes the move from being a vendor-driven project (under Upbound’s CLA) to being completely owned and driven by the CNCF and Crossplane community. This move for Crossplane providers to be managed entirely by a trusted foundation enhances the long-term viability of Crossplane.
Upbound made this contribution with the goal of ensuring the long term sustainable health and success of the Crossplane ecosystem so that it continues to remain an open platform to build on. To be clear, this is a governance change at its core. It essentially prevents Upbound from being able to change its mind in the future and re-license to something more restrictive. Currently, Upjet and the providers it generates use the permissive Apache 2 license, and through this donation to the CNCF the licensing must remain that way in the future. This move makes Crossplane the only complete cloud automation solution governed entirely under a foundation.
No migration will be necessary as a result of this move, which makes this donation painless to absorb for the existing users of these providers. Everything remains the same within these providers with the exception of their new source code location. The schema, API groups, etc. will remain untouched, thereby causing no impact or migration effort for existing control planes.
Opportunity for convergence
Providers being an official component of the Crossplane project enables a provider ecosystem that is managed by the project itself. The ecosystem of Crossplane providers has some fragmentation and in some cases there are multiple provider options for a single targeted offering, e.g., AWS. This has caused confusion amongst the community about the differences between the providers, which provider to use, etc. Now that providers are part of the project, we can work as a community to converge upon single provider implementations that we can all rally around. Any effort to converge would be an open discussion in a collaborative fashion amongst the community.
The crossplane-contrib organization on GitHub will remain a point of collaboration for providers (and other projects related to Crossplane) with neutral governance. Multiple providers can reside within that organization as the community invests in their development. As an effort around convergence progresses, it will be possible to select a curated set of providers that are formally endorsed by the project and move them to the main crossplane GitHub organization. Converging upon a set of endorsed providers for the project will greatly reduce confusion about which providers to use, but we won’t get to that destination without involvement and collaboration from the entire community.
Executing on the expanded charter
These are very exciting times for the project as it continues to grow and cover new ground. Crossplane feels more complete than ever now and we’re hoping the steps we’ve taken to expand the project will smooth the adoption journey for all our users.
Going forward, there are new opportunities we encourage the community to participate in:
- Join the regular community meetings to discuss provider convergence opportunities.
- Join the newly formed SIG-DevEx to collaborate on making Crossplane easier to use.
As always, we also welcome you to contribute through a variety of other opportunities, such as opening and commenting on issues, joining sharing your adoption story, and providing feedback on design docs and pull requests.
We love to hear from the community, as they are exactly what makes this project great.
Whether you are a developer, user, or just interested in what we're up to, feel free to join us via one of the following methods: