Why We Chose Control Plane for Multicloud Infrastructure

We didn't choose multicloud because it's trendy.

We chose it because one portfolio company needs AWS for compliance, another needs GCP BigQuery for massive geospatial analysis, and a third needs Azure for enterprise customer integration.

But here's the truth: managing multiple clouds separately is operational hell.

Different CLIs. Different IAM models. Different networking. Teams become experts in one cloud provider, then can't transfer that knowledge to the next project. Portfolio companies spend 30% of engineering time on infrastructure instead of building product.

That's not a portfolio company problem. That's a Grey Haven problem.

So we needed a solution that lets us:

• Deploy anywhere without vendor lock-in
• Maintain consistency across all portfolio companies
• Eliminate the need for dedicated DevOps teams
• Cut cloud costs (startups can't waste money)
• Stick to our "consistency over novelty" philosophy

Enter Control Plane.

The Multicloud Problem Nobody Talks About

Everyone focuses on egress fees. "AWS charges $0.09/GB to leave!" True, but that's not the real cost.

The real cost is operational lock-in.

The Hidden Costs That Actually Matter

Different Everything:

• AWS uses aws CLI with one syntax
• GCP uses gcloud with completely different flags
• Azure uses az with yet another approach

Your team learns AWS CloudFormation. Great. Now they need to learn GCP Deployment Manager. And Azure Resource Manager. And Terraform providers for all three.

Credential Hell:

To access AWS S3 from a container:

1. Create IAM role with S3 permissions
2. Generate access keys
3. Store keys in environment variables
4. Embed keys in application code
5. Rotate keys periodically (security requirement)
6. Repeat for every cloud provider × every service

One portfolio company had 47 different credential files scattered across projects. Nobody knew which were still active. Half pointed to development environments that no longer existed.

The Talent Problem:

You know what's worse than not finding multicloud talent? Finding them, training them on your specific setup, then watching them leave for 40% more money at a bigger company.

The Time Sink:

Portfolio companies spend 30% of their time on infrastructure instead of product features. DevOps tasks that should take one day took five days. Not because the engineers were slow—because multicloud operations are genuinely that complex.

When Multicloud Actually Makes Sense

Let's be honest: most companies don't need multicloud.

If you're:

• An early-stage startup (pick one cloud, move fast)
• Building a simple CRUD app (standard web apps don't need this)
• A small team (<10 engineers) without growth plans

Pick AWS. Or GCP. But pick one and stick with it.

Multicloud makes sense when:

1. Best-of-Breed Services

• You need Google BigQuery (no AWS equivalent for massive geospatial analysis)
• You want GCP Vertex AI for training, AWS SageMaker for inference
• Enterprise customers require Azure integration

2. Compliance & Regulatory

• Financial services need data residency in specific regions
• HIPAA compliance requires specific cloud configurations
• Government contracts dictate FedRAMP/GovCloud

3. Cost Optimization

• Spot instances from cheapest provider at any moment
• Negotiation leverage: "We can move workloads" = better pricing

4. Risk Mitigation

• AWS US-East-1 goes down (it happens). Failover to GCP automatically.
• Vendor diversification avoids complete dependency on one provider's business decisions

For Grey Haven's portfolio companies, it's usually option 1: they need specific services only available on certain clouds, but don't want to be locked in operationally.

What We Actually Needed

Let's be specific about requirements:

Portfolio Company Scale:

• Teams of 5-15 engineers
• 3-10 microservices typically
• No dedicated DevOps team (can't afford it)
• Mix of languages (Python, TypeScript, Go)

Grey Haven Consistency Requirements:

• Same deployment process across all companies
• Reduce onboarding time for new engineers
• Knowledge transfer between portfolio companies
• Fits our "consistency over novelty" philosophy

Technical Non-Negotiables:

• Deploy to any cloud provider
• Automatic cost optimization (startups bleed money on overprovisioned infrastructure)
• Built-in observability (no separate monitoring stack to manage)
• Production-grade reliability (99.9%+ uptime)
• Minimal operational overhead

What We Were Willing to Give Up:

• Some Kubernetes control (we don't need every K8s feature)
• Direct cloud provider access for edge cases (can work around it)
• Cutting-edge features (stability > novelty)

Why Not Terraform/Pulumi/Raw Kubernetes?

We evaluated the obvious alternatives. None fit.

Terraform/Pulumi: Wrong Layer

What they are: Infrastructure as Code tools. Define cloud resources (VPCs, databases, DNS) in code, version control them, deploy declaratively.

Why we didn't choose them:

Terraform provisions infrastructure but doesn't manage running applications.

You can:

• Create a Kubernetes cluster? Yes.
• Deploy an app to that cluster? Not really Terraform's job.
• Manage credentials across clouds? Manual.
• Optimize costs automatically? No.
• Handle monitoring and logging? Separate tools needed.

Terraform creates the foundation. You still need something to deploy and manage applications on top of that foundation.

State Management Complexity:

Terraform state files are a disaster waiting to happen. Corruption means infrastructure disaster. Team collaboration requires remote state (S3 bucket + DynamoDB for locking, or pay for Terraform Cloud).

One portfolio company had three engineers accidentally run terraform apply simultaneously before we set up remote state. Spent two days untangling the mess.

When Terraform Makes Sense:

• Provisioning base infrastructure (VPCs, databases, DNS)
• Organizations with dedicated platform teams
• When you need extreme customization

Can You Use Both?

Yes. Use Terraform to provision infrastructure, Control Plane to deploy/manage applications. We do this for some complex setups.

Raw Kubernetes: Too Much Operational Burden

What it is: Manage EKS (AWS), GKE (Google), or AKS (Azure) directly.

Why we didn't choose it:

Operational Overhead:

• Cluster upgrades every few months
• Security patches constantly
• Monitoring, logging, tracing setup
• Certificate management
• Load balancer configuration
• Ingress controller setup
• Service mesh if you need it

Casai couldn't find/retain DevOps talent to manage this. We face the same problem.

Multi-Cloud Complexity:

EKS, GKE, and AKS have different:

• APIs (different kubectl contexts, different cloud-specific resources)
• CLIs (eksctl, gcloud container, az aks)
• Networking models (different VPC/subnet approaches)
• IAM integrations (AWS roles, GCP service accounts, Azure AD)

Cross-cloud networking requires manual VPN/peering setup. One misconfigured security group and your services can't talk to each other.

No Cost Optimization:

You specify CPU/memory requests. Kubernetes allocates that capacity. You pay for it whether you use it or not.

Overprovision = waste money. Underprovision = performance degrades, apps crash.

Manual optimization means constantly adjusting resource requests based on Prometheus metrics. That's a full-time job.

When Raw Kubernetes Makes Sense:

• Large teams (50+ engineers) with dedicated platform teams
• Need cutting-edge K8s features not yet in platforms
• Regulatory requirements demanding full infrastructure control

Crossplane: Kubernetes-Native, But Steep Learning Curve

What it is: Open-source tool extending Kubernetes to manage cloud infrastructure. Define S3 buckets, databases, networks as Kubernetes Custom Resources.

Why we didn't choose it:

Requires Deep Kubernetes Knowledge:

Crossplane is for teams that already live and breathe Kubernetes. You must understand:

• Custom Resource Definitions (CRDs)
• Kubernetes controllers
• Reconciliation loops
• Composition resources

Portfolio companies explicitly chose Control Plane because it's "far easier to learn" than Crossplane.

Self-Managed:

You run Crossplane controllers in your clusters. You maintain Crossplane upgrades. You debug when compositions fail. You monitor the controllers themselves.

That's the operational burden we're trying to eliminate, not add.

Still Need Application Management:

Crossplane provisions infrastructure. You still need to:

• Deploy applications
• Manage application lifecycle
• Handle secrets and credentials
• Set up monitoring
• Optimize costs

When Crossplane Makes Sense:

• Already heavily invested in Kubernetes
• Have platform engineering team to maintain it
• Want infrastructure-as-code in K8s-native format

How Control Plane Actually Works

Control Plane is a managed multicloud platform built on Kubernetes but abstracting away the complexity.

You don't need to be a Kubernetes expert. You don't manage clusters. You define your application once, and Control Plane handles deployment, scaling, networking, monitoring, and cost optimization across any cloud.

Global Virtual Cloud (GVC)

The foundational concept: a GVC is a collection of cloud locations that act as a single unified deployment target.

# gvc-config.yaml
kind: gvc
name: production-api
spec:
  staticPlacement:
    locationLinks:
      - //location/aws-us-west-2
      - //location/gcp-us-central1
      - //location/azure-eastus
  domain: api.mycompany.com

Deploy an application to this GVC, and it runs in all three clouds automatically.

What Control Plane Handles:

• Infrastructure provisioning in each cloud
• Load balancing with geo-routing (users hit the nearest healthy location)
• TLS certificate management (automatic Let's Encrypt)
• DNS configuration
• Health checks and automatic failover

The Result:

• 99.999% uptime (5.26 minutes/year max downtime)
• 20-30ms global response times
• If AWS fails, traffic routes to GCP/Azure transparently

Universal Cloud Identity™

This is the killer feature that eliminates credential hell.

The Old Way:

To access AWS S3 and GCP Cloud Storage from the same application:

# Embed credentials (terrible security)
s3_client = boto3.client(
    's3',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
)

gcs_client = storage.Client.from_service_account_json(
    'path/to/service-account-key.json'
)

Credentials in environment variables. Committed to Git by accident. Rotated manually every 90 days. Different approach for each cloud.

The Control Plane Way:

Define an identity once:

# identity.yaml
kind: identity
name: storage-access
spec:
  aws:
    cloudAccountLink: //cloudaccount/aws-prod
    policyRefs:
      - "arn:aws:iam::123456789:policy/S3ReadWrite"

  gcp:
    cloudAccountLink: //cloudaccount/gcp-prod
    bindings:
      - roles: ["roles/storage.objectViewer"]

Assign to workload:

kind: workload
name: api-server
spec:
  identityLink: //identity/storage-access
  container:
    image: myregistry/api:v1.2.3

In your application code:

# No credentials needed. Cloud SDKs find them automatically.
s3_client = boto3.client('s3')  # Just works
gcs_client = storage.Client()    # Just works

How it works:

Control Plane uses each cloud's native IAM mechanisms:

• AWS: Temporary credentials via IAM roles
• GCP: Service account tokens
• Azure: Managed identities

Your container gets credentials automatically, with automatic rotation, no embedded secrets, and unified access control.

Real Impact:

Portfolio companies use Universal Cloud Identity to access AWS RDS, S3, SQS, Lambda AND GCP BigQuery from the same application. No credential management. No separate authentication logic.

Cloud Wormhole™

Secure access to private network resources without exposing them to the internet.

The Problem:

Your database is in an AWS VPC (10.0.1.50:5432). Your application runs in Control Plane. How does it connect?

Traditional Solutions:

• Open VPC to internet (terrible security)
• Set up VPN (complex, manual, requires networking expertise)
• Use bastion hosts (operational overhead, slow)

Control Plane's Solution:

Deploy Control Plane agent in your private network:

# Deploy agent in AWS VPC
kind: agent
name: vpc-agent
spec:
  cloudAccountLink: //cloudaccount/aws-prod
  vpc: vpc-0abc123

Define network resources in identity:

kind: identity
name: database-access
spec:
  networkResources:
    - name: "postgres-primary"
      agentLink: //agent/vpc-agent
      IPs: ["10.0.1.50"]
      ports: [5432]

Assign to workload:

kind: workload
name: api-server
spec:
  identityLink: //identity/database-access

In your application:

# Connect to private IP as if it's local
conn = psycopg2.connect(
    host="10.0.1.50",
    port=5432,
    database="production"
)

Control Plane routes the connection through the agent automatically. Encrypted tunnel. No public exposure. No VPN configuration.

Capacity AI™

Automatic resource optimization that slashes costs.

The Problem:

Kubernetes requires CPU/memory requests and limits. Get it wrong:

• Overprovision: Pay for unused capacity (wasteful)
• Underprovision: Performance degrades, apps crash

Most teams overprovision "to be safe." That's where the money bleeds.

Control Plane's Solution:

Enable Capacity AI:

kind: workload
name: api-server
spec:
  container:
    image: myregistry/api:v1.2.3
    # Don't specify CPU/memory. Let Capacity AI handle it.
  options:
    capacityAI: true
    autoscaling:
      minScale: 0 # Scale to zero when idle
      maxScale: 10

Capacity AI analyzes historical usage and automatically adjusts resources:

• Starts with minimal resources
• Scales up based on actual demand
• Scales down during low-traffic periods

Result: ~10x reduction in RAM consumption, 60-80% cost savings vs manual sizing.

Pricing: You pay only for actual CPU/RAM used:

• CPU: $0.062 per millicore-month (~$62/core-month)
• RAM: $0.007 per MB-month (~$7/GB-month)

Compare to AWS Fargate: $0.04048/vCPU-hour + $0.004445/GB-hour = significantly more expensive, and you pay for provisioned capacity, not actual usage.

What We Gave Up (The Honesty Section)

Control Plane isn't perfect. Here's what we traded away.

Less Control Than Raw Kubernetes

Control Plane abstracts away Kubernetes complexity—which is usually a feature, but can be a limitation.

What you can't do:

• Custom Kubernetes operators not supported by Control Plane
• Specialized networking plugins (custom CNI configurations)
• Cutting-edge K8s alpha/beta APIs
• Complete control over cluster configuration (kubelet flags, etc.)

Trade-off: We don't need that level of control. Our portfolio companies aren't building internal K8s distributions. They're building products.

If you need extreme customization, manage your own clusters. We chose operational simplicity over maximum flexibility.

Platform Abstraction Overhead

Control Plane adds a small networking layer (~1-3ms latency) for routing and service mesh.

Trade-off: For most applications, 1-3ms is invisible. For high-frequency trading or real-time gaming? Use bare metal or direct VMs.

Our portfolio companies are building SaaS products, data analytics platforms, AI agents. The operational benefits far exceed 1-3ms of latency.

Newer Ecosystem

Control Plane has fewer tutorials and community resources than AWS/GCP/Kubernetes directly.

Trade-off: Aligns with our "consistency over novelty" philosophy. We'd rather have a stable, well-documented platform than chase the latest trends.

Control Plane's documentation is excellent. Their support team is responsive. We've built internal knowledge that compounds across portfolio companies.

Managed Service Dependency

Control Plane's control plane infrastructure runs in their account. You don't self-host it.

Trade-off: Fine for us. Not fine for government contractors or organizations with "all infrastructure in our account" requirements.

Control Plane offers BYOK (Bring Your Own Kubernetes) for those use cases, but that adds operational complexity we're trying to avoid.

When You Should NOT Use Control Plane

Let's be direct.

1. Very Small Workloads (<$100/month cloud spend)

Control Plane has minimum costs (~$50-100/month). For hobby projects or pre-revenue MVPs, free tiers from cloud providers or simple PaaS (Heroku, Render) are cheaper.

When to switch: Once you're spending >$200/month on cloud infrastructure.

2. Very Large Scale (>$100K/month cloud spend)

Large enterprises with negotiated AWS/GCP discounts (60-70% off list price) and dedicated platform teams may build custom solutions more cost-effectively.

Control Plane is optimized for small-to-mid-size teams (5-100 engineers).

3. Need Extreme Kubernetes Customization

If you're building internal K8s distributions with custom operators, specialized networking, or cutting-edge features, raw K8s gives you more control.

4. Complex Stateful Workloads

Control Plane supports stateful workloads but with limitations. Complex database clustering (Galera, Cassandra with specific topology) may be challenging.

Our approach: Use managed databases (AWS RDS, GCP Cloud SQL) and access them from Control Plane via Universal Cloud Identity. Don't run critical databases in Control Plane.

5. Real-Time/Ultra-Low-Latency (<1ms Requirements)

High-frequency trading, real-time gaming, or applications requiring sub-millisecond latency should deploy directly on VMs or bare metal.

6. Early-Stage Startups (Pre-Product-Market Fit)

If you're still figuring out product-market fit, pick one cloud provider and move fast. Don't over-engineer multicloud before you need it.

When to adopt Control Plane: Once you have customers, predictable growth, and >$200/month cloud spend.

How It Fits Our Unified Stack

Control Plane is part of Grey Haven's unified tech stack:

Frontend & API: TanStack Start (full-stack React with server functions) Infrastructure: Control Plane (multicloud deployment and management) Database: PlanetScale (serverless MySQL with branching) LLM Framework: Mirascope (structured LLM outputs, tool calling) Vector Search: TurboPuffer (fast vector search without enterprise pricing)

The Philosophy:

Pick stable tools once. Get world-class at them. Reuse expertise across all portfolio companies.

Why Control Plane Fits:

1. Consistency across portfolio: Same deployment process everywhere
2. Deploy anywhere flexibility: Portfolio companies choose cloud based on needs, not our framework's limitations
3. Reduces onboarding time: New engineers learn Control Plane once, productive across all companies
4. Enables knowledge transfer: Solutions from one portfolio company work in others
5. Operational simplicity: Small teams don't need dedicated DevOps

Real Impact:

When a new engineer joins any Grey Haven portfolio company, they learn our stack once. Control Plane deployment. TanStack Start patterns. Mirascope agent orchestration. TurboPuffer vector search.

That knowledge transfers. Move to another portfolio company? You're already productive.

That's the compounding value of consistency.

Multicloud Without the Complexity

Multicloud isn't about avoiding commitment. It's about operational flexibility.

Control Plane makes multicloud practical for small teams by:

• Abstracting away cloud provider differences
• Eliminating credential management hell
• Providing automatic cost optimization
• Including built-in observability
• Reducing operational burden to near-zero

The cost savings are real: 60-80% typical reduction, with customers reporting 75-90% savings.

The productivity gains are real: 30% of engineering time saved, DevOps tasks that took 5 days now take 1 day.

The operational simplicity is real: Teams of 5-15 engineers deploy to multiple clouds without dedicated DevOps.

For Grey Haven's portfolio companies, Control Plane enables the best of both worlds: multicloud flexibility with single-cloud simplicity.

We're not chasing novelty. We're choosing stability that lets our companies move fast.

That's the unified stack philosophy in action.

---

At Grey Haven, we've deployed Control Plane across multiple portfolio companies. We've seen 60-80% cost reductions, 30% productivity improvements, and elimination of dedicated DevOps overhead. We know what works in production at scale.

Want to learn more about our unified tech stack? Read Part 1: Why We Ditched Next.js for TanStack Start, Part 3: Why We Chose Mirascope Over LangChain, Part 4: TurboPuffer Vector Search, and Part 5: PlanetScale PostgreSQL vs Supabase.

Building AI products and need infrastructure that scales without bleeding money? Let's talk.