Upbound

Our main use case for Upbound Crossplane  at Carbon International involves maintaining our Kubernetes  environments, which is entirely run using Terraform  in the background. We considered using Crossplane along with Terraform  to have all Kubernetes  objects up to date, and we are still in the POC phase and have yet to bring it to production.

There are a couple of surprises regarding the integration between Crossplane and Terraform. Managing the state files of Terraform and Crossplane is challenging because if both are working on the same platform component, synchronizing between the two state files is risky at this time. However, if we focus Crossplane towards one Kubernetes platform and Terraform towards another platform, we believe that would solve this issue, and my team and I are still investigating this approach.

We are still exploring how we can utilize Crossplane to manage our infrastructure completely. We are trying to replace Terraform with Crossplane, but we are still in the POC and R&D phase.

The best features Upbound Crossplane  offers include the GitOps approach, which synchronizes Kubernetes platform changes, and I find that very useful compared to Terraform. With Terraform, maintaining the Terraform code is risky, and if any Terraform block breaks, the entire code and Terraform lifecycle breaks. With Crossplane, maintaining individual components and keeping Kubernetes components in sync using Argo CD is more feasible and easy compared to Terraform, which is why we are trying to pivot towards Crossplane from Terraform.

Upbound Crossplane helps us increase or expand its API capabilities just like Kubernetes APIs, which we are looking forward to. I believe this is GoLang, and we are investigating that approach. Synchronizing the entire infrastructure and provisioning infrastructure using Crossplane is something we are very interested in, and we will try to achieve that as soon as possible.

Upbound Crossplane has positively impacted our organization so far. I can share specific outcomes such as provisioning a PostgreSQL  database, an S3  bucket, and an EC2  instance from Crossplane using the GitOps approach, which has worked very well. We are trying to expand the same towards the entire Kubernetes native capabilities as well, and that is our current goal.

When I provisioned PostgreSQL  and S3  buckets through Crossplane, I noticed improvements in deployment speed, reliability, and team collaboration. Since this works solely on the GitOps approach, whenever we use Crossplane to provision any PostgreSQL or other cloud resources, we can see the entire logs using that specific Argo CD application sets. If something breaks, we can immediately look into the Argo CD app and its logs to determine exactly where the problem is coming from. The deployment happens in a matter of seconds, not in minutes, compared to Terraform, and that is what has impressed us with Crossplane so far.

Regarding Upbound Crossplane, I see room for enhancement in synchronizing the state file of Crossplane with Terraform, as 90% of organizations have generally implemented Terraform and have their own specific, environment-specific Terraform state files. If they are planning to integrate that with Crossplane, synchronizing both state files with respect to Crossplane and Terraform is one of the major challenges we are experiencing. Additionally, coding through GoLang and extending its capabilities as per our use cases is another challenge we are facing.

The documentation for Upbound Crossplane is very good, and I believe no improvements are needed so far, except for the platform-level changes which I mentioned before.

I have been using Upbound Crossplane for close to three months, and I also used it in my previous company as a POC, not in a production environment.

I have not experienced any reliability issues with Upbound Crossplane so far; it performs very well.

Upbound Crossplane's scalability has met my needs as the platform grows. Since it works on a GitOps approach, it is all a matter of the HPA and the VPA concerning the Crossplane components, which can be easily maintained.

I have not yet interacted with customer support for Upbound Crossplane.

Previously, we were using application deployments through GitHub Actions  integrated with Argo CD, and we were deploying applications using Helm charts from our GitHub  repositories, while the target environment was a Kubernetes cluster managed by Terraform. Since we are working 100% on the Kubernetes native platform, we are trying to shift from Terraform.

We did not evaluate any other options except Upbound Crossplane.

My advice to others looking into using Upbound Crossplane is that if they have any legacy systems or if they are deploying applications on virtual machines, I would suggest they stay away from Crossplane because it is strictly bound to a Kubernetes-native GitOps approach. However, if they are deploying their applications on Kubernetes, then I would suggest they consider it. I would rate this product a 6 out of 10.

My main use case for Upbound Crossplane  is automating our back-end deployment.

I believe the best features Upbound Crossplane offers are the documentation, which is easy to understand, and the way Upbound Crossplane uses providers to deploy the entire infrastructure we need.

The documentation helps me in my workflow because it is clear regarding what we need to do and what variables and features we can add during the creation of the Helm templates that we use to deploy. Upbound Crossplane provider integration makes things easier for us because it uses simple YAML to deploy, allowing us to deploy the entire provider easily.

Upbound Crossplane has positively impacted our organization by allowing us to reduce our deployment time from three days to three hours for the entire back-end and entire infrastructure.

I found an issue with features that was difficult for me when we needed to retrieve some tags or IDs of a resource that we deployed using Upbound Crossplane, for example, the RDS . We encountered a problem where we needed to use the ID of the RDS  in another document that we have, making it difficult to return this information using Upbound Crossplane deployment.

I believe Upbound Crossplane could be improved by possibly having a feature that can return tags, IDs, or resources that were deployed inside AWS , such as needing to return the ID of the VPC that we create when using Upbound Crossplane.

I think the current state of Upbound Crossplane is already good enough.

I have been using Upbound Crossplane  for about one year.

I find Upbound Crossplane to be stable.

I think Upbound Crossplane's scalability is good enough.

I did not use the customer support, as I do everything by myself.

I did not previously use a different solution. The solution was manual, and we deployed everything manually before changing to Upbound Crossplane.

We did not buy Upbound Crossplane through the AWS Marketplace . We use the free versions.

I did not evaluate other options beforehand because the platform decided we must use Upbound Crossplane.

I have not seen any return on investment apart from the time savings I already mentioned.

We did not use the paid version, only the free version, so I do not have experience with pricing, setup cost, and licensing.

I rate Upbound Crossplane a 10 on a scale of 1 to 10. I choose 10 because it is easy to work with. Regarding Upbound Crossplane's AI capabilities, I do not know much because I did not use it with AI. I did not use the AI features, so I cannot comment on its accuracy and reliability of output. My advice for others looking into using Upbound Crossplane is to read the documentation, as it is simple and easy to understand. My overall review rating for Upbound Crossplane is 10.