Radius Resource Types and Recipes for Github-Radius integration #11863
Radius Resource Types and Recipes for Github-Radius integration #11863Reshrahim wants to merge 5 commits into
Conversation
Signed-off-by: Reshma Abdul Rahim <reshmarahim.abdul@microsoft.com>
Signed-off-by: Reshma Abdul Rahim <reshmarahim.abdul@microsoft.com>
Signed-off-by: Reshma Abdul Rahim <reshmarahim.abdul@microsoft.com>
Radius functional test overviewClick here to see the test run details
Test Status⌛ Building Radius and pushing container images for functional tests... |
There was a problem hiding this comment.
Pull request overview
Adds an extensibility design note describing a strategy for GitHub–Radius integration, focusing on a deterministic catalog of application-oriented resource types and a recipe model that directly references community IaC modules (Bicep/Terraform/Helm), plus an adoption-ranked catalog appendix to guide prioritization.
Changes:
- Introduces a top-level design note for resource type + recipe strategy, contribution lifecycle, and validation approach for AI-driven
app.bicepgeneration. - Adds an adoption-ranked catalog of candidate application components with tiers and supporting metrics/methodology notes.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| eng/design-notes/extensibility/2026-05-radius-resource-types-recipes.md | Main design note describing the proposed resource type catalog, direct-module recipe approach, and contribution/validation model. |
| eng/design-notes/extensibility/2026-05-radius-resource-types-recipes/resource-type-ranked-catalog.md | Ranked catalog appendix used to justify prioritization of resource types based on adoption signals. |
| Radius maintains the resource type schemas and recipes in the `resource-type-contrib` repository. We need about 30 application oriented resource types covering the basics: databases, caches, messaging, storage, and so on. These are what AI agents use to generate `app.bicep`, so the schemas need to be well-defined. We use Agents and skills to generate schemas and validate them against community Bicep and Terraform modules. | ||
|
|
||
| Recipes reference community modules directly rather than custom IaC code. The `resource-type-contrib` repository contains type definitions and tested module references. For Azure, recipes point at Azure Verified Modules. For AWS, the Terraform Registry. For Kubernetes, Helm charts. Radius resolves inputs and outputs automatically, with the mapping configuration maintained in Recipe packs. |
| } | ||
| ``` | ||
|
|
||
| For the full technical specification, including user stories, acceptance scenarios, parameter precedence rules, and implementation details, see the [Direct Module Support Spec](https://github.com/Reshrahim/radius/blob/001-direct-module-support/specs/001-direct-module-support/spec.md). |
|
|
||
| ## Appendix C: Methodology | ||
|
|
||
| This catalog was produced using the Discover → Measure → Rank methodology documented in detail in [`resource-type-discovery-methodology.md`](resource-type-discovery-methodology.md). In brief: |
| 1. Build a resource type catalog broad enough for AI agents to generate accurate `app.bicep` for real-world applications. | ||
| 2. Eliminate recipe authoring by pointing directly at community modules, so Radius never owns or ships IaC code. | ||
| 3. Establish a contribution model that lets the community add and validate resource types with clear maturity gates from Alpha to Stable. | ||
| 4. Extend recipe driver coverage to match where developers deploy: Bicep for Azure, Terraform for AWS, Helm for Kubernetes. |
There was a problem hiding this comment.
Do we have any data on IaC usage for AWS? I'm curious if Terraform or CloudFormation is the right way to go. I suspect the key driver here is if there is an authoritative library of CloudFormation templates which Radius can link to.
|
|
||
| | Tier | What's included | Criteria | | ||
| |------|----------------|----------| | ||
| | **Build First** | PostgreSQL, Redis, Object Storage, LLM Inference API, MongoDB, MySQL, Kafka, Elasticsearch/OpenSearch, RabbitMQ, SQL Server | Highest adoption + stable connection contracts suitable for cross-cloud abstraction | |
There was a problem hiding this comment.
Can you clarify what LLM Inference API is exactly? Is this the OpenAI API? Is that a standardized LLM API? 'LLM Inference API' sounds generic and non-specific.
| | Tier | What's included | Criteria | | ||
| |------|----------------|----------| | ||
| | **Build First** | PostgreSQL, Redis, Object Storage, LLM Inference API, MongoDB, MySQL, Kafka, Elasticsearch/OpenSearch, RabbitMQ, SQL Server | Highest adoption + stable connection contracts suitable for cross-cloud abstraction | | ||
| | **Build Next** | Serverless Functions, Message Queue, MQTT, pgvector, NATS, Oracle, Neo4j, Vault, Cassandra, InfluxDB | Strong adoption but higher abstraction complexity or narrower use cases | |
There was a problem hiding this comment.
Please clarify what is a message queue? You already have Kafka and RabbitMQ in the tier 1 bucket.
|
|
||
| Notable inclusions: LLM Inference API reflects AI becoming a first-class application dependency (81.4% of surveyed developers use OpenAI GPT models). pgvector (#14) is the recommended vector-database entry point with the same PostgreSQL connection contract and 3/3 cloud availability. Vault (#18) is included because applications directly establish runtime connections to secrets providers, unlike org-level identity or observability platforms. | ||
|
|
||
| Shared infrastructure services (identity/auth, observability, logging, email, feature flags) are provisioned at the platform level, but applications still connect to them at runtime. These may warrant a lightweight **shared resource type** with no recipe, just connection metadata at the environment level. |
There was a problem hiding this comment.
Please clarify. If these are platform level resources, what would the resource type be and do?
| Generated schemas must: | ||
|
|
||
| - Expose stable application-facing contracts | ||
| - Follow naming and validation conventions |
There was a problem hiding this comment.
What does this mean exactly?
|
|
||
| ### Schema generation | ||
|
|
||
| Rather than manually authoring every schema, Radius uses a `resource-type-creator` agent to analyze infrastructure modules, application usage patterns, and existing deployment conventions. |
There was a problem hiding this comment.
This is the first mention of a resource-type-creator agent. Is this just a suggestion for how to one time generate these resource types? Or are you saying some bigger and recurring? Either ways, it's unclear what the relevance of how the schema is generated is.
|
|
||
| ### Recipe module reference generation | ||
|
|
||
| Once direct module support is implemented, we create a `recipe-module-generator` agent that tests the type with community modules and builds the recipe pack by platform. |
There was a problem hiding this comment.
Same question as the previous agent reference. Are you just hinting at we would generate the recipe pack? Building a recipe pack seems trivial and one time. Or are you saying something bigger?
|
|
||
| CNCF 2025 confirms Kubernetes at 82% production adoption among container users, with Helm at 81-87% adoption among Kubernetes organizations. That Helm number is what makes it the highest-leverage next driver for Radius: it maps directly to how the Kubernetes ecosystem already packages and distributes software, and unlocks existing charts instead of requiring custom Bicep modules per backing service. | ||
|
|
||
| ## 3. Testing and Validation |
There was a problem hiding this comment.
I do not understand what we are testing. Is there anything new to our testing strategy being proposed here? We have existing resource types and recipes--what is different after this proposal?
| Radius maintains the resource type schemas and recipes in the `resource-type-contrib` repository. | ||
| We need about 30 application oriented resource types covering the basics: databases, caches, messaging, storage, and so on. These are what AI agents use to generate `app.bicep`, so the schemas need to be well-defined. We use to generate schemas and validate them against community Bicep and Terraform modules. | ||
|
|
||
| We don't write recipes. The `resource-type-contrib` repository has type definitions only, no recipe code. Recipes point at community modules directly: Azure Verified Modules for Azure, Terraform Registry for AWS, Helm charts for Kubernetes. Radius handles the input and output mapping automatically with configuration maintained in Recipe packs. |
There was a problem hiding this comment.
I do not think 100% no recipe code is possible. Look at the containerImage recipe as a counter point. #11734
| 2. Documentation and Module references (which AVM/TF/Helm modules to use) | ||
| 3. Tests that validate the type deploys correctly with those modules | ||
|
|
||
| ### Maturity Stages |
There was a problem hiding this comment.
Is this different from what is in place today? Seems the same.
This pull request introduces a comprehensive design note outlining the strategy for integrating Radius resource types and recipes to support deterministic, reliable AI-driven deployment definition generation. The document proposes a catalog of well-defined resource types, a model for leveraging community infrastructure modules as recipes without maintaining IaC code, and a contribution and validation framework to ensure quality and extensibility.
Resource Types and Catalog Expansion
resource-type-creatoragent to ensure stable, provider-agnostic contracts.Recipe Management and Direct Module Support
Validation, Testing, and Contribution Lifecycle
Please explain the changes you've made.
Type of change
Fixes: #issue_number
Contributor checklist
Please verify that the PR meets the following requirements, where applicable:
eng/design-notes/in this repository, if new APIs are being introduced.