{"id":97685,"date":"2025-06-30T08:00:00","date_gmt":"2025-06-30T15:00:00","guid":{"rendered":"https:\/\/opensource.microsoft.com\/blog\/?p=97685"},"modified":"2025-06-27T14:59:06","modified_gmt":"2025-06-27T21:59:06","slug":"expanding-platform-engineering-capabilities-with-radius-resource-types","status":"publish","type":"post","link":"https:\/\/opensource.microsoft.com\/blog\/2025\/06\/30\/expanding-platform-engineering-capabilities-with-radius-resource-types\/","title":{"rendered":"Expanding platform engineering capabilities with Radius Resource Types"},"content":{"rendered":"\n

The Azure Incubations team within the Azure Office of the CTO has contributed several projects to the Cloud-Native Computing Foundation (CNCF) including KEDA<\/a>, Dapr<\/a>, Copacetic<\/a>, Drasi<\/a>, and Radius<\/a>, the focus of this post. Radius enables platform engineers to build internal developer platforms that improve collaboration between enterprise application teams and platform engineering teams. It helps teams deliver cloud-agnostic applications using features like Recipes, Environments, and the Application Graph. If you are new to Radius, learn more on the Radius website<\/a> and try the Getting Started tutorial<\/a>.<\/p>\n\n\n\n

A couple of weeks ago we announced Radius Resource Types, a new feature directly guided by early adopter feedback that represents a major step forward for platform engineering. Radius already enables platform engineers to build internal developer platforms that are application-centric rather than infrastructure-centric. Now, with Radius Resource Types, platform engineers can define resource types specific to their organizations. Radius uses Recipes to implement these resource types. Radius Recipes can be new or existing Terraform configurations or Bicep templates. The great thing is that a single Radius Resource Type can have different Recipes depending on the Environment. Combining Radius Resource Types with Radius Recipes and Environments makes Radius a fully extensible and adaptable platform.<\/p>\n\n\n\n

\n
Define, deploy, and collaborate on cloud-native applications with Radius<\/a><\/div>\n<\/div>\n\n\n\n

Radius in the beginning<\/h1>\n\n\n\n

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.<\/p>\n\n\n

\"A<\/figure>\n\n\n\n

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.<\/p>\n\n\n

\"A<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

Introducing Radius Resource Types<\/h1>\n\n\n\n

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.<\/p>\n\n\n

\"A<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

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

Additional\u202fRadius resources<\/h2>\n\n\n\n