I've been looking at Crossplane, which takes the Kubernetes operator pattern and applies it to cloud infrastructure, a significant shift from traditional Terraform state files and CLI operations
Crossplane runs inside a Kubernetes cluster, providing a set of providers for AWS, Azure, GCP, and Helm, that map Kubernetes custom resources to cloud resources, allowing you to define an S3 bucket as a Kubernetes YAML manifest
The AWS provider in Crossplane ensures the bucket exists and matches the spec, using the same reconciliation loop as any Kubernetes controller, with the desired state declared in the cluster and the actual state in the cloud, continuously reconciled
For example, I've seen this in action with a team that used Crossplane to manage their AWS RDS instances, they defined a custom resource for their database setup and Crossplane handled the provisioning and updates, the team was able to manage their database infrastructure using the same tools and workflows they used for their Kubernetes applications
One of the key features of Crossplane is its Composite Resource Definition, which lets platform teams define higher-level abstractions over raw cloud resources, such as a 'PostgreSQLInstance' that provisions an RDS instance, a parameter group, a security group, and a Secrets Manager secret
I've worked with teams that have used this feature to define abstractions for their specific use cases, such as a 'webserver' that provisions an EC2 instance, a security group, and an Elastic IP, this abstraction layer decouples application teams from cloud-provider specifics, so the application team can request a webserver without worrying about the underlying resources
This abstraction layer decouples application teams from cloud-provider specifics, so the application team can request a PostgreSQLInstance without worrying about the underlying resources, and the platform team defines what that means in terms of cloud resources
Using Crossplane with around 50 custom resources, we've seen the overhead of the control plane to be around 10-15% of the total cluster resources, which is a trade-off we're willing to make for the ease of management and automation it provides, and with the right monitoring and logging in place, we've been able to catch and fix issues before they become incidents
Crossplane also integrates naturally with GitOps tools like Flux and ArgoCD, where Crossplane manifests are stored in Git, the GitOps operator applies them to the cluster, and Crossplane reconciles the cloud state, allowing infrastructure changes to be reviewed as pull requests
I've seen this integration in action with a team that used Flux to manage their Crossplane manifests, they were able to review and approve infrastructure changes in the same way they reviewed code changes, which helped to reduce errors and improve collaboration between teams
The full cloud provisioning history is stored in Git, making it easy to track changes and roll back to a previous version with a simple git revert followed by the GitOps sync
When comparing Crossplane to Terraform, it's clear they solve the same problem, but differently, Terraform is a CLI tool with state files that is run explicitly, while Crossplane is a continuously running control plane that maintains desired state, each with its own trade-offs
For instance, Terraform is a good choice when you need to manage a small number of cloud resources and don't need the automation and scaling that Crossplane provides, but as the number of resources grows, Crossplane becomes a more attractive option, with its ability to handle large numbers of resources and automate the provisioning and updates
In my experience, the choice between Crossplane and Terraform comes down to the specific needs of your team and the trade-offs you're willing to make, both tools have their strengths and weaknesses, and it's worth taking the time to evaluate them and choose the one that best fits your use case