Enabling developers to take ownership of the Platform Infrastructure
Enter Crossplane
This is your need:
I need an S3 bucket so my application can send data to it.
Simple, right? But here is the problem you are facing. Either you:
Have to open a ticket to another teamโs Jira board, wait until the S3 is in place, and iterate because something was missing.
Have to open a Pull Request in a repo from another team, typically, the โInfrastructure teamโ.
You name itโฆ
๐๐ผ You donโt have ownership of the infrastructure you need for the applications you own.
And this is a huge problem, because:
One, you depend on another team.
Two, that makes you slow when shipping your code to Production.
In todayโs email, I bring you a Cloud Native technology that would return power to developers by allowing them to own their own infrastructure.
Enter Crossplane
This is my definition:
Crossplane is a Cloud Native technology that allows you to deploy Platform Infrastructure by leveraging the Kubernetes Custom Resource API.
In short:
You deploy a Custom Resource, a YAML file, in Kubernetes,
And that will be translated into a piece of infrastructure, like an S3 bucket.
More in detail:
Crossplane works on top of the Custom Resource API from Kubernetes. Itโs an application living in Kubernetes.
Crossplane defines a set of Custom Resource Definitions.
You, as a developer, can deploy new Custom Resources, a new Crossplane Composition, to tell โhey, I want an S3 bucket with the name โACMEโโ.
And Crossplane will connect to the corresponding API (AWS S3 API in this example) to create the infrastructure indicated in the Custom Resource you deployed.
Now that you have an idea about what Crossplane is, letโs get back to the problems it solves.
1. Lack of autonomy for developers
๐ Problem:
Every time you need a database or a bucket, you must open a ticket with the platform team.
๐ With Crossplane:
The Platform Team publishes internal declarative APIs (for example,
kind: PostgreSQLInstance,kind: CacheCluster, orkind: MessageQueue) with secure defaults.You, as a developer, just create a YAML manifest with their parameters, in the same way as you would deploy a Deployment or a Service.
Crossplane translates that into an RDS in AWS, a CloudSQL in GCP, or whatever is defined in the Composition.
2. Inconsistency and risk in infrastructure
๐ Problem:
You and your peers define your own infrastructure differently, sometimes with insecure configurations.
๐ With Crossplane:
The Platform Team defines Compositions that enforce corporate standards, such as instance types, policies, regions, tags, etc.
You, as a developer, can only choose allowed parameters.
You can guarantee that you deploy a secure and standardized (within your company) infrastructure without sacrificing autonomy.
3. Artificial separation between โinfrastructureโ and โapplicationโ
๐ Problem:
The code (application) lives in Kubernetes, but the infrastructure (DBs, queues, etc.) is defined in Terraform or another external tool. This breaks the declarative model and complicates GitOps deployments.
๐ With Crossplane:
Everything lives in the same Kubernetes control plane.
Your application manifest can include both the Deployment and the PostgreSQL instance or Bucket it needs.
This results in you having infra and app versioned and deployed together under a unified declarative model.
โจ Summary
In todayโs email, I just wanted to make a heads-up about Crossplane, a technology that solves a real and important problem that the majority of us suffer from every day: Not owning our infrastructure.
In the last months, Iโve been implementing Crossplane to solve the problem described.
Iโve already learned a few things, and Iโll be sharing them with you here in the next few weeks.
If you know some friends who might be interested in this email, forward it!
Stay tuned!
Thanks for your support and feedback, I really appreciate it!
Youโre the best! ๐๐ผ
๐๐ง ๐บ๐ฐ๐ถ ๐ฆ๐ฏ๐ซ๐ฐ๐บ๐ฆ๐ฅ ๐ต๐ฉ๐ช๐ด ๐ฑ๐ฐ๐ด๐ต, ๐ต๐ฉ๐ฆ๐ฏ ๐ค๐ญ๐ช๐ค๐ฌ ๐ต๐ฉ๐ฆ ๐. ๐๐ต ๐ฉ๐ฆ๐ญ๐ฑ๐ด!
๐๐ง ๐บ๐ฐ๐ถ ๐ฌ๐ฏ๐ฐ๐ธ ๐ด๐ฐ๐ฎ๐ฆ๐ฐ๐ฏ๐ฆ ๐ฆ๐ญ๐ด๐ฆ ๐ธ๐ช๐ญ๐ญ ๐ฃ๐ฆ๐ฏ๐ฆ๐ง๐ช๐ต ๐ง๐ณ๐ฐ๐ฎ ๐ต๐ฉ๐ช๐ด, โป๏ธ ๐ด๐ฉ๐ข๐ณ๐ฆ ๐ต๐ฉ๐ช๐ด




A Good read. I did come across similar platform orchestrator humanitec which is a commercial tool.
In my evaluation POCs, I have come across a k8s native sdk CDK8S using which we can have our own cross plane type orchestrator. I did do some POC and what I understood is I can create my own k8s constructs and have a single CRD that can give multiple k8s Kind. Here developer provides every config that is needed for his app to be up and running.
What are your thoughts of build vs buy on platform orchestrator?
I would love to hear from folks about your experiences about how do you deploy your infrastructure.