In the previous post I talked about the complicated relationship between developers and operators. I described how Kubernetes solves many, but not all operators and developer conflicts.

We discussed how Kubernetes not only provides a standardized API but also provides state enforcement. Kubernetes ensures things are always doing what an operator intended it to do. This makes Kubernetes a powerful tool, but only if your workload lives inside Kubernetes. This leaves out non-Kubernetes resources. It works great for applications, but misses out on cloud resources. Things like Amazon S3 storage buckets, Google GCP compute engine VMs or Microsoft Azure SQL databases still need operators to deploy and manage.

Even if an Operator automates this process it requires a unique process for every cloud.  Even if two clouds provide the same resource, every cloud has their own APIs to create resources. For example, creating a VM in Microsoft Azure and Amazon AWS has the same outcome but requires two different APIs.

Crossplane Extends Kubernetes to the Cloud… and Beyond!

Crossplane extends Kubernetes so things which don’t “live” inside of a K8s cluster can be managed using native Kubernetes objects. Crossplane acts as a translation engine between Kubernetes and external resources, so operators can now use Kubernetes to control everything - not just applications. This means one tool for all use cases.

Beyond tools, Operators now get Kubernetes state enforcement for things like cloud resources. If an Operator deploys an AWS server, and it crashes they must manually deploy a new server. Crossplane allows the Kubernetes "control loop" to watch that AWS server. If something crashes, Kubernetes automatically starts a new server. The Operator never needs to act.

Crossplane extends Kubernetes by using "Custom Resources". The first custom resource Crossplane creates is a "Provider". Every cloud has their own Crossplane "Provider". Providers are the bridge from Kubernetes APIs to the resources inside a public cloud. When Crossplane installs a Provider, operators can now create cloud resources directly from Kubernetes.

Connecting Kubernetes to cloud resources is only the beginning of what Operators can build. With cloud resources living next to applications and able to use Kubernetes tools Operators can now define custom clouds and resources for developers.

Going Beyond Existing Clouds and Building Your Own

Connecting Kubernetes to cloud resources is only the beginning of what Operators can build with Crossplane. Now that cloud resources share the same Kubernetes tooling, operators can build their own custom cloud platforms.

Beyond "Providers" Crossplane introduces three more components to make cloud resources even more powerful: "Composite Resource Definitions", "Compositions" and "Claims".

A restaurant analogy is a good way to describe these components:

Composite Resource Definitions represent all the possible options. Like a restaurant offers a set of choices on the menu, the Composite Resource Definition is the menu for the developer. Operators define this "menu" and what developers can request.

Claims are the customizations made by the developer for a menu item. For example, asking for a sandwich with no onions and extra pickles. The developer orders a sandwich from the menu, makes some customizations and changes.

A Composition is the complete meal. Customers express some opinions over the meal, but can't change the ingredients in the bread or what kind of butter the chef uses. Operators take the opinions in a Claim and adds them to other settings important to the operator. Developers can't change these settings, just like a customer can't change the butter.

Let's look at each of these in more detail.

Composite Resource Definitions

With Composite Resource Definitions operators define what resources developers can request. Operators allow developers to have control over some, but not all, settings. For example:

• A "database" that is "small, medium or large". The size of the hard drive can be picked but the database software and version are fixed.
• A "server" with "memory" and "CPU" options. Devs set these server settings but they can't pick the cloud provider.
• A "cluster" with "nodes". Developers choose the number of nodes in a Kubernetes cluster. Operators define the regions and node settings.
  

In each of these examples the operator is giving the developers some choice. But operators maintain control over any settings critical to the infrastructure or business.

When operators build Composite Resource Definition Kubernetes creates a new customized API endpoint. Developer uses that API with a "Claim".

Claims

Developers create "Claims" to ask for the resources defined in a Composite Resource Definition. For example, the operator defines a Composite Resource Definition called "SecureDatabase".  Operators guarantee a "SecureDatabase" will meet all PCI encryption, monitoring and security requirements.

The "SecureDatabase" API has the following options:

• storageSizeGB: <integer> - The storage size for the database in gigabytes.
• databaseType: <"sql" or "nosql"> - The type of database requested.
• isFast: <boolean> - A true/false value that is true for high performance databases and false for standard databases.
  

Developers now "Claim" this database with a Kubernetes API "Claim"

kind: SecureDatabase
metadata:
  name: my-fast-and-secure-database
spec:
  parameters:
    storageSizeGB: 500
    databaseType: "nosql"
    isFast: true

Developers express only a few opinions and all other settings are in the hands of the operator. The number of CPUs and amount of memory and any other settings are outside developer control.

Operators can create arbitrary settings like "isFast" that have meaning to the internal teams. This setting could determine if the database uses a standard or high-speed SSD disk.  The details don't matter to the developer; the operator can abstract away these specifics. It's up to the operator what the API endpoints are and what those endpoints do. Operators create settings in Custom Resource Definitions and developers access them with Claims.

Now the developer has their very own database. But deploying a database to production is usually more than the settings of that one server. The database may need virtual networking, server monitoring and alerting and backup policies.

Taking this new resource and deploying it with other components happens in "Compositions".

Compositions

While a Claim and Composite Resource Definition create a single resource, like a database, a Composition creates all the other required pieces for a production deployment.

Other settings like virtual networking or alerting are critical to operators. Operators want to ensure all resources deploy with the correct infrastructure settings.

Compositions act like a template for the infrastructure. When a developer "Claims" a resource Crossplane plugs it into a Composition. Crossplane creates the database and anything else the operator requires.

Different resources map to different Compositions. Again, the operator is in complete control of their infrastructure.

The New Internal Cloud Platform

With Crossplane, operators can manage cloud resources like anything else inside Kubernetes. More than that, operators can build custom APIs and complete cloud deployments. Operators can mix resources across cloud providers, provide state enforcement and simplify deployments.

Operators now create their own cloud platforms that meet the needs of their developers and business objectives. The final barrier in full developer self-service is finally removed. Operators can focus on building the system architecture and developers focus on deploying code. Everyone spends less time waiting around for things to happen.

If you're ready to build your own cloud platform visit the Upbound Marketplace to learn how to get started.

–

Upbound is the creator and maintainer of the popular open source project Crossplane. We are democratizing the best kept secret in cloud computing — the control plane — giving platform engineers centralized control and developers the freedom of self service.

We have two offerings – Upbound Universal Crossplane (UXP) and Upbound.

UXP is Upbound’s downstream distribution of Crossplane, and Official Providers are production ready versions of Providers available exclusively to Upbound customers. Both are maintained, tested, and supported by Upbound on behalf of our customers, and are included with an Upbound subscription.

Upbound is a single, global platform to build, deploy, and operate your own internal developer platforms using managed control planes powered by Crossplane. Want to try Upbound for yourself? Sign up for your 30 day free trial here!