Microsoft-sponsored Radius project aims to mitigate “limitations of Kubernetes”

Microsoft-sponsored Radius project aims to mitigate “limitations of Kubernetes”

The Microsoft Azure Incubations Team has introduced an open source (Apache 2.0 license) platform called Radius, designed for deploying applications across on-premises, Azure or AWS, with more providers to follow.

The core of Radius is a thing called the Universal Control Platform (UCP) which according to the docs is new code, written in Go, “based on the design principles of the Azure Resource Manager (ARM) control-plane but generalized to work across multiple clouds and systems.” The Azure Resource Manager is a management service for Azure that can create, delete and update Azure services. Similarly, UCP publishes a REST API and routes requests to resource providers that can manage services. 

Radius is therefore an automation tool, but one that delegates the actual automation to other providers. “There are plenty of great CI/CD systems, application delivery pipelines, and Gitops systems out there and Radius can work with any of them,” the docs state. It is focused on Kubernetes, but could also be used with other deployment targets.

One of the ideas is to enable developers to specify what resources they need, but to allow operators to determine how those resources are provided. Radius “recipes” support Terraform or Bicep languages for describing resources and enable “a separation of concerns between infrastructure operators and developers by automating infrastructure deployment,” the docs explain.

Another idea is to promote multi-cloud, making the choice of cloud provider an implementation detail. That will not work when a service is cloud-specific, but could work for more generic resources. Microsoft, like Google Cloud Platform and others, has an incentive to promote multi-cloud because of the dominance of AWS.

Radius can also report on how applications are composed via a feature called the Application Graph, which is intended to “capture the relationship between resources in an application.”

According to the Radius docs a key reason for developing Radius is that organizations often build abstractions over Kubernetes to overcome its limitations, including that “Kubernetes has no formal definition of an application, it mingles infrastructure and application concepts and it is overwhelmingly complex.” 

The Radius team describes the project as “an early release of Radius … not yet ready for production workloads.” Further, “the maintainers are in the process of submitting Radius as a new project to the Cloud Native Computing Foundation (CNCF),” according to the introductory post.

This is a project in its early stages; for example the range of recipes currently available is thin. Adoption will depend on whether it is perceived as a solution to these real problems of excessive complexity in today’s cloud applications; or as yet another piece that has to be managed, potentially increasing rather than reducing complexity.