Welcome to this issue of Activation Function. Every other week, we introduce you to a new and exciting open-source backend technology (that you’ve probably only kind of heard about… ) and explain it to you in 5 minutes or less so you can make better technical decisions moving forward.
In this issue, we’ll explore Crossplane, an open-source framework to provision and manage cloud resources across any cloud provider (aka a multi-cloud control plane) using the magic of Kubernetes.
But wait... Why the heck would I use Kubernetes to do this? Let’s find out.
TL;DR:
- Crossplane is an incubating CNCF project created in 2018 by Upbound.
- Crossplane lets you provision & manage infrastructure in a cloud-agnostic way using the Kubernetes API by abstracting the underlying cloud provider. It offers support for all major cloud providers and can be extended to support any third-party tool running pretty much anywhere.
- Crossplane is built to serve both Ops and Dev teams. Platform teams can create an interface that application teams can self-serve cloud resources without worrying about implementation details.
Why do I need a multi-cloud control plane?
Unless you’ve lived under a rock for the past 10+ years, just like the rest of us, you’re probably hooked on this awesome thing called managed cloud services. It’s convenient to get started with, easy to scale, and, in many cases, cost-efficient.
Initially, the game was simple – You needed a managed cloud service, you got it from your main cloud provider, and that was it.
And then, the cloud wars got REAL, and things went from 0 to 100 real quick!
You now have so many options to choose from. Mixing and matching (aka adopting a multi-cloud strategy) allows you to pick whatever best fits your use case, budget, compliance, geography, etc.
But of course, there are always trade-offs. In this case, it’s complexity.
Running across multiple cloud providers is a mess—fragmented tooling, no portability, different UIs/UXs, no standardization, etc. You get the picture…
Wouldn’t it be nice to leverage whatever resources best fit your needs because, you know... we’re all so unique and get a single pane of glass, ideally a single API, to manage and abstract away all the complexity?
Of course you do!
Enters Crossplane
At its simplest, Crossplane is an abstraction layer that lets you provision and orchestrate cloud resources across multiple vendors in a declarative way using a single unified API.
Think of it as a universal remote control for cloud services.
In addition to its declarative and unified nature, Crossplane brings 2 major advantages:
- Workload portability – This allows dev teams to build applications that can run on any cloud provider without any modifications. We’ll break this down later in the how it works section.
- Reconciliation loop – This ensures that the state of your deployment matches the state of the configuration you passed in.
Does this all sound familiar? Well, it should, as this is what Kubernetes does for containers.
In fact, Crossplane is essentially extending Kubernetes beyond the cluster and turning it into a universal Control Plane. It has adopted the Kubernetes declarative resource management model and leverages the Kubernetes API, etcd, and controllers to manage external cloud services.
Definition: A Control Plane is a system that provides cloud infrastructure management, routing, and orchestration.
Given this tight integration with Kubernetes, Crossplane plays nicely with most tools in the Kubernetes ecosystem (e.g., Argo CD) AND can run directly on top of an existing Kubernetes cluster without requiring any changes.
And there you have it… That’s why Kubernetes.
[Note] Kubernetes manages containers (pods) and the resources they consume across nodes. Crossplane manages workloads (container, serverless, others) and the resources they consume across cloud providers or on-premise environments.
How does Crossplane work?
To use Crossplane, you must first install its control plane in a Kubernetes Cluster.
Note: Crossplane must be installed in a Kubernetes cluster—either where your applications run or a new one.
Crossplane extends the Kubernetes API using custom resource definitions (CRDs) known as Providers responsible for creating and managing external cloud-provider-specific services (e.g., an RDS database). Crossplane has a Provider for every major cloud, including AWS, GCP, and Azure, but you can also build custom Providers using the provider template.
Once your Provider is installed, you must configure it with the necessary security credentials and endpoint details to communicate with your cloud provider's API.
Once that’s all set, you’re ready to start creating resources (e.g., an RDS instance) to be managed by the Provider. These are called Managed Resources, and you create them by declaring a Kubernetes custom resource (CR) that specifies things like the size, type, and any other configurations specific to the cloud resource you want to spin up.
This is where the Provider’s reconciliation mechanism kicks in, and the magic happens. The Provider’s controller detects the change (desired state), and the Provider communicates with the cloud provider's API and attempts to reconcile the actual state of the cloud resource with the desired state declared in the CR, in this scenario, creating an RDS instance.
[Note] Crossplane Managed Resources are just Kubernetes resources, which means that you can use any Kubernetes tool to monitor and query the state of these resources
But what if you need to spin up other components alongside the main one (e.g., networking, security, RBAC, etc.)? Compositions are here to help!
Compositions let you create multiple individual Managed Resources as a single object known as Composite Resources (XR). Like Managed Resources, XRs have a reconciliation loop that will sync their desired and actual state.
[Note] Before being able to create Composite Resources, you’ll need to create a Composite Resource Definition (XDR), which defines the schema for a custom API you’ll use to create your XRs.
Crossplane for Devs
Crossplane was created to serve both Administrators (e.g., Platform Engineers) and Developers. So far, we’ve explored the administrator side of things, but what’s in it for devs?
This is where portability comes into play. With the help of Crossplane, Developers can define workloads without worrying about implementation details, environment constraints, and policies.
They do this by leveraging Claims.
Claims are the primary way developers interact with Crossplane. Claims access the custom APIs the platform team defines in a Composite Resource Definition to create the developer's desired resource.
[Note] Claims are like Composite Resources. The difference between Claims and composite resources is that Crossplane can create Claims in a namespace, while composite resources are cluster-scoped.
Crossplane Vs. Terraform
Like Crossplane, Terraform lets you dynamically provision and declaratively make infrastructure changes across cloud providers and build reusable components. However, there are a couple of differences worth pointing out:
- State Management – Crossplane offers out-of-the-box automated reconciliation (aka drift correction) leveraging Kubernetes controllers and etcd. On the other hand, unless you’re using a Terafform cloud, you’ll need to configure your own backend and manage the state of your resources manually.
- Policy-Driven Provisioning – Crossplane provides a native policy framework to enable policy-driven provisioning and management. On the other hand, Terraform requires external tools to do the same.
That being said, Terraform is a much more established technology with a huge ecosystem of tools and a large community. Additionally, Terraform is a standalone tool, whereas Crossplane requires you to run Kubernetes. Finally, the lack of a preview feature similar to Terraform's dry-run/plan feature to assess and verify changes in advance is another drawback of Crossplane.
So which solution should you go with? Well, as usual, it depends.
Are you ready to go all-in on Kubernetes? Do you already have expertise in HCL? Do you like managing infrastructure using APIs? Does your existing tooling (e.g., CI/CD tooling) play nice with Kubernetes? Is the Terraform Open Source license an issue?
Where to next
Crossplane is still a fairly new project; therefore, resources and documentation are still limited. That being said, here are a few resources to get you started on the right path:
Documentation
Articles & Tutorials
- An Introduction to Crossplane – The original and first introduction written by the creators of Crossplane
- vRelevant Blog – A blog written by Nate Reid covering various cloud computing topics, including Crossplane.
- First steps with Crossplane
Books
- End-to-End Automation with Kubernetes and Crossplane
- Defining Infrastructure Declaratively with Crossplane
- Platform Engineering on Kubernetes
Videos & talks
- Crossplane Intro and Deep Dive
- How to provision a production cluster with Crossplane
- Crossplane on Amazon EKS
- Secure and multi-tenant infrastructure as code with Crossplane & Argo
- Anthos & Crossplane for Lifecycle Management of Infrastructure and Kubernetes Config
Communities
- Crossplane Slack group
- Crossplane Twitter
- CNCF Crossplane community group
- Crossplane YouTube channel
- Crossplane Forum
People to follow
- Viktor Farcic – Developer Advocate at Upbound
- Bassam Tabbara – Crossplane co-creator
- Jared Watts – Crossplane co-creator
- Illya Chekrygin – Crossplane co-creator
- Matthias Lübken – PM at Upbound
That’s it, folks! I hope this gave you an overview of Crossplane. There are a lot of technical nuances to effectively implementing Crossplane and tailoring it to your needs, so I strongly recommend looking at the documentation.
Until next time!
P.S. Did you enjoy this content? Sign up here.
.jpg)
