Upbound

My main use case for Upbound Crossplane is defining all cloud resources using Infrastructure as Code, typically as a replacement for Terraform.

A specific example of how I use Upbound Crossplane to define cloud resources is managing all cloud resources through Crossplane, such as GCS buckets, IAM roles, service accounts, everything related to permissions, projects, networks, and similar infrastructure components.

The resource definitions are part of the same deployment system. I deploy everything with Argo CD, and for my organization, unifying the deployment of cloud resources with deployments inside Kubernetes enables developers to perform self-service not only of their applications and deployments, but also of the cloud components they need.

Upbound Crossplane has had a positive impact on my organization by allowing me to completely eliminate drift. Previously, I had to ensure that changes made in Terraform code were applied periodically to prevent drift. This drift no longer exists because I have a way to perform continuous releases with Argo CD, which is responsible for checking if there is a change in the resource and restoring it to its desired state. This allows me to implement pure GitOps for those resources.

Since implementing Upbound Crossplane, I have seen a reduction in management time, fewer incidents, and a specific indicator is that I see less drift and fewer incidents due to changes or cloud resources that should be in one state and are not. I now know that the source of truth for my resources is in code because I have a continuous reconciliation loop that ensures that what is defined in code is actually live in the different services.

The best feature offered by Upbound Crossplane is being able to deploy as if it were through Argo CD, as if it were just another deployment.

The CD-type integration has facilitated my operations by unifying the way of working. Instead of having one way to validate and deploy cloud resources and another to validate and deploy applications inside Kubernetes, it has unified things so that I can use the same guardrails for both deployments. This makes the way I deploy much simpler. Another key capability it enables is the ease for developers who use the platform to describe their resources without having to know a complex and delicate language like Terraform.

While I use Upbound Crossplane for cloud infrastructure, I also manage other types of APIs for other services that cannot directly be a cloud provider through Upbound Crossplane.

In terms of how Upbound Crossplane could improve, the generation of providers that are not already covered via Terraform is acceptable, but it could be more user-friendly for people who may not have knowledge of how those custom providers are structured.

Regarding possible improvements or needs I have with Upbound Crossplane, one of the things that could improve is the management of compositions. Making it more visible which resources are part of the compositions would help, because it is currently opaque to know all the different resources that are part of a composition.

I have been using Upbound Crossplane for four years.

I consider Upbound Crossplane to be stable in my daily use, as it is stable enough for a production environment.

The accuracy and reliability of the results or outputs that Upbound Crossplane provides in its daily operation are quite satisfactory, except for some issues that may exist with some specific types of resources. In general, I am quite satisfied in that regard.

Regarding the scalability of Upbound Crossplane, I think it adapts well to the growth of my needs. At the beginning, when I started using it, it had problems due to the size of the different Custom Resource Definitions within the public cloud providers, but currently it is quite stable.

My experience with customer support for Upbound Crossplane is that I do not have paid support.

Before Upbound Crossplane, what I used for what I now use Upbound Crossplane for was basically Terraform or OpenTofu.

Since starting to use Upbound Crossplane, I have not seen specific metrics for a return on investment, but it does ensure that drift does not exist. I do not have a metric that measures exactly how much I have improved in that regard, but it is a significant improvement.

My experience with the costs, initial setup, and licensing of Upbound Crossplane is that in my case there are no costs or licenses because I use the open-source version.

Before choosing Upbound Crossplane, I did not evaluate other options because I was familiar with Upbound Crossplane, and I knew it provided everything I needed. I did not evaluate any different option; I wanted to implement it directly because I knew the advantages it brought.

I gave Upbound Crossplane a rating of nine because of how it has facilitated the implementation of all those benefits in my organization. It provides me with something that is very important, and it does it really well.

My advice to other people who are considering using Upbound Crossplane is that they really give it a chance and that they consider using it not only to replace their Terraform code, but also to enable a much more self-service platform for their developers or the people who use the platform.

Our main use case for Upbound Crossplane is that we are using Kubernetes as our main platform, and we have multiple clients who will be using this Kubernetes platform for deploying their container service. Initially we were using Terraform for the infrastructure side, but since we have the application dependency and infrastructure dependency separately, most of the developers have to push their develop containers through Argo CD. For the infrastructure, they need to depend upon a separate pipeline for their Terraform deployment. We want to give the developers the ability to deploy both the containers and the infrastructures through the same GitOps way, through Argo CD. That is why we planned to have Upbound Crossplane in it.

