Radius in the beginning

When we launched Radius, it was focused on bringing a cloud-neutral application model to cloud-native computing. Developers could define an application and its resources, including AWS, Azure, or Kubernetes types. The Radius Universal Control Plane understands these types and, in concert with Radius Environment configurations, deploys the application and its resources to the correct cloud provider and region.

Enterprises executing multi-cloud strategies highlighted to us the challenges they face building portable, cloud provider-agnostic applications. This motivated the team to build into Radius support for open-source, portable resource types as well as Dapr resource types, both of which allow developers to build applications which are completely portable across cloud providers when using Radius. Furthermore, Recipes and Environments enable platform teams to tailor these resource types for different requirements depending on the use case (a database could be configured differently for non-production versus production, for example). This achieves our original vision of Radius separating the application definition from the platform implementation.

While early adopters love using Recipes to deploy open-source and Dapr types, they also need the ability to add their own resource types. For example, their existing internal development platform (IDP) may support types required by their developers, but those were not supported by Radius. They need the ability to define their own types for Radius that are deployable via Recipes, just like the resource types built into Radius. In some cases, early adopters just needed to create a simple resource type, a PostgreSQL database for example, and let their developers specify a T-shirt size for the database their application requires. In other cases, they needed to create more complex, abstract types, such as a complete web service (including, for example, a reverse proxy, an application container, and an in-memory cache) encapsulated into a single resource type.

Introducing Radius Resource Types

To address this customer feedback, Radius Resource Types now extends Recipe support beyond just built-in resource types to any custom-defined resource type, enabling platform engineers to define their own resource types for their organization, each with a custom API for their developers.

The support for customized resource types completely decouples Radius from the definition of a resource type and the configuration of cloud resources. In other words, developers use the resource type interface, while platform engineers define the implementation. This decoupling gives platform engineers a powerful capability, and it improves the developer experience with application-centric resource types. It also allows platform engineers to change an implementation seamlessly, without impacting developers using the types.

If you are interested in learning more about Radius and Radius Resource Types, watch the video recording of my presentation and demo at the Radius June 2025 Monthly Community Call. You can also read the Introducing Radius Resource Types post on the Radius blog and try out the tutorial in the Radius documentation.

Additional Radius resources

• Join the monthly Radius Community Call to see demos and hear the latest updates (join the Radius Google Group to get email announcements).
• Join the discussion or ask for help on the Radius Discord server.
• Subscribe to the Radius YouTube channel for more demos.
• Review the Radius documentation and Getting Started guide.
• Read the Radius Blog.
• Check out Radius code here.

Azure Incubations Team mission

The Azure Incubations Team mission is to work across the open-source community to explore and deliver technology that provides value to the industry at large: not just Microsoft customers and not just Azure customers. We focus on investments that help accelerate the industry’s collective journey to the cloud, with projects like KEDA, Dapr, Copacetic, Drasi, and Radius. Because these projects address the needs of the industry at large, our primary ship vehicle is open-source software. As such, all Incubations Team projects have been donated to the Cloud-Native Computing Foundation (CNCF) which provides a highly respected open governance model. So, while these projects were all initiated within the Azure Incubations team at Microsoft, the IP for all of them is owned by the CNCF, is managed via their open governance processes and the code for all is freely available on Github via the Apache 2.0 license. Please follow the links above to learn more about and contribute to any of these projects.