Infrastructure as Data: Building a Self-Service Platform with Crossplane

GoYAMLHCLView on Github

As mission-critical infrastructure moves to Kubernetes, Crossplane is being used to transform cloud resources into declarative data. This transition is the foundation of an Internal Developer Platform (IDP), aiming to eliminate provisioning bottlenecks and empower engineering teams with a self-service model.

The Challenge: Eliminating the "Infrastructure Ticket"

A common bottleneck in high-stakes environments is the dependency on infrastructure ticket queues. During the migration of services from VMs to Kubernetes, it was recognized that if a developer needs an RDS database or an S3 bucket, they shouldn't have to wait for a separate Terraform workflow.

Drawing on roots as a Senior Developer focused on high-performance MySQL and API optimization, "Developer Velocity" is a priority. The goal is to provide "Paved Paths"—pre-configured, secure infrastructure that "just works" within the same Kubernetes ecosystem.

The Strategy: Infrastructure as Data

Crossplane was selected to extend the Kubernetes control plane. Instead of writing external HCL/Terraform scripts, infrastructure is defined as Kubernetes "Data." This strategy offers several key advantages for a modern SRE stack:

1. Continuous Reconciliation: Unlike Terraform, which only checks state during a run, Crossplane is a controller that continuously monitors for drift and automatically fixes it.
2. Unified GitOps: Infrastructure provisioning is integrated directly into ArgoCD pipelines, allowing applications and their databases to be managed in the same Git repository.
3. Abstraction via XRDs: Composite Resource Definitions (XRDs) are currently being designed. For example, a developer can request a ProductionDatabase, and Crossplane handles the complexity of provisioning the RDS instance, security groups, and defined backup policies.

Current Phase: The "Paved Path" for Managed Services

Implementation focuses on shifting the complexity of AWS configuration from the developer to the core platform. By defining resources as Kubernetes manifests, immediate auditability and resilience are gained:

# A standardized, pre-configured S3 bucket for prod-core
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
  name: prod-assets-vault
spec:
  forProvider:
    region: us-east-1
  # The platform team defines the hard security boundaries here
  deletionPolicy: Delete

When this is applied, Crossplane's AWS provider handles the underlying API calls. If an unauthorized user or a rogue script manually changes the bucket settings in the AWS Console, the Crossplane controller detects the drift and reverts it immediately.

Impact: Scaling the Internal Developer Platform (IDP)

By leading the Crossplane initiative, a platform is built that provides:

• Self-Service Provisioning: Eliminating the need for manual infrastructure tickets.
• Reduced Friction: Developers interact with the same Kubernetes APIs they are already learning for the application migration.
• Global Reliability: Entire environments can be replicated across cloud regions by syncing declarative manifests.

Conclusion

Crossplane is more than just a tool; it's the engine for the next generation of the Platform Engineering strategy. By treating infrastructure as data, a self-healing, self-service platform is built that scales with the mission-critical needs of disaster management systems.

Looking back at the journey through Full-Stack Development and Systems Integration, the goal has always been the same: simplifying complexity to let engineers focus on the high-value work of building and protecting the system.