Crossplane

Wed, 03 Jun 2026 00:00:00 +0000

Crossplane is Kubernetes-native infrastructure management. Where Terraform runs as a CLI tool that applies changes and exits, Crossplane runs as a controller inside a Kubernetes cluster and continuously reconciles infrastructure — the same control loop model as Kubernetes itself.

Cloud resources become Kubernetes objects. You kubectl apply an RDS instance the same way you apply a Deployment. Crossplane’s controllers watch those objects and make the API calls to converge actual infrastructure to the desired state.

Core concepts

Providers extend Crossplane with CRDs for a specific cloud. provider-aws adds Kubernetes resources for every AWS service — S3 buckets, RDS instances, VPCs. Apply a provider, get hundreds of new resource types.

Managed Resources (MRs) are the individual cloud resources:

apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
 name: my-assets
spec:
 forProvider:
 region: eu-central-1
 tags:
 Environment: prod

Crossplane creates this bucket and keeps it in sync. If someone deletes it outside of Crossplane, the controller recreates it.

Composite Resources (XRs) are the powerful part. You define your own CRDs — a Platform or DatabaseCluster — that compose multiple managed resources. A developer applies a DatabaseCluster and gets an RDS instance, a subnet group, a parameter group, and security groups, all wired together, without needing to know any of the details.

XRDs (Composite Resource Definitions) define the schema for composite resources — what fields the developer sees, what defaults apply.

Compositions define how a composite resource maps to managed resources — the implementation behind the abstraction.

The platform engineering model

Crossplane’s real value is as a platform layer. A platform team owns the Compositions — they define what a “compliant database” or “standard app environment” looks like. Dev teams consume the simplified abstractions without touching the underlying cloud resources.

Self-service infrastructure with guardrails baked in.

vs Terraform

Crossplane and Terraform are not direct alternatives — they solve the problem differently.

Terraform is a CLI tool: run plan, review, apply, exit. State is a file. Good for human-in-the-loop workflows and one-off provisioning.

Crossplane is a control plane: always running, always reconciling. Better for continuous enforcement and self-service platforms. More complex to set up and operate.

In practice: Terraform for provisioning foundational infrastructure (clusters, networks, accounts). Crossplane for what runs on top of the cluster — letting application teams provision their own databases, queues, and object storage through Kubernetes-native APIs.

Upbound

The commercial platform behind Crossplane. Managed control plane hosting, a marketplace of providers and compositions, and tooling for building and publishing your own platform APIs. Worth evaluating if you are building a serious internal platform.

Learning curve

Steep. You need to understand Kubernetes controllers, CRDs, and the Crossplane composition model before you can be productive. The payoff is a genuinely powerful platform abstraction — but it is not a beginner tool.

A good framing: Crossplane is a digital twin of your infrastructure. The cluster holds the desired state of everything — cloud resources, application configuration, other tools — and continuously reconciles reality to match it.

Genuinely cool and worth learning if you have a cluster. The provider model has expanded well beyond cloud infrastructure — from v2 onwards Crossplane can manage applications, not just infra. There are also providers for Ansible and Terraform/OpenTofu, which means Crossplane can be the orchestration layer that drives other IaC tools. One control plane to rule them all.

The prerequisite is the cluster itself. If you already run Kubernetes, Crossplane is a natural extension of the same model you already operate. If you do not, it is not the tool to start with.

Kubernetes

Mon, 01 Jan 2024 00:00:00 +0000

Kubernetes (K8s) is the de facto standard for container orchestration and the second largest open source project after the Linux kernel. It has well and truly reached the plateau of productivity — the ecosystem is mature and it genuinely delivers.

That said, the honest take: K8s is ridiculously hard to deploy and manage (day 2 operations especially). Docker Swarm is equally ridiculously easy to get started with. For raw scale, Mesos/DC/OS wins — clusters of 80k+ nodes have been documented in the wild, versus K8s master’s practical ceiling of around 5k nodes.

So the real question is whether the ecosystem justifies the complexity for your situation. For most teams doing cloud-native work, it does.

Core concepts

The main building blocks:

Pods — smallest deployable unit, wrapping one or more containers that share network and storage.

Deployments — declare desired state; K8s handles rolling updates and self-healing.

Secrets — store sensitive data (passwords, tokens, keys) separately from application config.

DaemonSets — run a pod on every node. Typical use: log collectors, monitoring agents.

ReplicaSets — ensure N copies of a pod are running at any given time.

Ingress — HTTP/S routing rules at layer 7. Your load balancer config, declarative.

CronJobs — scheduled jobs, K8s-native.

Custom Resource Definitions (CRDs) — extend the K8s API with your own resource types. The foundation of most K8s operators.

Architecture

How the pieces fit together internally:

Containers vs virtual machines

Not an either/or — they solve different problems and are frequently combined.

Local clusters for development

When you need K8s without a full cluster:

Tool	Best for
MicroK8s	Ubuntu, snap-based, batteries included
Minikube	The classic, broad driver support
Kind	K8s in Docker, great for CI pipelines
K3D	K3s in Docker, fast startup
K3S	Lightweight K8s, edge and IoT use cases

Resources

kubernetes.io
CNCF Landscape — map of the cloud-native ecosystem
TGI Kubernetes intro (YouTube)
Setting up MicroK8s with RBAC and Storage

Cloud-Native on Backend Engineering Strategy Tools

Crossplane

Core concepts

The platform engineering model

vs Terraform

Upbound

Learning curve

Kubernetes

Core concepts

Architecture

Containers vs virtual machines

Local clusters for development

Resources