crossplane
Find ways to slim down provider binary sizes
What problem are you facing?
This issue doesn’t significantly impact us, but we noticed that the container images generated from Upjet-based providers (specifically the AWS provider in this case) are quite large.
For reference, the S3 image is 768MB:
REPOSITORY TAG IMAGE ID CREATED SIZE xpkg.upbound.io/upbound/provider-aws-s3 v1.20.1 0ea4c3c5e06f 17 seconds ago 768MB
I then performed a raw go build over the cmd/provider/sqs zz_main.go file, which resulted in a binary that's 1.1GB in size:
-rwxr-xr-x@ 1 jakub staff 1.1G Mar 5 15:58 sqs
This build is based on the c47300 commit. For comparison, the Go 1.24 binary is around 18MB.
How could Upjet help solve your problem?
We could find ways to slim down the generated binary, which would reduce the size of the container images, saving storage space and speeding up deployments.
Additionally, the build time seemed quite long. Optimizing the binary size could likely reduce build times significantly.
Some related issues/discussions:
- https://github.com/aws/aws-sdk-go-v2/issues/2933
- https://github.com/aws/aws-sdk-go-v2/discussions/3053
- https://github.com/alecthomas/kong/discussions/517 - quite a few packages use text/template or reflect.MethodByName which prevents full DCE
Files which "include everything":
- apis/zz_register.go should probably be per-provider instead of global
- config/provider.go should also be per provider
- internal/controller/zz_*_setup.go too
- vendor/github.com/hashicorp/terraform-provider-aws/internal/provider/service_packages_gen.go also. This one is probably harder to do as it's part of an external package.
Those four changes makes the s3 provider go from 1.1 GB to 773 MB on my Mac machine (690 MB after strip). For v2 there should also be done some work to avoid size increases.
