Exploring Microsoft Radius Application Platform
Microsoft recently launched Radius, a cloud native application deployment platform. While there are many platform choices for developers that abstract Kubernetes, Radius takes a different approach by unifying the deployment model not just for Kubernetes but also cloud platforms such as Azure, Amazon Web Services, and Google Cloud Platform.
What Is Radius?
Radius is an open source application platform that abstracts the deployment runtime to enable developers and operators to target diverse runtime environments, including Kubernetes, cloud, and edge infrastructure.
Operators define and publish a set of services called Recipes that developers can consume in their applications. When you deploy Radius, you get an initial set of containerized local-dev Recipes pre-registered in your environment. These Recipes are based on lightweight containers to enable developers to get started immediately. Moving an application to production is as simple as changing the Recipe based on a managed service in the cloud.
Applications consume Recipes similar to how a program consumes an external library or a module. An application is a collection of container images and Recipes that are deployed as one unit.
Both Recipes and applications are declared in either Bicep or Terraform. This approach brings a clear separation of concerns between infrastructure operators and developers by automating infrastructure deployment. Developers select the resource they want in their application (MongoDB, Redis Cache, Dapr State Store, etc.), and infrastructure operators define in their environment how these resources should be deployed and configured (local containers, Azure resources, AWS resources, etc.).
While the dependencies may be based on cloud services, the application is always running on a Kubernetes cluster as a set of microservices packaged as containers.
Getting Started with Radius
Let’s look at Radius and the workflow involved in deploying containerized workloads.
Radius runs on Kubernetes and exposes an API to manage the lifecycle of applications and their dependencies.
With the kubeconfig file in place, install and initialize Radius. This process also scaffolds the template for an application, which we will modify to run a simple NGINX container image.
Running the rad init command deploys a set of resources in Kubernetes and creates a couple of files in the current directory. Let’s first explore what happens to the Kubernetes cluster.
First, there is a new namespace that contains the resources required by the Radius control plane.
It also creates a set of CRDs responsible for managing the Recipes and applications.
We will revisit this when we discuss the architecture of Radius. Let’s deploy our first application through Radius.
In the same directory where you ran the initialization, open the file app.bicep and change the image to the standard NGINX image and the port to 80.
Let’s run the application and access it by forwarding the port of the application.
Since we ran the application from a directory named simple, it assumes the same name. You can verify this by accessing the file rad.yaml stored under the .rad directory.
rad resource expose --application simple containers demo --port 8080 --remote-port 80
Feel free to explore the Kubernetes resources created by Radius related to the application available within the default-simple namespace.
Consuming a Recipe in an App
Let’s now deploy the popular Azure Vote sample application through Radius. This application has one container with a frontend web interface that talks to the Redis cache to store the state.
Create a directory calledvote and scaffold the app with rad init.
Instead of adding Redis as yet another container, we will use the built-in Radius Recipe from the local-dev environment. It’s available as ghcr.io/radius-project/recipes/local-dev/rediscaches:0.26
Modify the file app.bicep to add the Redis Recipe to it.
resource redis 'Applications.Datastores/redisCaches@2023-10-01-preview' = {
name: 'redis'
properties: {
environment: environment
application: application
}
}
Let’s replace the default app definition with the frontend container of the Azure Vote sample.
resource frontend 'Applications.Core/containers@2023-10-01-preview' = {
name: 'frontend'
properties: {
application: application
environment: environment
container: {
image: 'mcr.microsoft.com/azuredocs/azure-vote-front:v1'
env: {
REDIS: redis.properties.host
}
ports: {
web: {
containerPort: 80
}
}
}
connections: {
redis: {
source: redis.id
}
}
}
}
Notice how the Redis Recipe is bound to the frontend web container in the connections section. This enables the Recipe to inject the properties as environment variables into the application. The host property of the Recipe is mapped to the REDIS environment variable of the web app.
Here is the complete Bicep definition of the Azure Vote application:
import radius as radius
param environment string
param application string
resource frontend 'Applications.Core/containers@2023-10-01-preview' = {
name: 'frontend'
properties: {
application: application
environment: environment
container: {
image: 'mcr.microsoft.com/azuredocs/azure-vote-front:v1'
env: {
REDIS: redis.properties.host
}
ports: {
web: {
containerPort: 80
}
}
}
connections: {
redis: {
source: redis.id
}
}
}
}
resource redis 'Applications.Datastores/redisCaches@2023-10-01-preview' = {
name: 'redis'
properties: {
environment: environment
application: application
}
}
Let’s run the application and access it through port forwarding.
rad run app.bicep rad resource expose --application vote containers frontend --port 8080 --remote-port 80
We have deployed an application through Radius that has a container and a Recipe. It is possible to replace the Redis Recipe to point to Azure Cache for Redis or Amazon ElastiCache for Redis without any change to the application.
In the next part, we will take a closer look at the architecture of Radius. Stay tuned.