A specific example of how we used Upbound Crossplane in that setup is when an application has a dependency on DynamoDB and an IAM role. Previously without Upbound Crossplane, our workflow looked the following way: developers would have the containers in a GitOps way in a GitOps repository, and it would deploy the containers. Then there would be a separate repository and pipeline where they have to have their own Terraform code to deploy this DynamoDB and IAM. That was two separate pipelines they needed to take care of. Now, what we are doing is in the same container repository, along with their development code, they will have this Upbound Crossplane custom resources where they can directly invoke the AWS provider by creating this DynamoDB and IAM. Using this one, they will have everything in a centralized GitOps way. Even if they want to change something on the IAM, they can simply tweak it on their GitOps repository and that will actually do the change on the infrastructure side.

In addition to our main use case, we were creating a few Compositions in Upbound Crossplane as well. It was similar to the modules in Terraform. In Terraform, we tend to create more complex modules, which means combining Dynamo, S3, and IAM as a single one. Similarly, in Upbound Crossplane, we did some Compositions where the developers just have to mention the DynamoDB name, S3 name, and IAM name. Behind the scenes, it will correlate all the resources and it will do the connections between them using this composition as a module. That would actually create a final resource and give it as an output to their containers.

The best features Upbound Crossplane offers include the reconciliation capability. Whatever change that we are doing through our GitOps, that becomes the main source of truth. Even if someone changes something on the infrastructure side manually, the reconciliation will be able to rectify it and make it a change. That is the biggest feature which I am seeing. The composition is again a good quality. We can have a complex structure without the native providers' resources that AWS or anyone gives. We can have our own composition or our own providers to be able to call the APIs on the infrastructure side.

Upbound Crossplane has positively impacted our organization by reducing the pipeline time, saving time, and decreasing cost spending. Initially, we had a separate Jenkins pipeline which would run the Terraform tasks. The developers, in order to tweak anything or in order to create any infrastructure, needed to depend on the platform team. Since we have Upbound Crossplane, they will be able to directly invoke this composition from their end. They do not need to depend on the infrastructure side, on the platform team.

One thing I have noticed about improving Upbound Crossplane is that, in Terraform, we can do a validation stage where people can say Terraform plan and see what changes it will do. It would be better if we had something in Upbound Crossplane as well. There is an option to render, I think 'crossplane render' or 'crossplane validate' will do similar to this, but it will just render the manifest, I would believe. It is not actually validating your current infrastructure with your desired infrastructure. If there is any system, something corresponding to 'crossplane plan' or, in a GitOps stage, if people push or create any new merge request, and if Upbound Crossplane can predict what it would do to the actual infrastructure, that would be really helpful.

Regarding the needed improvements in Upbound Crossplane, I think the documentation part was pretty good even at the time when I was exploring a year back. It was very useful. Using that only, we tended to create a lot of compositions and these things. The community might have improved it much better, I believe. I haven't touched upon it recently. This was the only thing that we took as a disadvantage at the time of implementing, since we did not have any way to see what the Upbound Crossplane composition or what the Upbound Crossplane resource will do to the actual infrastructure. That is the only pain point we were seeing before.

Upbound Crossplane is stable.

Regarding customer support, mostly, if I have any questions, I reach out to the community Slack channel. That is where I got most of my doubts resolved. I would say it is good. We have not tried any enterprise customer support.

I would say that the reconciliation was the biggest feature that I would highlight about Upbound Crossplane, but again, it has its own disadvantages as well that the teams were using.

The advice I would give to others looking into using Upbound Crossplane is that it is tough to get started. There are a lot of concepts that you need to be aware of. At first, you need to be aware of Kubernetes and what reconciliation is. The learning curve is much steep, I would say, if you take Upbound Crossplane, but it is worth the hassle at the same time. The GitOps way is what all the companies are moving to, so that way it will give an advantage, but the learning curve is a little high. You need to learn a lot of new concepts.

I would rate Upbound Crossplane an eight on a scale of one to ten because it still has some flaws. The pain point I previously mentioned is that we do not have clear visibility of what exactly it will do based on the YAML file that we are creating. Even if Terraform is the major infrastructure as code tool currently in the market, and it has some disadvantages such as Terraform plan which takes time, it is the market leader now. At least for the application dependency side, Upbound Crossplane definitely is a good option, which is why I rated it an eight, not a nine or ten.

Upbound Crossplane connects the cloud APIs on cloud providers like GCP, AWS, and Azure. We need to maintain the network resources and the VM containers, and the VM instance that Upbound Crossplane provides ensures the constancy and self-healing of that part. It is very useful for our use case to provision the infrastructure and create the network resources and cloud resources.

