"Where Terraform can fall apart is when more engineers need to collaborate to manage their organisation’s infrastructure."
I have seen this _so often_, with large teams of Engineers resorting to one of two methods to deal with the terraform sprawl:
1. Breakup the terraform into ever smaller modules, which reduces blast radius of the drift, but at the cost of visibility.
2. "-target" applies. Which amounts to basically the same thing as #1.
Terraform offers small teams a common language for controlling their infrastructure, and an efficient method of comparing desired state to actual state. Crossplane appears to have a clear yaml syntax (easy enough to commit to source control) and runs a control plane for enforcement (easier than setting up Atlantis, I imagine).
> It also raises the level of configuration abstraction for application developers without raising the level of access control abstraction.
This may be the most interesting point in this post. Terraform (and cloud provider APIs for that matter) are not built for developer self-service, not because they are complicated, but because the developer must be given credentials to perform the granular operations, even if they are interfacing with a higher-level interface. Crossplane flips this model by instead saying that the developer is only given permission to perform operations at the interface they are interacting with and the operator (in this case a Kubernetes controller) that satisfies the high-level request by performing granular operations is given permissions for those operations. This greatly simplifies the model for both the platform builder and the platform consumer. The builder is responsible for defining the interface and exposing it to consumers. The consumer knows that if they have RBAC on an abstraction, the underlying operations can be performed on their behalf.
Many folks are using GitOps with Flux/ArgoCD to deploy their k8s apps but they can't use Terraform in the same workflow. How does Crossplane help get to a single GitOps workflow so app teams can self-service the infra from within the app cluster alongside their k8s app Deployments?
OP here - this is enabled by a mix of tooling consistency (e.g. everything can happen in the same Kubernetes API server) and carefully designing our "managed resources" - the custom resources that represent bits of infra - to be able to reference each other in an eventually consistent way. For example you can create a firewall rule in Crossplane before you create the database instance it applies to. The firewall rule controller will go into backoff until the database is created, at which point everything will fall into place.
I have seen this _so often_, with large teams of Engineers resorting to one of two methods to deal with the terraform sprawl:
1. Breakup the terraform into ever smaller modules, which reduces blast radius of the drift, but at the cost of visibility. 2. "-target" applies. Which amounts to basically the same thing as #1.
Terraform offers small teams a common language for controlling their infrastructure, and an efficient method of comparing desired state to actual state. Crossplane appears to have a clear yaml syntax (easy enough to commit to source control) and runs a control plane for enforcement (easier than setting up Atlantis, I imagine).