8 reasons why Crossplane is the ideal engine for internal developer platforms

Crossplane is a Kubernetes-native framework that allows organizations to manage anything using a consistent API and runtime, making it an ideal foundation for Internal Development Platforms (IDPs). 

Organizations typically run a complex mix of cloud and on-premise resources like databases, virtual machines and network policies. IT teams must support multiple platforms to provision and manage resources, resulting in time-consuming manual processes or user-hostile and brittle home-grown systems.

Using a control plane architecture, Crossplane allows any organization to run an internal self-service cloud platform with a standard API and runtime like the major cloud providers.

Here are eight reasons why engineers building platforms should use Crossplane.

1: Platform API

One of the most important features of any platform is the API. Unfortunately, most infrastructure tooling is designed for engineers working on the command line. Crossplane is an API-first system, building upon Kubernetes Custom Resource Definitions (CRDs) to allow engineers building platforms to dynamically define new APIs called Composite Resource Definitions (XRDs) that are available to end users.

With Crossplane XRDs, platform engineers can easily create new APIs using an OpenAPIv3 schema. XRDs are Kubernetes objects just like Pods and Secrets. API fields can be validated using either OpenAPI data types or the Common Expression Language. For example, an API designer can set a minimum and maximum number of cluster nodes, limit a serverType to “small”, “medium” or “large”, force a username to match a regular expression pattern, or set transition rules so that database sizes can only increase.

XRDs can be created and updated by applying manifests to the cluster and are immediately available for consumption. Since XRDs are served from the Kubernetes API server, virtually all your existing Authentication, CI/CD, and Security tooling will work with XRDs out of the box. Crossplane deployments are often combined with tools like ArgoCD, Backstage and Kyverno. 

2: Provision Anything With Providers

Crossplane Providers are responsible for communicating to API endpoints. A Provider consists of a CRD for each Cloud API and a controller that manages resources. This architecture allows platform operators to select which resource types are supported for provisioning.

To prevent drift, Providers reconcile Managed Resources continually, comparing them to the desired state and automatically resolving any differences found.

In the Upbound Marketplace alone, there are over 60 published providers, including the major cloud providers along with other services like ArgoCD, Aviatrix, GitLab, and New Relic. To ease migration to Crossplane, Provider-terraform allows operators to run existing Terraform modules in a Crossplane-native manner inside Compositions.

Providers are built upon standard Kubernetes libraries like controller-runtime, giving advanced organizations the ability to write their own providers using well-supported tooling.

Finally, to accelerate Provider development, Upjet allows programmers to automate the creation of new Crossplane providers from existing Terraform providers. Upjet bypasses the Terraform CLI, offering significant performance improvements.

3: Observability for Every Resource

Internal Cloud Platforms can scale up quickly, managing tens of thousands of Managed Resources across multiple Clusters. For platform operators, having insights into Crossplane and the resources it manages is critical. As expected, all Crossplane components export performance metrics via a Prometheus endpoint. But Crossplane is capable of insights that exceed what is available from commercial offerings, answering questions like “how long does it take to provision a database in AWS?”

Virtually every resource in Crossplane is a unique Kubernetes object with its own Status, Conditions, and Events. Instead of having to parse a state file to get the status of resources, platform operators can query the Crossplane cluster using standard tools like kubectl.

And with addons like the x-metrics project, metrics can be generated from individual Composite and Managed Resources, allowing platform operators to use tools like Grafana to visualize metrics like Ready state and how long each resource takes to provision. With Crossplane, platform teams can define and track service levels of the infrastructure they manage across multiple clusters and environments.

4: Composition Functions

One of the major new features in Crossplane is Composition Functions. These small programs that template Crossplane resources are a significant new development in infrastructure provisioning and have been rapidly adopted by the Crossplane community.

Traditionally, most infrastructure engineers were forced to choose between inflexible static files like YAML, limited configuration languages found in Infrastructure as Code (IaC) tools, or the complexity of full programming languages.

There are two major innovations present in Crossplane functions. First, functions focus on infrastructure data, leaving other Crossplane components to manage provisioning. A function only needs to take the existing Observed and Desired state of resources and output a Desired state.

The second major innovation in functions is the runtime environment. Crossplane runs functions in a series of steps similar to Unix pipelines. Functions get and send data in standard gRPC messages, allowing functions to be written in any language. SDKs in Go and Python remove almost all boilerplate, so function authors can implement custom logic with only a few lines of code.

Fortunately, many organizations will not need to write their own functions. Since Crossplane functions are packaged in standard OCI images, it is easy to run published functions. The Composition function ecosystem is growing quickly, allowing users to create desired states in multiple ways such as Patch & Transform, Go Templating, KCL, and CUE Lang. 

5: Workload Identity Built In

Infrastructure provisioning systems can present a significant security risk, as they require elevated credentials. IT teams often provision resources out of systems that have a single account with wide permissions and shared hard-coded credentials that are not rotated.

Since they run as Kubernetes pods, Crossplane Providers can utilize the built-in Workload Identity trust mechanisms available in Amazon EKS, Azure AKS, and Google GKE. IAM roles can be mapped to individual Provider service accounts, enabling least-privilege, auditability, and credential rotation.

Platform operators can configure Crossplane ProviderConfigs to assume different roles at a Managed Resource level, allowing each team or organization to provision using their own accounts on the same cluster. And, where supported, Workload Identity can be set up so that Crossplane Providers can communicate securely between cloud providers like AWS and Google Cloud Platform (GCP).

6: Shift Development and Testing Left

“Shift left” is the practice of moving testing and validation to earlier in the development process. The Crossplane CLI can render and validate Composition Pipelines, allowing developers to test changes in their local development environments. Continuous Integration systems like GitHub Actions can check and test Compositions during the Pull Request Process. End-to-end frameworks like Uptest and xp-testing create live infrastructure and ensure that provisioning is successful.

Platform operators can quickly debug live systems using the crossplane trace command to view the status and dependencies for many Crossplane resources in the terminal.

7: Leverage Existing Kubernetes Expertise

Crossplane can run almost everywhere Kubernetes does, from the developer desktop to large cloud-based clusters. Applications and infrastructure can be deployed using the same platform, accelerating time to value. Organizations that have invested in Kubernetes tooling and training will find Crossplane a natural enhancement of their existing environments. 

8: Open Source with Community and Vendor Support

After 5 years of development, the strong growth and adoption of Crossplane has made it a candidate for CNCF graduation. Crossplane is licensed under the Apache 2.0 license, copyrights and trademarks are owned by the CNCF, and the project has strong governance.

Public Crossplane adopters include Nike, Autodesk, Grafana, NASA Science Cloud, Novo Nordisk, SAP, IBM, VMware Tanzu, and Nokia. The Crossplane Slack has over 10,000 members, and hundreds of developers are working on Crossplane-related open-source projects.

Vendors like Upbound, AWS, and Accenture provide 24×7 commercial support and Professional Services around Crossplane. 

Crossplane is for Platform Engineers

Crossplane was built to support organizations creating self-service internal clouds. With low-code infrastructure APIs, powerful functions, a large and growing Provider ecosystem, and tooling for developers and operators, Crossplane is a comprehensive framework and one of the leading projects adopted by platform engineers. Join the community at crossplane.io.