Does anyone here have experience with both crossplane and Pulumi?

I haven’t used Crossplane, but my teammate @many-telephone-49025 has looked at it. He’s in EMEA and therefore it’s already the weekend for him, so he may not weigh in until he gets back to the office on Monday.

Thanks @salmon-account-74572 for tagging me! @millions-furniture-75402 any particular question around Crossplane and Pulumi?

I'm curious how they stack up against either. Crossplane would be considered more "first class" in the Kubernetes ecosystem, but the providers appear less developed than Pulumi. I'm curious if the Pulumi k8s Operator makes Pulumi a viable alternative to Crossplane. If I already have a number of stacks deployed through traditional pipelines using Pulumi, that I want to move into Kubernetes for delivery, then does it make more sense to use the Pulumi k8s Operator, or redeclare the stacks in Crossplane?

One thing Engin pointed out to me (which is obvious now in retrospect) is that Crossplane lacks any preview/plan functionality---this makes sense when you think about it leveraging the core K8s reconciliation loop, but I hadn’t considered that before he mentioned it. WRT to your question, to me it makes more sense to move to the Pulumi K8s Operator.

Is there any first class features in crossplane that Pulumi is missing in Kubernetes?

@millions-furniture-75402 I think there is no feature missing. It is just the way you can achieve them. For example: A composite Resource (XR) is defined in crossplane with the XRD and a Compostion. To create a similar abstraction, you have to use in Pulumi either Component Resources (for each language) or if yo want to stick in YAML land, by creating a multi language component.

Last question, if I may. Are there any pain points in the setup, usage or overall developer ergonomics?

What I saw in Crossplane with the latest releases, was a general shift to Pipelines in the composition and the usage of functions (in code) and go-template function. So as a Platform Engineer, with a more sophisticated use case, you will probably need to program your own functions or use some of the predefined functions of the upbound marketplace to create custom Compositions to your users which they can then Claim. Same you can do now in Pulumi without running in a challening YAML / code mixture as your MLC or Component Resource are available in the language of your choice. This helps for a great product thinking, when exposing them to consum efrom your internal teams. If you are a polyglot company, using MLC and generating SDKs for every language is a nice plus. From a setup point: Both use Kubernetes! Thats can be smooth if your chain is optimised for k8s or can be bad. Delivery: Pulumi Operatior supports GitOps and even has a native intergration with Flux

Thank you, I appreciate your thorough feedback.

Good thing is always to open a issue. With this, @salmon-account-74572 and I can take this internally and advocate for it with the engineering team. As mentioned, I would like to have this feature of creating component resources in yaml too. Either through CRDs on K8s or on a more generic way.