This article was originally posted on The New Stack.

Crossplane was one of the most discussed topics of KubeCon + CloudNativeCon North America 2022. It was mentioned in keynotes and talks, and the surrounding chatter was all over the show floor.  Crossplane is being deployed in production across Global 2000 organizations, and at KubeCon companies like Grupo Boticário, Adobe, and Autodesk shared how they are adopting Crossplane.

For those who might not be familiar, Crossplane is a framework to build internal cloud platforms using control planes.

Control Plane-Powered Platforms

You may be asking, “Why should I use control planes?” Let’s start with the big picture. Every bigger company has some kind of internal “cloud, DevOps, platform” organization. Let’s call them the “platform team.” They manage the operations and consumption of public clouds and internal services. After the first wave of automation with Infrastructure as Code (IaC) tools, these platform teams have realized that a pure IaC approach is not sufficient, as they often fail to address two fundamental problems:

• How do we govern infrastructure and services in a central place to ensure they are used efficiently and in compliance with our security and other standards?
• How do we unblock development teams and enable self-service that doesn’t require deep Infrastructure as Code knowledge?

Various approaches have attempted to tackle these objectives and promised self-service with a single pane of glass at reduced costs. But all the offerings have trade-offs: They lock platform teams into a particular technology or infrastructure vendor, and they are too opinionated about the layer of abstraction provided.

The missing ingredient here is a control plane. A control-plane-based architecture gives you a declarative approach to defining and managing resources, a continuous reconciliation to eliminate configuration drift and offer a single point of control for concerns like policy enforcement and permission management.

Which brings us back to Crossplane, an open source framework that runs on top of Kubernetes to build platforms using a control-plane-based architecture. Let’s see how that is actually done.

Building a Platform with Crossplane

Building and using a Crossplane-based platform involves three major steps: Connect to the resources you want to manage, Compose the different resources into a custom API for your team, and finally Consume those resources by developers:

Connect to the Cloud with Providers

The first step for a platform team is to connect to the Cloud APIs they would like to offer internally. With Crossplane, this involves creating a custom resource definition (CRD) and running a controller that makes the respective API calls. These specific CRDs are called managed resources and are bundled into a specific Crossplane provider.

It’s been a consistent message in the community that the quality and coverage of providers is important to their adoption of Crossplane. There are hundreds of contributions and open source listings available, but it’s often unclear which ones are the highest quality, and it’s becoming increasingly more difficult to discover the latest or more relevant contributions.

It’s because of this that Upbound created The Upbound Marketplace as the one-stop shop for all things Crossplane, including official providers and other listings. It’s a great place to see what’s happening with the project. The marketplace offers users:

• A catered place to host Crossplane packages.
• Auto-generated API documentation for packages published to it.
• An easy way to find and learn about different Crossplane extensions and how to use them.
• Upbound Official providers: a set of Crossplane providers that are maintained, tested and supported by Upbound.

As of today, the marketplace offers 1,182 cloud resources to choose from. This goes from the usual suspects of Amazon Web Services (AWS), Google Cloud Provider (GCP) and Microsoft Azure over to smaller cloud providers such as Civo, DigitalOcean and Equinix, but also other “special” providers such as Kubernetes, Helm or even Terraform and Ansible. Upbound has released a first set of official providers and made them available to the whole Crossplane community.

Additionally the community keeps contributing many providers. We will continue to support this effort and if you want to generate a provider for your API, please see Upjet as a great tool to generate a provider.

Compose by Patching Resources

With so many services at our disposal, it’s now time to move to our next step: compose. With Crossplane, you don’t expose the raw API to developers. Instead, you provide a tailored API in what we call a Composite Resource Definition (XRD). So instead of giving a developer a raw PostgresSQLInstance, you set guardrails by providing a tailor-made XPostgreSQLInstance. Now the developer can only change the options you’ve enabled and the platform team has permitted; the rest is pre-defined and ready to use.

For this new API to come into reality, you need to build a composition by configuring a set of resources and combining them. This is what we call patching, and you can see the XPostgreSQLInstance as an example. Combining a set of resources is very powerful and fun (as fun as YAML goes ;-). So, the next big step for the Crossplane community is to come up with new and exciting APIs by creating some patches.

The last patch I’ve created was a digital twin for a ship. So, I’d like to challenge you to create something more fun and usable. If you are looking for a starting point, I’d like to point to our reference platforms: upbound/platform-ref-aws, upbound/platform-ref-gcp or upbound/platform-ref-azure. You can also start from scratch by following our quick starts from AWS, GCP, or Azure. And be sure to join https://slack.crossplane.io/ and ping me @luebken.

This article was originally posted on The New Stack.