Upbound founded Crossplane to help you build cloud control planes. These control planes sit one level above the cloud providers and allow you to customize the APIs they expose according to the needs of your organization. Platform teams at leading enterprises are increasingly adopting Crossplane to offer their developers simpler, safer, self-service interfaces to the cloud.
Crossplane is an open-source project incubating with the Cloud Native Computing Foundation (CNCF). It’s built on Kubernetes, making it a great fit for organizations that have embraced cloud-native tools and practices.
Crossplane has the notion of providers that are the glue between Crossplane and external APIs, such as AWS and Azure. This glue takes a different shape for almost every resource in those APIs, so you need custom implementations in most integrations.
A typical new Crossplane user starts their journey by installing Crossplane and playing with the provider they use at their company. After the initial prototyping step, folks go to the API reference of a given provider to see if it includes support for all the cloud resources they use. At this point, we see many users drop out because of the lack of coverage. Unfortunately, it’s usually zero or one — they don’t use Crossplane even if only 10% of the infrastructure of a given application is not covered because you don’t want to have two ways of orchestrating the cloud infrastructure. We call this the provider coverage problem, which is present in every infrastructure provisioning tool that has come so far, like Terraform, Ansible, etc.
The Crossplane community has been adding CustomResourceDefinitions (CRDs) to cover the API surface, but the pace is unable to catch up with users who are blocked from getting into production with Crossplane due to the lack of coverage. To give you an idea, AWS has ~1000 resources and the classic AWS provider has yet to cover ~200 as of writing.
At Upbound, we have concluded that even though we are able to re-use many utilities across the providers, it won’t scale to implement support for every CRD one by one. We should stand on the shoulders of what has come before.
The first iteration of this conclusion was Terrajet — a code generation framework for CRDs and a generic controller that runs Terraform under the hood. But Terraform doesn’t have all the metadata we need to satisfy the Crossplane Resource Model (XRM) experience that we’re all used to. We came up with a configuration framework in Go that allowed providing additional metadata that can scale to many implementations.
In fact, we experimented with having just the default configs for all resources and it resulted in thousands of working CRDs which was a first in the Kubernetes community! This uncovered bugs in the Kubernetes API server that would appear only when you reach that scale. We worked closely with API Machinery team to provide patches to accommodate that scale. More on this here.
Upjet is the second generation of this approach that is more stable, has more customization points, and includes new code generators that enable automatically generating API documentation and example YAMLs ready to be used as well as inferring metadata configurations from the Terraform documentation such as cross-resource references so that the providers get to be production-ready with much less effort and time. Provider maintainers can replace Terrajet with Upjet with minimal code changes to utilize these new features. Our first set of Upbound Official Providers — AWS, Azure, and GCP — that Upbound uses to meet SLAs to its customers are all built on Upjet, contributing to its stability.
Official Providers are production-ready Crossplane providers that are authored or maintained by Upbound. As a vendor, Upbound can provide support and SLAs around using Official Providers, giving customers peace of mind. They have the highest number of CRDs at the v1beta1 quality level and are tested continuously using real cloud provider endpoints. The first set contains the big three cloud providers (AWS, Azure, and GCP), and we are continuously expanding the program to cover more APIs and infrastructure providers.
As of writing, Official Providers have the highest coverage of the big three Cloud APIs in the Crossplane ecosystem.
With these ever-growing numbers, you can use these Official Providers to orchestrate your most complex scenarios. In addition to production-level quality, the Upjet-based providers have extended coverage of given APIs, i.e. more fields and features are supported in the CRDs compared to other providers. This is achieved by relying on mature Terraform providers under the hood that have already implemented most, if not all, features of a given API.
Great power comes with great responsibility. With so many APIs to deal with, it’s essential that we keep the complexity under control and don’t introduce regressions. To do this at scale, we have developed a new tool called Uptest that deploys the resource into a cluster, makes sure it gets to a ready state, and that the removal succeeds. Over time, we will add more scenarios to build even higher confidence levels.
With Uptest in place, all official provider CRDs are at v1beta1 maturity — meaning they are safe to use in production, and we guarantee that even if there is a breaking change, it will be handled automatically by a standard Kubernetes webhook.
One of the concerns we had with Terrajet was the cases where the underlying Terraform provider may not provide a high-quality implementation for a given resource and we may end up stuck with it till the upstream fix is accepted. In Official Providers, we can add custom implementations, in addition to generated ones, whenever the need arises. ClusterAuth in AWS EKS is a good example where we added a manual implementation to cover the authentication story of AWS EKS in a way that provides ever-refreshing tokens through its connection details secret.
We want to provide the best experience for users getting started with Official Providers. A big step towards this goal is having examples for every resource. You will see that every CRD in our Official Providers has at least one example, and Uptest tests all examples you see continuously to make sure they are always up-to-date. See AWS VPC here with 19 examples!
In addition to examples, official providers have a high bar that all fields in the API reference of a given CRD should have as much documentation as possible. To see the rich experience, see AWS EKS Cluster API Reference here. With Upjet, this is automated, and future Official Providers will have this as well.
At Upbound, we talked with many customers and uncovered that while having a community around providers is great, many companies want formal support from a vendor. With Official Providers, Upbound supports its customers with timely fixes and provides patch releases immediately! All fixes we will be doing for our customers will land on the same repository.
Official Providers are released under the Apache 2.0 license, just like Crossplane. We encourage everyone to play around with them, ask questions in Slack, and feel free to contribute. We were delighted to see a community contribution even on the launch day!
We have a comprehensive guide that will help you migrate your existing resources to official providers. In addition, we are working on a new tool that will create a migration plan, let you edit specifics when necessary and execute it; making it a breeze to migrate to official providers!
Keep an eye out for the next release since Official Providers are released every week! In the coming weeks, we’ll see more CustomResourceDefinitions added, and you can expect them to reach full coverage soon, all the while providing the same high-quality level. In addition to increasing the coverage, we are getting close to the first Crossplane providers with “v1” CRDs!
Note: If you're interested in working on these with us, view our open roles here.
Subscribe to the Upbound Newsletter