What Is Crossplane?

Chapter 4. What You Can Build with Crossplane

So Crossplane is a pretty open-ended framework for building control planes. What, specifically, do we see platform engineers building control planes for? Let’s look at three examples.

A Service Catalog

One common use case is to build a service catalog—a smorgasbord of common cloud services that product engineers can choose to use. At one Fortune 100 company, each product-engineering team has their own AWS account and a lot of freedom to pick which services they use to build their products. The platform-engineering team uses a central, Crossplane-powered control plane to create a platform runtime in each team’s account. This runtime consists of common foundational infrastructure, like VPC networks and IAM roles. Once the platform runtime is in place, teams can choose to add services like Amazon OpenSearch, S3, and RDS, to name a few. The platform-engineering team appreciates the control plane approach because a control plane handles the entire lifecycle of the services they use—not just provisioning. They picked Crossplane specifically because it allows them to give their product engineers a lot of autonomy while enforcing their best practices using Compositions.

“Batteries Included” Kubernetes Clusters

Another problem I often see teams solving with Crossplane is “batteries included” Kubernetes cluster management. In this scenario, the platform-engineering team’s goal is to empower each of the product-engineering teams they support to provision the Kubernetes cluster they’ll use to run their product’s workloads. We say these clusters are “batteries included” because Crossplane automatically deploys and configures supporting software that makes the clusters more useful, like Argo CD, Prometheus, Fluent Bit, and Istio.

A platform-engineering team can build a control plane for “batteries included” clusters by pairing a Crossplane provider that can create, update, or delete clusters with Crossplane providers that can manage what runs in those clusters. For example, one Fortune 500 company uses provider-aws to create an EKS cluster with a few node groups and provider-helm to deploy the supporting software to the EKS cluster. From the product engineer’s perspective, all of this is abstracted behind an API request (i.e., a claim) for a standard Kubernetes cluster. The platform-engineering team can even update their Compositions to carefully add and tweak cluster features over time.

Your Own Application Model

Kubernetes is the most popular control plane for application code today. You package your code in an OCI container and use Kubernetes’s APIs to deploy and operate it. However, not everyone loves Kubernetes’s concepts and APIs. They’re frequently criticized as being complex and hard for product engineers to learn. This has led to the creation of application models like Open Application Model (OAM). Most application models are an abstraction layer atop Kubernetes that attempt to reframe its concepts in a developer-friendly, application-focused way. Indeed, the core API type in OAM is called “Application.”

Application models like OAM aim for more developer-friendly concepts and APIs than Kubernetes, but they’re still one-size-fits-all. An emergent pattern in the Crossplane community is platform engineers using Crossplane to build application models that are tailored to their organizations’ needs. These application models might use provider-helm to deploy an application’s code to Kubernetes and provider-aws to deploy its infrastructure dependencies such as databases and queues. The models themselves—the abstractions—are Crossplane claims.

Keep in mind that these are just three examples of control planes built with Crossplane—there are many more. Take a look at the Crossplane ADOPTERS.md file for more inspiration. It lists organizations that have publicly adopted Crossplane with a brief description of what they’re building control planes to do.

Conclusion

I hope this report has given you a better understanding of the value of cloud control planes. I also hope you feel some of the excitement I felt when I first learned about Crossplane! Having spent much of my career as a platform engineer, I believe being able to build bespoke control planes without having to start from scratch is a game changer for engineering productivity.

If you’d like to learn more about Crossplane, their website is the best place to start. From there, you can find our “getting started” documentation and our active Slack community. Another great resource is the Upbound Marketplace. In particular, deploying one of the featured Configuration packages is a great way to try Crossplane out. If you’re an AWS customer, you’ll also want to check out the Blueprints for Crossplane put together by the folks at AWS.