Infrastructure · Cloud-Native
Complete cloud environments on request, from a single definition
A team asks for an environment and gets networking, a Kubernetes cluster, a private database, secret storage and access rules — the same way every time, created and kept in shape automatically.
Proof of concept: Crossplane Azure Environment Factory
Where this helps
- Spinning up development and test environments in minutes
- Enforcing company standards for every cloud resource
- Self-service for developers without handing out full cloud access
The rest of this page is the technical deep dive — how it was built and what its limits are.
The technical problem
Spinning up a complete team environment on Azure — networking, an AKS cluster, a private PostgreSQL database, Key Vault and access control — usually involves several tools and pipelines.
How the architecture works
- 01 · Claim
A team applies one namespaced environment claim.
- 02 · XRD
The Composite Resource Definition defines the self-service API and its parameters.
- 03 · Composition
Maps the claim to resource groups, VNet and subnets, AKS, private PostgreSQL, Key Vault and RBAC assignments.
- 04 · Providers
Crossplane Azure providers create and continuously reconcile the managed resources.
What was being explored
Whether a platform team can offer complete cloud environments as a self-service Kubernetes API, so that application and infrastructure changes follow the same declarative, GitOps-friendly workflow.
Why this approach
Terraform is excellent at provisioning, but it lives outside the cluster in separate pipelines. Crossplane keeps infrastructure under continuous reconciliation by the Kubernetes control plane and lets the platform team publish a narrow, opinionated API instead of exposing every cloud setting.
What was implemented
Provider installation and configuration, the composite resource definition, a composition function and composition covering six Azure service areas, and an example environment claim, with step-by-step setup and troubleshooting instructions.
What it demonstrates
A multi-service environment with private networking can be expressed as one declarative request, and the composition becomes the single place where standards — naming, networking, access — are enforced.
Limitations and next steps
- The setup authenticates with a service principal that has the Owner role; a real platform would use narrower roles and workload identity.
- Covers one environment shape; real platforms usually need versioned compositions and per-environment sizing.
Related writing
From Terraform to Crossplane: Unifying Apps and Infrastructure Under Kubernetes
Addresses the “two-world” problem of apps in Kubernetes and infrastructure in separate Terraform pipelines. Covers Crossplane's XRDs, Compositions and Claims, how they fit GitOps, and a practical Azure example.