Radius in a nutshell
- Radius decouples the application from the infrastructure, enabling the developers to focus on the application’s components and their relationships, taking away the infrastructure complexity. The goal is to simplify application development by abstracting infrastructure complexity.
- Developers describe their applications in a Bicep file, including containers, databases, and their connections.
- Kubernetes is the hosting platform for the Radius control plane and for the applications modeled and managed by Radius.
- Applications are bound to an environment (e.g. Kubernetes ) and to a specific infrastructure recipe (e.g. LocalDev, Azure, Aws).
- Operators define the infrastructure recipes. Recipes can be seen either as a helm chart or a bicep/terraform module.
Create a new environment
To get started with Radius, you first need to install the RAD cli (instructions here) and have a Kubernetes cluster (K3S, K3D, Kind, AKS) where you can deploy the Radius control plane.
Run the “rad init” command to:
- Create a new environment. Radius Environments are prepared to target configurations. An environment specifies the container runtime, configuration (for example the list of allowed recipes), and other settings like identity provider. By default, the new environment is named default and creates a ‘default’ namespace on the connected Kubernetes cluster.
- Create a new workspace. Workspaces are meant to facilitate the platform operations by allowing you to manage multiple Radius environments using a configuration file.
- Install the Radius control plane to the Kubernetes cluster in the radius-system namespace. The following pods are created in the radius-system namespace.
- Associate the local-dev recipes to the “default” environment (rad env show default -o json).
If you want to have better control over your configuration, you can either run the “rad init –full” or run a sequence of single commands like “rad install, rad env create, etc.”
For this exercise, I used the “rad init” command, but when I was asked whether to create a new application, I selected ‘No’ to have better control of the application creation. The different objects managed by Radius can be found in the universal control plane CRD: “resources.ucp.dev”.
Create a Radius app
A Radius application is a way to model your cloud-native application. A Radius app can contain multiple containers (for example a backend and a frontend), a datastore (f.e SQL), a gateway (how to expose the application to the external world), and how those resources are connected to each other.
- Create an empty Radius application by executing the following command: “rad deploy empty.bicep –environment default“. As a result of the deployment, a new namespace has been created (“default-empty”) and there is an empty resource in the UCP. Note: by default, Radius concatenates the application name to the namespace associated with the environment. You can change this behavior by adding the ‘kubernetesNamespace’ key to the extensions property of your Radius application.
- Let’s now add a single container to our app (see example) and execute the following command “rad run podinfo.bicep –application podinfo-app –environment default“. Note that instead of using the “rad deploy” command, at this step we are using “rad run”. This is the easiest way to deploy and perform a first test of your Radius application because the run command will trigger the app deployment, enable the port forwarding, and stream all the logs to your development console.
- As a final step to making our application available to the outside world, let’s add a gateway resource. Run the “rad deploy s2s.bicep –environment default” command to deploy this third example. Under the hood, Radius uses Contour and Envoy to expose the application using a load balancer service. To provide a better developer experience, Radius leverages nip.io to give an FQDN to your application. For more professional environments it is advised to set up your own domain name and add the TLS termination to the gateway.
Recipes
One distinctive feature of Radius is its ability to fully describe an application, including resources like message queues and state stores. When a developer adds a database to the application, they don’t need to specify how or where to run the underlying infrastructure. The Radius Environment and its Recipes take care of that for you. In the same way the Radius Environment bounds your container to a Kubernetes cluster, it also deploys and binds your database to underlying infrastructure using Recipes.
Developers define what they need (Mongo, Redis), and operators define how it will be deployed (Azure/AWS) by creating pre-configured environments.
For example, you might have a setup like the following:
- An APP deployed on LOCALDEV environment will use the REDIS recipe assigned to localdev to configure the Redis image on K3D or on AKS (depending on the connected context).
- An APP deployed on AZUREDEV environment will use the REDIS recipe assigned to azuredev to configure the Cloud-managed Redis on Azure.
You can find some recipe examples on this repo: https://github.com/radius-project/recipes/tree/main. You can see recipes as an alternative to helm charts or a wrapper on top of AVM modules and terraform modules.
How was my first experience with Radius?
Pros
➕ You can quickly deploy an application to Kubernetes without any YAML and Kubernetes networking knowledge.
➕ You can deploy your application and the Azure infrastructure using a single language (bicep).
➕Radius looks very promising and I am looking forward to seeing all the new features, resources, and recipes that will be added in the coming months. It’s also interesting to see whether there will be an integration with Azure Container Apps to make an application extremely portable in the Azure context.
Doubts
🤔Recipes sound like an alternative to helm chart, but without the maturity of helm.
🤔Bicep is the modeling language used by Radius. Will Bicep get any traction outside the Azure community?
🤔Radius is in principle cloud neutral, but on the other hand, the universal control plane (UCP) is based on the Azure Resource Manager deployment engine which is a Microsoft proprietary service. Microsoft plans to open-source this resource manager in 2024.
🤔The abstraction, which is a benefit for developers, might be a blocker for cluster operators that will have to deal with concepts split on different resources. How will radius fit in with the GitOps movement?
Conclusion
In conclusion, Radius is a very interesting open-source application platform that aims to be an infrastructure pain-killer for developers by separating the application modeling from the infrastructure implementation. Radius leverages Kubernetes and offers the flexibility to deploy applications on various environments, making it a promising tool for cloud-native development.
Subscribe to our RSS feed