The Control Plane Manifesto

This document outlines the strategic direction for our SmoothGlue platform. It is our "why"—the core philosophy that guides our architecture, our tool choices, and our mission to provide a world-class platform that accelerates development, ensures security, and simplifies operations for everyone.

Executive Summary: From Friction to Flow #

For years, building and deploying software has involved a painful handoff between Developers, Site Reliability Engineers (SREs), and Security. Each team speaks a different language, uses different tools, and optimizes for different outcomes. This creates friction, slows down delivery, and introduces risk. Our developers want to ship features; our SREs want stability; our security team wants to ensure compliance. Today, these goals are often in conflict.

Our platform strategy is designed to solve this fundamental problem by creating a single, unified control plane built on Kubernetes. Think of it as a universal translator and a central factory for all the resources our applications need.

Instead of developers learning five different tools to request a database or configure a security policy, they make a simple, standardized request. The platform intelligently interprets this request and provisions the right resource for the right environment—be it a simple database for a test environment or a highly-available, multi-region database for production on AWS or Azure.

By choosing Crossplane as the engine for this control plane, we are adopting a community-backed, production-ready standard. This allows us to:

1. Increase Velocity: Developers get what they need, faster, through a simple, self-service model.
2. Reduce Complexity: We hide the underlying differences between clouds (AWS, Azure, etc.) and environments, presenting a single, consistent experience.
3. Enhance Security & Governance: All resources, from the application to the database, are managed in one place, allowing us to apply security policies, audits, and guardrails consistently.

This is a multi-year strategic investment that moves us from manually stitching together disparate systems to building a true, scalable platform-as-a-product. It is the foundation for our next phase of growth and efficiency.

The Deeper Dive: Our Platform Philosophy #

The Core Problem: A Tale of Many Languages #

The central challenge we face is impedance matching. Our developers, SREs, and security experts all have valid concerns, but their tools and workflows don't naturally align.

• Developers care about their application code. They live in Git, container images, and Helm charts. They (begrudgingly) understand Kubernetes manifests for their app.
• SREs care about infrastructure, reliability, and observability. They live in tools like Grafana, Terraform, SSH, and cloud-specific consoles.
• Security cares about policy, identity, and compliance. They need to enforce rules across every layer of the stack.

In the past, we bridged these worlds with fragile, custom-coded scripts and complex CI/CD pipelines—stitching Terraform outputs into Helm values, managed by one central team. This model was a bottleneck. It didn't scale, was prone to errors, and created a dependency on a small group of experts.

Our Guiding Principle: The Orchestrator is the Overmind #

Our strategy is to move as much of the "heavy lifting" as possible into the one layer we can guarantee is consistent everywhere: the Kubernetes control plane.

We're not just using Kubernetes to run containers; we're leveraging its powerful, extensible API as the central point of truth for our entire platform. Why here? Because we get a massive head start:

• A Universal API: Kubernetes provides a stable, extensible API server with role-based access control (RBAC), auditing, and everything else we need, for free.
• A Home for Policy: With tools like Kyverno, we can enforce security policies, validate configurations, and even automatically mutate objects to inject required settings.
• A Familiar Interface: Developers already work with Kubernetes manifests. Extending this to include the infrastructure their app needs is a natural, incremental step.

This is our "stable ground." Everything below this layer is cloud-specific and variable. By building here, we create an abstraction that can endure changes in the underlying infrastructure. Yes, there is work to bridge that (a ton of it, in fact), but we have to pick our battles.

The Magic Ingredient: Crossplane and True Lifecycle Management

If Kubernetes is our foundation, Crossplane is the engine we install on top. It teaches the Kubernetes API to speak the language of external services like AWS, Azure, and GCP.

This is the key that unlocks true lifecycle management, a concept that declarative, one-shot tools, like Terraform, cannot provide on their own.

• Constant Reconciliation: Crossplane doesn't just create a resource; it constantly monitors it. If a configuration "drifts" from its desired state (due to manual changes or errors), Crossplane automatically corrects it. This enforces security and repeatability.
• Ownership and Garbage Collection: Every resource is owned by another, creating a clear chain of custody. When you delete an application, Crossplane can automatically clean up all the databases, user accounts, and permissions associated with it, preventing orphaned resources and cost overruns.
• The Power of Composition: This is the real magic. We can define our own, simplified APIs. We create a custom API called PostgreSQLInstance.
  • A developer requests a PostgreSQLInstance for their app.
  • Behind the scenes, Crossplane checks the environment. In dev, it might provision a simple in-cluster Postgres pod. In prod on AWS, it provisions a highly-available, multi-region RDS instance with backups and encryption enabled.
  • The developer’s request remains the same. The platform handles the translation. We define the "what," and the platform figures out the "how."

This allows us to bundle an application with all its external needs into a single, manageable unit that can be deployed anywhere with a single command.

Addressing the Challenges Head-On #

No strategy is without its tradeoffs. We are clear-eyed about the challenges and are actively working to mitigate them.

• "Is everything just YAML?" The underlying API is declarative YAML, but this doesn't have to be the primary user interface. This API-first approach allows us to build intuitive "clicky GUIs" in the Console on top, hiding the complexity for most users.
• "Are we locked into Kubernetes?" Yes, and this is a deliberate strategic bet. The Cloud Native Computing Foundation (CNCF) ecosystem, with Kubernetes at its core, is the industry standard for building modern platforms. Planning for a world beyond it today would be premature optimization. We see this not as a lock-in, but as a commitment to a stable, vibrant, and future-proof ecosystem.
• "What about dependency on an external project?" Crossplane is a graduated project within the CNCF, the same home as Kubernetes. This provides a strong guarantee of neutrality and longevity. It is no different from our reliance on other critical open-source tools, like GitLab or Zarf.
• "How do we prevent accidental deletion?" This is our most critical operational challenge. A single kubectl delete command could, in theory, wipe out an application, its data, and its encryption keys. We must architect robust solutions for this, including:
  • Fortifying Permissions: Implementing stricter, fine-grained RBAC to limit who can perform destructive actions.
  • Architectural Safeguards: Designing our Crossplane compositions with deletion policies and backup mechanisms that are specific to each cloud and infrastructure, ensuring data is retained even if the resource definition is removed.