How to Introduce Crossplane in Your Organization — And Keep Everyone Smiling Lately, I’ve seen many people in the Crossplane community struggle to convince their teams that Crossplane is a good fit for managing infrastructure and application stacks. Changing minds is hard — especially when it means stepping out of a familiar workflow. I find this challenge fascinating, so I decided to write this blog post to explore the common hurdles people face when introducing Crossplane to their teams. But before we dive in: Setting the level source: Upbound Blog Crossplane is an open-source CNCF project that enables you to build control planes on Kubernetes. It provides you with the tools to abstract infrastructure and service configurations into higher-level APIs, tailored to your organization’s needs, and expose them to developers. apiVersion: platform.example.org/v1alpha1 kind: XApp metadata: name: my-xapp spec: image: xapp:1.25 replicas: 2 bucketName: my-xapp-bucket Some of the most important advantages include: Syntax: It’s all YAML — no new DSLs to learn. (We love YAML, don’t we? 🙂) Real-time Observability: You can view the status of each resource in real-time and some metrics to see how things are looking. Continuous reconciliation: Crossplane constantly checks that the actual state of your resources matches the desired state. Self-healing infrastructure: As part of the reconciliation loop, if something drifts or breaks, Crossplane works to restore it automatically. Real-time observability: You get live status updates and metrics for every managed resource. With Kubernetes huge adoption in the past years, Crossplane and similar (yet less mature) project Kro seem to be our best shot in deploying services and their cloud resources, through Kubernetes native abstractions. But before you even get to the technical stuff, the biggest challenge is simply getting people to step out of their comfort zones. It’s less about YAML and more about psychology. Teams are used to their tools and workflows — asking them to try something new can feel like suggesting they switch to tabs instead of spaces. Change is uncomfortable, and unfamiliar ideas often trigger resistance. Helping people see a new perspective takes patience and storytelling. Here are some classic “Wait, but…” moments you’ll hear as soon as you mention Crossplane: But we need to educate everyone to use crossplane! Of course you need to! The good news? Since Crossplane uses YAML, it’s usually easier for developers to pick up compared to learning a whole new DSL like Terraform. If your team is already familiar with Kubernetes, adopting Crossplane feels natural — mostly just small changes in code. I’d argue that what you should be more worried about is to educate yourself (Platform/Cloud Team) to understand Crossplane and start using it. But why not use Terraform? Lack of reconciliation is a big pain! How do you make sure what’s defined in code matches reality? Run Terraform on every stack every five minutes? Set up a cron job for that? Believe it or not, some companies sell exactly that — a continuous Terraform runner — as a paid service. On top of that, building a reliable CD pipeline for Terraform is not easy, whether you’re doing it yourself or using open-source tools like Atlantis. As one developer from a company specializing in Terraform CD pipelines put it: “Atlantis and other open-source tools send many customers our way. Honestly, we tell them to try those first before buying our product.” Sounds like a clever sales pitch, right? But there’s definitely some truth to it, which highlights a clear gap in open-source solutions for Terraform drift detection and continuous delivery — a gap that’s arguably intentional, since vendors want to offer features you have to pay for. And I haven’t even started on how much harder it is to teach Terraform’s concepts and HCL to developers, compared to the simplicity of a YAML-based Crossplane XRD. But we need a PhD in Kubernetes! Nah — if you can pronounce “kubectl,” you’re 80% of the way there. But all our infra is already in Terraform! Migrating from Terraform to Crossplane is not necessarily disruptive! Using Crossplane Terraform Provider, you can import your existing Terraform-managed infrastructure under Crossplane’s control. This enables a smooth transition where you can continue using your familiar infrastructure as code, while gradually replacing Terraform modules with native Crossplane Compositions at your own pace. This blog post goes deeper into this. But our infrastructure has complex logic! Perfect — so does spaghetti, and people still love it! Crossplane Composition Functions allow you to use a general-purpose programming language like Python or Go in your composition, which allows you to implement advanced logic to template resources, like loops and conditionals. So the sky’s the limit for what you can do there. But it’s not compatible with our current workflows? Crossplane is the Kubernetes approach to creating control planes and naturally fits into GitOps workflows with tools like Flux and ArgoCD. It’s less about replacing your workflows and more about enhancing them with powerful automation and standardization. But Crossplane is not production-ready! Ah, the classic skepticism — like saying Kubernetes wasn’t production-ready in 2016 (spoiler: it runs half the internet now). Sure, Crossplane is still an incubating CNCF project, and is about to release a new major version v2 soon. So it’s fair to say the product is maturing, and it’s not a one-size-fits-all solution. This doesn’t mean you should stay away from it; maybe even an opportunity for your team to start small, learn from your mistakes, and interact with the crossplane community. Think big, start small, fail fast, Iterate a lot. If this helped you, a few claps go a long way (and make my day 🙂 ). P.S. Follow me on LinkedIn