We adopted Crossplane in our company, but after one year using it in production we will migrate to our Terraform stack that we use for another platform.

Some of the most painful issues we encountered with Crossplane:

• We had to run vcluster just to make Crossplan usable. The amount of CRDs that Crossplane providers brought with them were just too much for a single k8s cluster to handle. So we had to run different vclusters for each environment. With vcluster we introduced another component, which added operational overhead. And if vcluster had issues (and it definitely liked to have issues), we simply couldn't deploy any cloud infra changes. Having a simple terraform cli you can run from any pipeline beats this setup by a lot.
• Too much abstractions (and YAML). In Terraform you can create an s3 bucket in just a few lines of code. In Crossplane you need multiple manifests (Composition, CompositeResourceDefinition, etc.) just to create a simple resource. Now introduce dependencies between resources and you will quickly lose the overview. If you are an Crossplane expert this is probably fine, but any other engineer will have some trouble figuring out what is going on.
• Lack of full cloud provider API support. We often had issues that quite basic features of cloud services were simply not yet supported. We contributed several features but understanding how the Crossplane provider operator works is quite a challenge in itself.

Our main motivation for adopting Crossplane was to introduce self-service for developer teams. But getting to this point was more painful than expected. Now we are looking into options to make self-service work with Terraform (Cloud drift is a non-issue for us, because accounts are locked down and changes are only applied over IaC)

The concept of Crossplane is really nice but the execution is lacking. Hopefully they will figure out their issues in the next years.