In October 2023, the Microsoft Azure Incubations Team open-sourced Radius, a cloud-native application platform. (Not RADIUS, no one is shouting, and this isn’t about remote authorization.) The platform is designed to create better collaboration between Dev and Platform Engineering teams for deploying and managing cloud-native apps.

The announcement is timely, as we recently blogged that enterprises have recognized that developers shouldn’t be forced into becoming infrastructure experts as it causes cognitive overload.

In the official announcement on the project site, the project maintainers describe the platform as a response to the increased complexity of cloud-native applications and the struggle to manage them in the cloud. Radius is multi-cloud from the start, “allowing for applications that can be written once and, using the same toolset and workflows, deployed to any cloud or on-premises infrastructure.”

What’s interesting About Radius?

The idea is that devs only need concern themselves with the app requirements, while Ops can standardize deployments and ensure that cost, security, and all the operational requirements are met.

Radius isn’t intended to replace Kubernetes; it can run inside Kubernetes clusters (or as a standalone set of processes or containers) and uses rad, a CLI, which occupies a predominantly management function for apps, resources, and environments.

Licensed under Apache 2.0, the Radius platform provides ‘infrastructure recipes’ that Ops can use to define infra-as-code templates and automate resource provisioning. The recipes are community-made (although only a handful were available when we wrote this) for commonly used app dependencies, such as databases. In the recipe files, devs can add a ‘connections’ type in the ‘properties’ entry. Radius automatically injects all the required environment variables (defined by Ops) and connects the app to the dependency. The example the project uses in the Get Started docs is Redis.

An ongoing difficulty with deployed apps is accurately seeing the resources being used. Radius includes an ‘Application Graph’ to visualize all the connections, relationships, and dependencies an app has, and Ops can use the graph to deploy apps if they want to.

Although it’s designed to promote multi-cloud, it only currently supports Microsoft Azure and AWS, but with Google Cloud and “more cloud providers to come.”

The platform also has built-in support for various app development tools like Dapr, a run-time system also open-sourced by Microsoft, and the infrastructure as code (IaC) languages Terraform and Bicep, which it uses for the recipes. Again, Radius doesn’t replace CI/CD pipelines, like GitHub Actions, but is designed to fit into them and any current development tasks.

Radius: How Does It Work?

The architecture of the Radius Control Plane has three main parts: a general resource management API, resource providers for apps, and tools (such as rad CLI and Bicep) for deploying and managing apps using the API.

At its core is the Universal Control Plane (UCP) written in Go and part of the management API, which receives all inbound HTTP traffic to the API and either serves or routes the requests for resources. Each resource provider type is registered with the UCP, so it knows where to send requests, and it’s also capable of having separate resource managers for multi-cloud setups and routing requests to different cloud providers as required.

Learn More About Radius

The maintainers are in the process of submitting Radius to the CNCF. The project is in early release (it had only 626 stars on GitHub when we wrote this), and it’s not ready for production but is available for testing. Email us or add a comment if you think we should do a deep dive into Radius for a future blog.

GitHub: https://github.com/radius-project/radius
Official site: https://radapp.io/

Contact Us

Get expert advice on the right cloud-native technology for your specific use case—Book a call today!

CONNECT WITH US