What Is Crossplane?

Chapter 1. Introduction

Crossplane is a framework for building cloud native control planes. When the founders of Crossplane at Upbound told me what they were working on in late 2018, shortly before the v0.1 release, I was very excited. I’d spent a lot of my career building cloud control planes from scratch. I loved the idea of an open source framework that baked in many best practices of control plane design and could be extended to control almost anything. I immediately joined the project and have been a maintainer since Crossplane v0.1.

A cloud platform is a distributed system, and distributed systems are often architecturally separated into two parts: control planes and data planes. The data plane is the system under control. It’s what provides direct business value. As for the control plane, it works like an air traffic control tower. This analogy is illustrated in Figure 1-1. The aircraft around the airport represent the data plane. The aircraft provide the business value—they move things—but the air traffic control tower is crucial to ensure they can do so safely and efficiently.¹

Figure 1-1. A control plane is similar to an aircraft control tower.

Amazon Web Services (AWS) is another example of control planes and data planes. AWS’s data planes are the virtual machines, databases, caches, and other services folks use to build products. Each of these services has a control plane that is responsible for starting, stopping, and configuring them. When you use the AWS console or call an AWS API, you’re interacting with one of AWS’s control planes.

You can also think of a cloud control plane as having a backend that orchestrates the data plane and a frontend that exposes an API. That’s where Crossplane comes in: it takes the Kubernetes control plane and makes both its backend and its frontend highly extensible. You can extend the backend to control any kind of system, and you can extend the frontend APIs to expose whatever concepts make sense for your organization. Figure 1-2 shows an engineer making an API call to the control plane’s frontend API and the control plane backend orchestrating a cloud provider.

Figure 1-2. A control plane has a backend that orchestrates the data plane and a frontend that exposes an API.

Imagine you’re part of the platform-engineering team at a growing technology company—say, a music streaming service. Your team supports 40 engineers who are split across 7 other teams. These teams deliver your company’s core product: streaming music. Perhaps they also work on social features or recommendation engines. Let’s call these folks product engineers. Most of your product-engineering teams want to use PostgreSQL databases to build their features, but they’re not experts in securing and scaling them.

Your team’s job, as platform engineers, is to make it safer and more efficient for the product engineers to do their regular tasks. This is a form of force multiplication: the platform engineers multiply the effectiveness of the product engineers.

How could you make it safer and more efficient for the product engineers to provision PostgreSQL databases?²

One option would be to have the platform team manage everyone’s databases. In this scenario, product engineers raise a ticket, and the platform team provisions a database for them. You use your database expertise to ensure you’re provisioning secure, scalable databases. Perhaps you use an infrastructure-as-code (IAC) tool like HashiCorp’s Terraform to automate the provisioning. This option is safe but not very efficient: it doesn’t scale well, because it puts the platform team in the critical path. It could be hours or days before you have time to service a request for a new database.

A second option would be to give the product engineers unfettered access to a cloud platform like AWS. This way, they can provision database instances themselves (self-service) by using the cloud provider’s CLI, web console, or API and a service like Relational Database Service (RDS). However, cloud services tend to offer so many configuration knobs that you need to be an expert in PostgreSQL and RDS to provision secure and scalable databases. This second option may be more efficient than the first, but it’s less safe—it would be easy for product engineers to make mistakes.

The sweet spot is your third option: to offer an RDS-like self-service platform of your own design. The product engineers can use a CLI, a web console, or an API to self-service their database needs just as efficiently as if they were using AWS. Because you design the platform yourself, you can bake safety in. You can also increase efficiency by customizing your platform’s concepts and configuration knobs to the product engineers. Embracing this approach is what differentiates a platform team from a more general infrastructure or devops team.

Crossplane is a framework that helps you build your self-service platform’s cloud control plane. You teach Crossplane what kind of APIs you want your platform to expose and what it should do when product engineers call those APIs. For example, Figure 1-3 shows a control plane configured to expose a SimplePostgres API and to create an RDS instance when a product engineer calls that API. This way, RDS does the heavy lifting of actually running the database, but you choose what configuration knobs are exposed and how they’re framed. Perhaps you don’t give the product engineers a choice of whether encryption at rest is enabled: it always is. Perhaps you choose to reframe AWS’s concept of instance types as a “small, medium, or large” choice. This is simpler to reason about, and it prevents product engineers from choosing unnecessarily expensive instances.

Figure 1-3. Configure Crossplane to reframe complicated cloud APIs using simpler concepts.

With Crossplane, you can build your platform’s control plane without needing to code it from scratch. This means you can build a bespoke platform much faster, while still tailoring it to your organization’s unique needs.

¹ The term data plane is an artifact of the concept’s origins in shared-memory multiprocessing research. In this context, the control plane and the data plane were distinct physical, geometric planes of switches (see Lawrie 1973, 76–87).

² Crossplane frequently uses database management as an example use case, but you can use Crossplane to build a control plane for any kind of platform. This example could just as easily be serverless functions or Kubernetes clusters.