The First Guide to Crossplane That Actually Makes Sense

There’s no denying that shifting left accelerates engineering teams. And Crossplane is at the forefront when it comes to facilitating self-service infrastructure.

Which is why today we’ll have a look at Crossplane and its concepts.

I’ll try to keep things light (promise), since it’s easy to get confused when you’re starting out with Crossplane.

But first…

What is Crossplane?

As taken from Upbound’s website, Crossplane is “The cloud native control plane framework”.

Crossplane allows you to build control planes without needing to write code. It has a highly extensible backend that enables you to orchestrate applications and infrastructure no matter where they run, and a highly configurable frontend that lets you define the declarative API it offers.

Translating it into plain English, it enables you to build your own self-service platform that can be used by your internal teams – as well as your customers.

Think AWS, but for your company’s offering.

Core Crossplane concepts

As I’ve said before, Crossplane is a tool for making blackboxes. The central piece to the blackbox is the API it offers to the end-users.

While our end users need not to know how the blackbox is constructed, we, as its creators, do.

Crossplane uses the concepts of:

• Providers,
• Managed Resources (MRs),
• Compositions,
• Composite Resource Definitions (XRDs),
• Composite Resources (XRs), and
• Composite Resource Claims (XRCs),

all of which I’m going to cover briefly.

What are Crossplane Providers?

In Crossplane, providers are responsible for connecting to and managing external infrastructure services. Similar to Terraform providers, Crossplane providers act as the bridge between the platform and the resources you want to manage.

Providers abstract away the details of interacting with various cloud providers or other infrastructure services. Each provider in Crossplane is a modular unit that enables you to extend Crossplane’s capabilities to work with different APIs and services.

What are Crossplane Managed Resources?

Managed Resources are representations of the desired state of a particular cloud or infrastructure resource. They play a crucial role in the Crossplane architecture, and their concept is closely related to the notion of resources in Terraform.

Essentially, Managed Resources define what you want to provision and manage within your infrastructure.

When declaring a Managed Resource, you’re specifying the characteristics and configuration of a resource, such as a database, virtual machine, or storage bucket.

This declaration includes provider-specific settings, such as resource type, its configuration, and any other relevant parameters.

It’s a way of telling Crossplane “I want a database in with these specifications”, or “Provision a virtual machine with these attributes” – all tied to the specific provider used.

This brings us to Compositions.

What are Crossplane Compositions?

Compositions in Crossplane are a powerful abstraction that enables you to encapsulate and reuse configurations for sets of resources.

Think of compositions as a way to create modular and reusable building blocks for your infrastructure, similar to how you might use modules in Terraform.

When you’re working with Crossplane, you don’t typically create individual Managed Resources directly. Instead, you define Compositions that bring together one or more Managed Resources along with their configurations. These Compositions act as templates or blueprints for creating higher-level abstractions of your infrastructure.

As such, Compositions provide a way to encapsulate and logically group related resources together.

For example:

You might have a Composition for a microservices application that includes Managed Resources for databases, virtual machines, and networking components.

What are Crossplane Composite Resource Definitions (XRDs)?

Now, Composite Resource Definitions are where the real magic begins.

This is also where Crossplane goes beyond what’s possible in Terraform.

Composite Resource Definitions (XRDs) in Crossplane are the blueprints for creating custom infrastructure abstractions.

They extend Crossplane’s capabilities by enabling you to define new types of resources that align with your specific infrastructure requirements (i.e. beyond Managed Resources alone).

XRDs define the API used to create a composite resource. An API specific to your business.

What are Crossplane Composite Resources (XRs)?

To actually make use of the XRDs, we have to instantiate them into Composite Resources.

Composite Resources in Crossplane are instances of Composite Resource Definitions (XRDs). They represent the actual, concrete resources that Crossplane manages on your behalf.

But wait.

If XRDs are the API, how does Crossplane know which resources to provision?

Using Compositions.

Aha!

Now the cool thing about Compositions & Composite Resources is that a Composition is just a particular way to satisfy the need for the Composite Resource.

The end user is given an API, a blackbox, and wants to use it as such. There may be a multitude of options to fulfill their needs.

Different environment options? Check.

Different cloud provider? Check.

Now, before we have a look at a Real World™ example, let me wrap up by quickly telling you about Composite Resource Claims.

(Bonus) What are Crossplane Composite Resource Claims (XRCs)?

Composite Resource Claims are similar to Composite Resources in that they both allow you to provision resources described by the XRD. The difference is how you’re requesting those resources.

Composite Resources are cluster-scoped, while Composite Resource Claims are namespace-scoped.

As such, this distinction allows you to delineate responsibilities between platform and app teams – which together with sensible RBAC rules facilitate the self-serve aspect of infrastructure.

Real-world example

Imagine you have an app which consists of a fleet of web containers, a database and a cache.

You want to be able to provision lots of small dev environments, using arbitrary revisions of code.

You want to do so without waiting 10 minutes for an AWS RDS database to provision. And without high availability. And in dev the cache is actually not needed.

At the same time, your production environment definitely needs an autoscaled fleet of beefy instances, use every opportunity to cache data, and uses a managed database instead of an ephemeral one.

Crossplane implementation

You can satisfy these needs easily by defining an XRD which accepts revision as parameter and 2 Compositions, which implement each scenario.

The dev Composition, which creates all the resources as ephemeral containers in the development Kubernetes cluster.

And the prod Composition, which configures all the bells and whistles needed to serve sustained production traffic and stores data in an AWS RDS database.

Finally, developers can easily request new app environments without burdening the ops team, simply by specifying that they want a dev Composite Resource.

Now, say your requirements change.

You now have a new customer, that wants to deploy your app on their existing GCP infrastructure.

To accomodate that, you can create another Composition, which uses GCP’s Cloud SQL instead of AWS’s RDS.

And all of that, while keeping a simple, unified API.

The bottom line

Shifting left is about giving access to those higher-level building blocks while shielding the users from their internal implementation’s complexity – and Crossplane takes the lead in democratizing infrastructure accross your organization.

By providing self-service capabilities, you can enable your teams to provision, modify, and scale their infrastructure independently, reducing bottlenecks and accelerating the development process.

If you want to explore how a new platform can boost your teams’ productivity contact us today and let’s build your platform together.