Radius Resource Types and Recipes for Github-Radius integration #11863
Radius Resource Types and Recipes for Github-Radius integration #11863Reshrahim wants to merge 10 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. |
|
|
||
| ## 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.
There was a problem hiding this comment.
I scanned through the Tf registry for AWS https://registry.terraform.io/namespaces/terraform-aws-modules and the weekly downloads are in millions. I couldn't find a authentic source for CloudFormation usage.
| | 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?
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>
Signed-off-by: Reshma Abdul Rahim <reshmarahim.abdul@microsoft.com>
|
|
||
| ## Goals | ||
|
|
||
| 1. Build a resource type catalog broad enough for AI agents to generate accurate `app.bicep` for real-world applications. |
There was a problem hiding this comment.
can we think of this as training the agents? i.e. when they come across a type or a user wants to define a type that does not directly map to a known resource the agent can create the type and recipe files successfully?
There was a problem hiding this comment.
This is about building the catalog (tested and validated) for the most basic services so that there is maximum determinism and less errors during application definition process for 60-80% of the cases.
After the basic catalog is in place which we can certainly think about training the agents to do more like generating types and recipes on the fly.
| |------------------|----------|----------------|----------| | ||
| | Azure | Bicep | [Azure Verified Modules (AVM)](https://aka.ms/avm) | `mcr.microsoft.com/bicep/avm/` | | ||
| | AWS | Terraform | [terraform-aws-modules](https://registry.terraform.io/namespaces/terraform-aws-modules) | `registry.terraform.io/terraform-aws-modules/` | | ||
| | Kubernetes | Helm | [Bitnami Charts](https://github.com/bitnami/charts) | `oci://registry-1.docker.io/bitnamicharts/` | |
There was a problem hiding this comment.
This might not be a best spource for Helm. Need to do an analysis here
| **Recipe Validation** catches upstream module breakage before it impacts deployments: | ||
|
|
||
| - Weekly CI runs that deploy each referenced module and verify outputs map correctly | ||
| - Version-pinned references with automated PRs when new module versions are available |
There was a problem hiding this comment.
can dependabot manage this?
|
|
||
| Radius maintains the resource type schemas and recipes in the `resource-types-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. | ||
|
|
||
| Recipes reference community modules directly rather than custom IaC code. The `resource-types-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. |
There was a problem hiding this comment.
do we actually point at Helm Charts for Kubernetes? I think all of the ones we have are direct Terraform/Bicep k8s provider
|
|
||
| Recipes reference community modules directly rather than custom IaC code. The `resource-types-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. | ||
|
|
||
| In most cases, there is no IaC code to maintain — just a module reference and mapping configuration. In rare cases where no suitable community module exists or where Radius-specific orchestration is needed (e.g., the container recipe that manages Kubernetes deployments directly), a custom recipe module is still required. This document lays out the strategy to build and maintain the types and recipes for the GitHub-Radius integration to be successful. |
There was a problem hiding this comment.
I would frame this as an assumption, not a fact. We don't really know yet
|
|
||
| Resource types are the building blocks of the application definition. Today's catalog is limited to a handful of types that serve only the Radius `todo-list` sample. To support real-world applications, the catalog needs to grow to cover the application dependencies developers actually use. | ||
|
|
||
| A data-driven analysis by Copilot from cloud provider catalogs, Docker Hub, the Stack Overflow 2025 Developer Survey, IaC registries, and package registry trends identified 27 application components ranked by actual developer adoption. Adoption is measured by dedicated client-library downloads across four ecosystems (npm, PyPI, NuGet, RubyGems), weighted by survey usage, Docker pulls, and cloud availability. The full ranked catalog with methodology is in [`resource-type-ranked-catalog`](2026-05-radius-resource-types-recipes/resource-type-ranked-catalog.md). |
There was a problem hiding this comment.
very cool that we got a data-driven approach
| ### Resource type and Recipe correctness | ||
|
|
||
| - **Dependency resolution rate**: 80%+ of detected app dependencies should map to a defined resource type, measured across common application patterns (web apps, microservices, data pipelines). | ||
| - **Schema accuracy**: Generated `app.bicep` files should require zero manual edits for connection properties (host, port, credentials) when deploying against any supported platform. |
There was a problem hiding this comment.
yes we need a way to measure the effectiveness of skills across apps
| ### Resource type and Recipe correctness | ||
|
|
||
| - **Dependency resolution rate**: 80%+ of detected app dependencies should map to a defined resource type, measured across common application patterns (web apps, microservices, data pipelines). | ||
| - **Schema accuracy**: Generated `app.bicep` files should require zero manual edits for connection properties (host, port, credentials) when deploying against any supported platform. |
There was a problem hiding this comment.
could we write fuzzy AI tests to simulate bicep creation and verify that its output looks right?
There was a problem hiding this comment.
yes we need a evaluation framework to know how good our skill or agent is
| ## Appendix: Testing, Validation, and Contribution Model | ||
|
|
||
| This will be covered in another doc with the technical details of the testing framework and contribution process, but here are the high-level principles. | ||
|
|
There was a problem hiding this comment.
If we care about the app.bicep generating reliable/consistent output, we should test that somehow too
| **Alpha** | ||
|
|
||
| - Schema passes validation (required properties, type checks, output contract) | ||
| - At least one working recipe module reference on any single platform |
| - Recipe module references for all three platforms (AWS, Azure, Kubernetes) | ||
| - README with usage examples across all platforms | ||
| - Recipe packs tested across all supported platforms | ||
| - Backward-compatible schema changes only |
There was a problem hiding this comment.
how will this be verified?
Signed-off-by: Reshma Abdul Rahim <reshmarahim.abdul@microsoft.com>
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.