Why I’m Excited About Crossplane: Kubernetes-Native Infrastructure as Code

Over the last few months, I’ve been diving deeper into the world of DevOps and cloud infrastructure. Between YAML, Terraform, Helm, and Kubernetes, there’s always a new tool or concept to wrap your head around. But recently, I stumbled across something that clicked instantly for me: Crossplane.

If you haven’t heard of it yet, here’s the short version:

Crossplane is like Terraform, but it runs inside your Kubernetes cluster and lets you manage cloud infrastructure using Kubernetes-style YAML.

That idea alone was enough to pique my interest, but after playing with it and reading more, I think it’s a game changer for platform engineers and anyone trying to build a solid internal developer platform.

---

🚀 What Makes Crossplane Different?

I come from a background where managing cloud resources meant hopping between Terraform files and cloud dashboards. That works, but there’s always friction when your app stack lives in Kubernetes and your infra lives somewhere else. Crossplane aims to fix that by treating your cloud resources as native Kubernetes objects.

Instead of writing .tf files, you write manifests like this:

yamlCopyEditapiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
  name: my-db
spec:
  forProvider:
    region: us-west-2
    dbInstanceClass: db.t3.micro

Now suddenly your database is managed by the same cluster that runs your apps. It feels unified.

---

🧩 Core Concepts I Found Cool

After a few days of learning, here are the pieces of Crossplane that stood out:

• Providers: Like Terraform providers, these let Crossplane talk to AWS, Azure, GCP, etc.

• Managed Resources: Represent actual cloud services like S3 buckets, RDS, or GKE clusters — all in YAML.

• Compositions: This blew my mind. You can define your own abstractions like MySQLCluster, and hide all the ugly config behind a nice developer-friendly interface.

• Claims: Devs can request infra (like a DB) by just applying a Claim — no cloud knowledge needed.

This kind of structure lets platform engineers define policies and templates while giving app teams freedom to deploy what they need.

---

🧠 Why I Think It’s a Big Deal

Here’s what excites me about using Crossplane in a real-world DevOps workflow:

• ✅ It’s GitOps-friendly — all infra is version-controlled and declarative

• ✅ You can offer self-service infrastructure safely (huge for developer experience)

• ✅ You don’t need to introduce another tool like Terraform — it all lives in Kubernetes

• ✅ You can standardize cloud usage across teams and clouds

---

🛠️ Getting Started Wasn’t Too Bad

I followed the official docs and set up Crossplane on a local Kubernetes cluster using Kind. Then I installed provider-aws, configured credentials, and spun up a real RDS instance just from a YAML file. It felt empowering, and also oddly clean. No messy state files or terraform plans — just Kubernetes doing what it does best: reconciling desired state.

---

🎯 Final Thoughts

Crossplane is still growing, and it may not yet replace Terraform for every use case. But if you’re working in Kubernetes and want tighter integration between app and infra, or you’re building a platform that supports multiple teams, it’s absolutely worth trying.

I’ll be experimenting more with Compositions, multi-cloud setups, and CI/CD pipelines that deploy both apps and infra from a single source.

If you’re interested in platform engineering, Kubernetes-native DevOps, or just like trying new tools — definitely give Crossplane a look.

---

🧵 Have you tried Crossplane? I’d love to hear your experience or tips.

Thanks for reading!

— Georgi