In my day-to-day work, we have a use case that I cannot disclose in detail, but in general terms, it is like this: let's suppose you want to create the VMs that will be called the edge nodes, which can offload the traffic from the edge devices to our control plane. It does this by having three or maybe four providers that we can attach to Upbound Crossplane, and it will instantly boot up the VMs. We are using temporals that will onboard the VMs and then install the software on them. The core part of Upbound Crossplane is that previously we were using Terraform, which had state lock issues, and all of that got solved when we moved to Upbound Crossplane, which keeps all state in etcd and also has auto-healing and self-reconciliation. If something happens to that particular instance, it will auto-reconcile it, and that is the main benefit of Upbound Crossplane.

My main use case for Upbound Crossplane is about connecting the public cloud providers; we even have some private providers that we can attach to it, and there is consistency we can achieve. There is the same call; we don't need to care about the cloud part because it will be automatically handled on Upbound Crossplane's side. The resources can be managed within this tool; we don't need to manually hit or create the instances or other network-related services on the cloud. We can utilize everything on Upbound Crossplane itself; it is fully managed.

One feature of Upbound Crossplane that I love is the reconciliation of the resources. If drift detection happens, it will automatically try to self-fix those resources and recreate them. That is the main part, and another benefit is that if we want to create thousands of instances or network resources, we can do that with just one API call, and everything will be handled through Upbound Crossplane. Also, it is Kubernetes-based, meaning it handles operators and Kubernetes operators that monitor the resources, and if something gets damaged, it will automatically self-heal that resource.

Most importantly, I find myself relying on the VM part of Upbound Crossplane, which we currently have. Let's suppose if any VM goes down or shifts from the ready state to another state, it will constantly watch that actual and desired state. If something changes from the desired state, it will try to reconcile that and actually create those resources. Additionally, it will have a layering with it, and it will inform the team via a Slack message; any detection will pop up on the UI, indicating that there are resources with some issues and that we are trying to reconcile them.

One area where Upbound Crossplane can be improved is with API rate limiting. For instance, if we frequently send some data to a specific API to poll the latest status of machines, it can result in exhaustion. While this isn't necessarily a fault of Upbound Crossplane, it relates to the cloud provider's side. If Upbound Crossplane retrieves the latest data, it might lead to delays or hit issues such as 429 too many requests, which should be addressed at the boundary layer if possible.

I have been using Upbound Crossplane to provision our infrastructure for one year.

Upbound Crossplane is stable.

When it comes to Upbound Crossplane's scalability, if we want to send some traffic to the outside internet, we can provision any infrastructure from Upbound Crossplane, and it will support that delete operation and, if it is in the ready state, we can route traffic to those nodes. In terms of scalability, we can create the desired number of replicas, change configurations, and manage resources dynamically. Any shortages will trigger automatic resource creation.

I have not had a chance to utilize customer support, as I have not encountered a specific reason to connect with them.

Prior to using Upbound Crossplane, we were using Terraform, which had state lock issues and lacked self-healing features. That is why we switched to Upbound Crossplane, as it effectively handles all these concerns, making our jobs easier.

Before choosing Upbound Crossplane, I evaluated various options, but I only found Upbound Crossplane to be the best choice. However, I am not recalling the solutions I looked at.

My advice for others looking into using Upbound Crossplane is this: if you are suffering from Terraform's state file locks while provisioning infrastructure and want to automate network cloud resources, reconciliation, and resource monitoring without manual intervention, then Upbound Crossplane will be very beneficial and useful. I would rate this product a nine out of ten.

My main use case for Upbound Crossplane is building layers for infrastructure platforms. I used it as a replacement for Terraform while working in an open-source project called Open Source Management and Network Orchestration by ETSI. I used it to create control planes for creating infrastructure for network workloads, specifically Telco network workloads. These include EKS clusters, workflows, and image building workflows, among other things. Mostly I work with the AWS provider, Google Cloud provider, and Microsoft Azure provider. I also built a platform layer on top of my existing toolset.

I have used Upbound Crossplane in my current organization, specifically with one of the teams. I used it to build platform layers. We had an internal developer portal, and I built a layer for the monitoring stack. It involved creating clusters to deploy Grafana, Prometheus, EFK stack, and various other tools that we continued adding. We migrated to Thanos and then Loki, and I kept adding these to the infrastructure layer while maturing the platform. Ultimately, what I provided to the developers was a monitoring API, which they called in a certain way. Actually, it was a file that they needed to push to a certain repository called Obstack. It would then trigger based on the guardrails that I had defined. I was continuing to work on the infrastructure layer, adding new tools, but the interface layer always remained the same, which was a great way to mature our platform.

