Today we are introducing Crossplane, the open source multicloud control plane. It exposes workload and resource abstractions on-top of existing managed services that enables a high degree of workload portability across cloud providers. A single crossplane enables the provisioning and full-lifecycle management of services and infrastructure across a wide range of providers, offerings, vendors, regions, and clusters. Crossplane offers a universal API for cloud computing, a workload scheduler, and a set of smart controllers that can automate work across clouds.

Crossplane presents a declarative management style API that covers a wide range of portable abstractions including databases, message queues, buckets, data pipelines, serverless, clusters, and many more coming. It’s based on the declarative resource model of the popular Kubernetes project, and applies many of the lessons learned in container orchestration to multicloud workload and resource orchestration.

The project supports a clean separation of concerns between developers and administrators. Developers define workloads without having to worry about implementation details, environment constraints, and policies. Administrators can define environment specifics, and policies. The separation of concern leads to a higher degree of reusability and reduces complexity.

It includes a workload scheduler that can factor a number of criteria including capabilities, availability, reliability, cost, regions, and performance while deploying workloads and their resources. The scheduler works alongside specialized resource controllers to ensure policies set by administrators are honored.

Walk-through

Let’s walk-through an example of running a portable workload using Crossplane. We’ll use a container workload of the familiar Wordpress application. Wordpress runs in a container and requires a MySQL database instance. Crossplane supports a clean separation of concerns between developers and administrators, and we will only consider the developer perspective in this walk-through. We will assume that the administrator pre-configured crossplane to use AWS resources.

With Crossplane, a developer writes portable configuration, and is generally not concerned about the cloud provider, credentials, and other details of the environment. Let's start by creating the configuration for a MySQL database instance that is needed by wordpress. This configuration acts as a request for a MySQL database server instance, we refer to it as a resource claim.

apiVersion: database.crossplane.io/v1alpha1
kind: MySQLInstance
metadata:
 name: wordpress-db
 namespace: demo
spec:
 version: 5.7
 highly-available: true
 autoUpgradePolicy: minor
 encrypted: true
 size: 100Gi

The spec defines the requirements for the MySQL instance independent of any implementation. For example, our example wordpress requires version 5.7 of MySQL, a highly-available instance that is spread across failure domains, encrypted storage, automatic upgrade policy on based on minor versions, and a 100 GB of storage. The rest of the implementation or environment specific details come from the default resource class as defined by the administrator. To provision the database, we can run the following:

kubectl apply -f wordpress-db.yaml

Next let's create a workload configuration that defines a container workload to run wordpress. A workload is a schedulable unit of work and contains a payload and requirements for where and how the workload should run. A workload scheduler is responsible for deploying the workload and in this case it will be scheduled to run on the EKS Kubernetes cluster provisioned by the administrator.

This workload specifies a Kubernetes deployment, service, and namespace to propagate to the target cluster. It also requests a minimum version of Kubernetes, but can include other requests that will be matched against the capabilities of the cluster.

apiVersion: container.crossplane.io/v1alpha1
kind: Workload
metadata:
 name: wordpress
 namespace: demo
spec:
 # the version of Kubernetes desired
 clusterVersion: 1.10
 # the namespace to create on a target cluster
 targetNamespace: wordpress
 # this is a template for a deployment to be created on a target cluster
 targetDeployment:
   metadata:
     name: wordpress
     labels:
       app: wordpress
   strategy:
     type: Recreate
   template:
     metadata:
       labels:
         app: wordpress
     spec:
       containers:
       - name: wordpress
         image: wordpress:4.6.1-apache
         env:
         - name: WORDPRESS_DB_HOST
           valueFrom:
             secretKeyRef:
              name: wordpress-db-connection
              key: endpoint
         - name: WORDPRESS_DB_USER
           valueFrom:
            secretKeyRef:
             name: wordpress-db-connection
             key: username
         - name: WORDPRESS_DB_PASSWORD
           valueFrom:
            secretKeyRef:
             name: wordpress-db-connection
             key: password
         ports:
         - containerPort: 80
           name: wordpress
 # this is a template for a service to be created on a target cluster
 targetService:
   metadata:
     name: wordpress
   spec:
     ports:
       - port: 80
     selector:
       app: wordpress
     type: LoadBalancer
 # these are the resource used by this workload. The secret holding the connection
 # information will be generated and propagated to the target cluster.
 resources:
 - name: wordpress-db
   kind: MySqlInstance
   secretName: wordpress-db-connection

The workload also references all resources it consumes in the resources: section. This helps Crossplane setup connectivity between the workload and resource, and create objects that hold connection information. In this example, a secret with name wordpress-db-connection is created and contains a connection string, user and password. This secret will be propagated to the target cluster so that it can be used by the wordpress container. Let’s go ahead and create the workload:

kubectl apply -f wordpress-workload.yaml

At this point the scheduler will assign this workload and after a few minutes, wordpress should be up and running in an EKS cluster, and consuming an RDS database.

Note that the developer created a portable configuration of wordpress. There was no reference to AWS, RDS or EKS in any of the configurations authored by the developer. They did not have to setup VPC, security groups, IAM policies, and other details of the environment and cloud provider. They were solely concerned with their workload and its requirements. This same configuration runs Azure or GCP without any changes.

Why we created Crossplane?

Upbound’s mission is to create a more open cloud-computing platform that offers more choice and less lock-in. At the heart of every cloud is a control plane, and we hope that Crossplane could become the control plane for the open cloud. With an open control plane anyone can add new APIs and controllers and extend it to manage commercial or open-source cloud services and resources. It acts as a common integration point across services, and a basis for more open ecosystem of applications and tools.

Crossplane is community driven and we are opening this project early with the hope that the open source community will join us in making multicloud a reality.

“Crossplane has an opportunity to change the cloud industry as we know it,” said Sid Sijbrandij, CEO and co-founder of GitLab. “Our customers are increasingly looking for a way to deploy their code across multiple cloud environments. The choices available today are too complex and vendor driven but with Crossplane the ability to orchestrate clouds becomes simple. We look forward to collaborating with them on this vision and as the first complex app deployed on Crossplane.”

For a deeper dive into Crossplane, see the architecture document, our documentation, and our github repo.

Crossplane is a project sponsored by Upbound. Stay up to date on Crossplane news by following Crossplane on Twitter or on GitHub.