Radius Application Platform — Microsoft's Open Source Answer to Kubernetes Complexity

Kubernetes is powerful and undeniably complex. The ecosystem response to that complexity has produced a wave of abstraction layers — Score, Crossplane, Backstage, OAM, and now Radius.

Radius was built by Microsoft, open-sourced in October 2023, and accepted into CNCF Sandbox in 2024. It takes a distinct approach: instead of abstracting Kubernetes resources, it tries to model the entire application — including cloud services, connections between components, and deployment targets — in a single unified spec.

Let me tell you what it actually does, where it's interesting, and where it falls short.

The Problem Radius Is Solving

The classic problem: a developer needs to deploy a web service that connects to a Redis cache, a PostgreSQL database, and reads secrets from Azure Key Vault. On Kubernetes, this means:

• Deployment YAML (the service)
• Service YAML (networking)
• ConfigMap (config)
• ExternalSecret (pull secrets from Key Vault)
• Redis operator CRD (or Helm chart values)
• PostgreSQL operator CRD (or RDS Terraform)
• NetworkPolicy (connect everything)
• ServiceAccount + RBAC (permissions)

Eight different YAML files, multiple tools, and the developer needs to understand all of them.

Radius wants to replace this with:

// app.bicep — the entire application in one file
import radius as rad
 
@description('The Radius Application ID')
param application string
 
resource webAPI 'Applications.Core/containers@2023-10-01-preview' = {
  name: 'web-api'
  properties: {
    application: application
    container: {
      image: 'myregistry.io/web-api:v1.2.3'
      ports: {
        web: { containerPort: 8080 }
      }
    }
    connections: {
      cache: { source: redisCache.id }
      db: { source: postgresDB.id }
    }
  }
}
 
resource redisCache 'Applications.Datastores/redisCaches@2023-10-01-preview' = {
  name: 'redis-cache'
  properties: {
    application: application
    environment: environment
  }
}
 
resource postgresDB 'Applications.Datastores/postgresDatabases@2023-10-01-preview' = {
  name: 'postgres-db'
  properties: {
    application: application
    environment: environment
  }
}

Radius handles the rest — deploying to Kubernetes, provisioning the Redis and PostgreSQL (via recipes), injecting connection strings, setting up networking.

Key Concepts

Applications — the top-level unit. Everything lives inside an application boundary.

Containers — your workloads (maps to Kubernetes Deployments)

Resources — databases, caches, message queues (Redis, PostgreSQL, RabbitMQ, Azure Service Bus, etc.)

Connections — declare that container A uses resource B. Radius automatically injects the connection string and sets up the networking.

Environments — where your app runs (dev Kubernetes, staging EKS, production AKS). Each environment has recipes.

Recipes — the platform team's answer to "how do we provision Redis in our environment?" A recipe is a Terraform or Bicep template that gets invoked when a developer asks for a Redis cache. Different environments use different recipes.

// Platform team defines the recipe for Redis in production
// Developers just ask for a redisCache — they don't see this
resource redisRecipe 'Applications.Core/environments@2023-10-01-preview' = {
  name: 'production'
  properties: {
    recipes: {
      'Applications.Datastores/redisCaches': {
        'azure-redis': {
          templateKind: 'terraform'
          templatePath: 'https://ghcr.io/recipes/azure-redis:v1.0'
          // In production, this provisions Azure Cache for Redis
          // In dev, a different recipe deploys Redis as a K8s pod
        }
      }
    }
  }
}

This is the most interesting idea in Radius: the developer asks for "a Redis cache." The platform team decides whether that's an Azure managed service in production or a local pod in dev. The developer's application spec doesn't change between environments.

Installation and Setup

# Install Radius CLI
wget -q "https://raw.githubusercontent.com/radius-project/radius/main/deploy/install.sh" -O - | /bin/bash
 
# Initialize Radius on your Kubernetes cluster
rad install kubernetes
 
# Verify
rad env list

# Create an environment
rad env create dev --namespace default
 
# Deploy an application
rad deploy app.bicep \
  --parameters application=myapp \
  --environment dev

What I Liked

The connection model is genuinely clever. When you declare a connection between a container and a database, Radius automatically:

• Injects the connection string as an environment variable
• Creates the necessary Kubernetes networking
• Sets up service accounts and permissions

This eliminates the most error-prone part of Kubernetes deployments: getting networking and secrets right.

Recipes solve the dev/prod parity problem well. "Give me a Postgres database" means a local pod in dev and an RDS instance in production. Same application spec, different underlying infrastructure. This is cleaner than the Helm values approach most teams use.

The dashboard (rad graph) shows a visual map of your application — which containers connect to which resources. Useful for understanding what you've built and debugging connection issues.

# Visual dependency graph in terminal
rad app graph -a myapp

What I Didn't Like

Bicep is the native language — not YAML. Bicep is Microsoft's ARM template DSL. If your team doesn't know Bicep, there's a learning curve. YAML support exists via app.yaml but it's less feature-complete than Bicep.

Ecosystem maturity is early. The resource types available out of the box are limited — Redis, PostgreSQL, RabbitMQ, MongoDB, and Azure/AWS/GCP-specific services. If you need anything custom, you're writing your own recipe from scratch.

Control plane overhead. Radius installs its own control plane — several pods in the radius-system namespace. It's not a lightweight addition. On small clusters, this matters.

Tight Azure integration. Radius was built by Microsoft and optimized for Azure workloads. AWS and GCP work but have fewer built-in recipes and less documentation coverage.

CNCF Sandbox ≠ Production Ready. Sandbox status means "interesting enough to incubate." It doesn't mean "ready for your $10M production workload." The API stability is still evolving.

Honest Positioning: Where Does Radius Fit?

Radius sits in a crowded space:

Radius is most compelling if:

• You're heavily on Azure and want to abstract AKS/ACR/Azure services
• Your platform team wants to provide "self-service infrastructure" without Crossplane's complexity
• You like the connection model for wiring together services

It's less compelling if:

• You're AWS-first
• Your team has no Bicep knowledge
• You need production-grade stability today

My Assessment

Radius has one genuinely good idea — the connections model that automatically handles service-to-service networking and secret injection. That's real developer experience improvement.

The rest is ambitious but early. The dependency on Bicep limits adoption outside Microsoft shops. The recipe ecosystem is thin. The control plane adds operational overhead.

Worth watching in 2026: Radius joined CNCF Sandbox in 2024 and Microsoft is actively developing it. If the ecosystem grows and YAML support matures, it has a real shot at becoming a serious Platform Engineering building block in 2027-2028.

Not worth adopting today unless you're on Azure, have a team comfortable with Bicep, and are explicitly building a developer platform that needs the multi-cloud portability Radius promises.

If you need this abstraction today, Score + Crossplane + Backstage is a more mature combination — even if it requires more assembly.

See how Score compares: Score Workload Spec Review