A specific example of a project where I used Crossplane as a replacement for Terraform is when we had a user request a 5G network deployment. We first created the infrastructure for the workload, which could be an EKS cluster along with many things required for a 5G deployment to work. From an EKS cluster to VPC subnetting and deploying the workloads, we called it the all batteries included version of an EKS cluster. It has many network components which are required for any 5G network to work. The example use case was Free 5G Core at that time from Orange Networks. I used Upbound Crossplane to create all that infrastructure, and the benefit it gave me was the active reconciliation feature compared to Terraform because it works on a Kubernetes kind of desired state and active state approach. It will definitely monitor the infrastructure that I asked it to create and then reconcile it without me interfering, unlike Terraform, which is a fire and forget approach and will not try to monitor the infrastructure created by it. It is just basic simple API calls.

The best features of Upbound Crossplane are the analogy it brings regarding separation of concerns. As a platform team member, I can continue to work on the infrastructure layer while developers can continue to work on interacting with the APIs and getting their infrastructure done, so they could work on feature development. This kind of separation, which was always desired in a DevOps team but never truly achieved, is something I find unique to Upbound Crossplane. There are many other benefits, including the active reconciliation I mentioned. There are so many advantages regarding the data language. It always works in YAML, which I find very to the point, accurate, and very concise. It is a management headache sometimes, but there are also tools to help me manage that. I find it is better than some of the templating tools that we have, such as Helm.

Using YAML with Upbound Crossplane compared to other tools in terms of my workflow and collaboration with developers feels very comfortable for me because I see what I get. With YAML, I am basically providing any system data and then expecting a result out of it. It is very to the point and I appreciate it, but obviously developers dislike it. I sometimes use templating tools and some UI forms for developers to interact with the tools that I use, which are internally driven by YAML. For me personally, I do not see YAML as anything negative. It has always been that I appreciate it whenever a tool works on YAML. I do not need to learn any domain-specific or tool-specific knowledge.

I feel that Upbound Crossplane can be improved in terms of the providers. Back when I was using it, there were some providers which did not have a certain schema, but obviously, that is something which will always come with how the tool is maturing and how it is being adopted. There will always be the use case of taking up the code base from other tools itself. If I were to develop a provider for Terraform for Upbound Crossplane, I think there is a way to do it via the Terraform provider. If there is a Terraform provider for anything, I can develop an Upbound Crossplane provider. All those things, YAML management and schema management, I felt was a little bit more tricky when I wanted to test it from the Upbound CLI or the Crossplane CLI. It was a little bit tricky and can be improved to encourage more developers to start contributing to the provider development in Upbound Crossplane.

Regarding Upbound Crossplane's capabilities, I feel the governance and security is something which is lacking. At that time, I did not see anything related to security apart from linting. I could not find anything in the CLI itself. This is something we need to look into, and I felt that when we talk about the security of the provider, that is also something we can look into regarding checking the source code itself if there could be a way to do that. Although I find it is good because you can package your composition and check the vulnerability in your composition using any tool that you use for Docker image scanning. There could still be some additions to the CLI itself to make people look more into security from their terminal itself.

I first used open-source Crossplane back in 2022.

Upbound Crossplane is stable.

Upbound Crossplane's scalability is quite impressive. It is just another tool in the Kubernetes ecosystem. It is as scalable as I want it to be because it is deployed in Kubernetes. I can scale it as much as I want.

I used to use Terraform and I switched to Upbound Crossplane because of the benefits around active reconciliation and Kubernetes ecosystem enablement.

Before choosing Upbound Crossplane, I evaluated other options such as Pulumi. The AI capabilities around Pulumi I find very intriguing, but I felt that my organization was not as mature to push all the infrastructure responsibilities to development teams. That is why I ultimately used Upbound Crossplane as my final tool.

I find the documentation around Upbound Crossplane very good. However, I also had to look for different blogs and open-source documentation to understand how this tool actually works when I was new. Still, I would say it was one of the better-documented projects than some of the other projects that I find in open source today. I find it to the point.

I can share some specific outcomes and metrics that highlight how Upbound Crossplane helped us deliver and build faster and more reliably. We took some time in building the whole knowledge base around Upbound Crossplane and tools such as Argo CD and Argo Workflows. But it still did not take much time. It was a one-month research and development period when we were able to build our minimal viable new kind of deployment model. The benefits we saw were amazing. We went from having a 28-member troubleshooting team down to four to five members of the platform engineering team. The metrics were also great from reducing the cost. Because we were always working on cost optimization once the deployment is done, it keeps on monitoring itself. I only need to watch my Git repository. If no changes are made there, nothing will cause any troubles. We were always working with new tools in cost optimization and security such as Kubecost and Karpenter in AWS. This helped us do all the research and development in the cost optimization and security landscape, which helped us save huge costs.

I find the pricing, setup cost, and licensing of Upbound Crossplane very suitable for research and development.

I would give Upbound Crossplane a nine rating. I take off that one point due to the provider maturity. I would advise others looking into using Upbound Crossplane to start small. Solve one problem at a time with Upbound Crossplane, and then you will have many problems that you can solve in your organization, but start small with a small use case. I have one additional thought about Upbound Crossplane before we wrap up: it is all good, and I want to send my cheers to the team working behind this project. The documentation and community support are commendable. If I had to suggest anything to change for the future, I would say to keep doing what you are doing.

My main use case with Upbound Crossplane during the time I used it was creating Azure resources such as Azure containers and VMs from Kubernetes clusters and AKS clusters in an automated, fully cloud-native way.

A specific example of how I used Upbound Crossplane for this automation is that we wanted to create resources and used Tekton to manage the automated process. In our POC, we used Argo CD to manage the Azure resources so that if anything happened on the AKS cluster or on the Kubernetes resources, if someone deleted it, we could easily recreate the whole thing. That's how we managed it.

In my opinion, the best features Upbound Crossplane offers are that it runs on Kubernetes, which is the main thing. As our whole infrastructure and everything runs on Kubernetes and we manage everything with Kubernetes, it is the best option. Since we also use Argo CD to manage the cluster, we don't need to manage anything else with GitHub Actions or Terraform; we only need to manage Upbound Crossplane resources.

As I mentioned regarding managing everything through Kubernetes and integrating with Argo CD, it simplifies our workflows and reduces the need for other tools such as Terraform or GitHub Actions. In our scenario and use case, we needed to manage it through our back-end services, which were on Kubernetes, so it was easier to manage the resources through Kubernetes. From our back-end application, we could call the Kubernetes API, and we just needed to call a GitHub repo and add a file on the GitHub repo, which was very useful to manage. That's why we wanted to use Upbound Crossplane instead of Terraform.

Upbound Crossplane impacts my organization positively because, from our perspective, we need to rely on fewer resources. As it manages through Kubernetes, it is easier to manage from a back-end application to do everything. For example, if we create any resources from a back-end application, we could actually manage and keep the information in a database, so it was less of a task.

The documentation needs to be updated regarding the needed improvements for Upbound Crossplane. There is very little documentation online, and there are no tutorials for Upbound Crossplane. We can find so many more tutorials on Terraform and other resources, but there are very few tutorials for this. Whenever a new developer or a new person comes to learn about the resources, it is very helpful if they have some video documentation. So, Upbound should work on that.

My advice to others looking into using Upbound Crossplane is that Upbound should actually work more on the documentation; it would be very easy to use if someone goes through the documentation. It may work, but Upbound should definitely work more on the documentation.

I worked with Upbound Crossplane for about six months.

In my experience, Upbound Crossplane is stable.

Upbound Crossplane's scalability is very good; it is very scalable as it is running on native Kubernetes, so it was very scalable from my perspective.

We didn't use customer support with Upbound Crossplane.

Before Upbound Crossplane, we used Terraform, but from the back-end perspective, it was very hard to manage or run Terraform from the back end.

There is a return on investment, as there are fewer employees needed, but I don't have any concrete metrics because it is managed from the management team, who have the metrics. If you need it, you can contact the company.

A specific outcome or metric I can share is that we reduced the headcount by two engineers. From the initial infrastructure creation, the automation we created allowed us to build any resources based on the back-end, so no additional DevOps engineer was needed.

Regarding my experience with pricing, setup cost, and licensing, since it was open source, we didn't need any licensing fees, but it was a little difficult because there is very little documentation. Other than that, everything is acceptable.

Before choosing Upbound Crossplane, we evaluated Terraform, but it didn't align with our goal.

Overall, I don't have any additional thoughts about Upbound Crossplane; it was a really cool product. Regarding Upbound Crossplane's AI capabilities, I haven't worked on that, so I don't have knowledge about it. Concerning Upbound Crossplane's AI capabilities, I think its accuracy and reliability of output are the same; I don't know, as I didn't work with Upbound's AI capabilities, so I don't have anything to share about that. I would rate this review a nine out of ten.