radius-demo-cheat-sheet

radius-demo-cheat-sheet.md

Setup and preparation

• Open up a Codespace from the demo repo
• Run the setup scripts to get your demo environments ready:

bash .devcontainer/on-create.sh
bash .devcontainer/post-create.sh

• Validate that your workspaces are set up:

rad workspace list

WORKSPACE   KIND        KUBECONTEXT      ENVIRONMENT
local-dev   kubernetes  k3d-k3s-default  default
prod-aws    kubernetes  prod-aws         prod-aws
prod-azure  kubernetes  prod-azure       prod-azure

Step 1: persona and scenario

Start at sharing the Dockerfile on screen

• In this demo scenario, I am an app developer
• I know how to use cloud services, but I'm not an infrastructure expert and thus don't have much knowledge in setting up cloud resources for security, networking, etc.
• My app has been developed, containerized, and tested to work locally - I now need to deploy it to cloud environments.
• The demo application is a simple Node-based TODO list app that leverages Redis as a database.
• This is what I'm showing you in this Docker file - all the source code for the application has been written and containerized, now I want to test it with real dependencies in a production-like environment: this is when Radius is most useful.
• Note that there isn't a SDK - we're not trying to change the way you write code, build containers, set up CI, etc.

Step 2: set up Radius

• We start with setting up Radius by running rad init:

rad init

• As a part of the Radius initialization, some default settings, Recipes, and a sample application are set up for you.
• In particular, local Recipes are set up for you to use as a starting point and allow you to create resources easily, for example a Redis cache with all settings preconfigured.
• Here's a list of the local Recipes available to you:

rad recipe list

• I also have both Azure and AWS environments configured by my operations teams for my use, each with their set of Recipes available:

rad recipe list -w prod-azure

rad recipe list -w prod-aws

Step 3: update the Bicep app definition

• In the root folder of my repository I have an app.bicep file that has some starter code for the application we'll work through - it's going to deploy a container to start.
• If you are not familiar with Bicep, it's a Domain Specific Language (or DSL) for deploying cloud resources, very comparable to Terraform.
• Looking at our app.bicep file, everywhere you see resource mentioned Radius knows to create a thing (e.g. a resource of type container).
• Let's now define and add a Redis cache datastore to our application:

resource db 'Applications.Datastores/redisCaches@2023-10-01-preview' = {
  name: 'db'
  properties: {
    application: application
    environment: environment
  }

Note that I didn't have to configure the Redis cache in terms of firewall rules, which cloud resources to use, etc. - all of that is handled by the Recipe I leverage to create the resource.

• I'll now declare a connection from the container to the datastore so that they may communicate with each other.
• This is a feature that's unique to Radius - we wanted this to feel like magic where you declare your intention to connect things, and Radius does the rest, specifically:
  • Injects settings into the app's environment variables
  • Sets up any managed identities automatically
  • Documents the connection in the application graph, which we'll see later
• In the app definition, we add a connections property to the container resource:

connections: {
      redis: {
        source: db.id
      }
    }

Note that we haven't mentioned anything about the platform we're deploying to or the cloud services we're using - the application is not coupled to those decisions, making it cloud agnostic and able to be deployed to multiple clouds.

Step 4: deploy and run the application

• Now I'm ready to test the application, so I'll deploy and run the application locally:

rad run app.bicep

This command deploys and runs the application, using the Recipe to create the Redis cache and then automatically creates the necessary port forwarding for us to access the application, you can see these in the output system logs.

• I can now access the application in my browser at http://localhost:3000 and see that it's working as expected.
• The application's frontend shows some information about the application, where you can see its resources, configurations, and even the environment variables that were injected into the container when I added the connection bwtween the container and Redis cache.
• The button at the bottom launches the TODO list app that we can test by adding an entry, which we can verify in the system log stream that the data was written to Redis.

Step 5: show the Radius Dashboard

• Now that we've seen the demo application deployed locally, let's take a look at this very curious log entry from when we ran the app, which looks like an additional port-forward to port 7007: [port-forward] connected from localhost:7007 -> ::7007.
• When we initialized Radius and ran the app, our Radius Dashboard was also started, so let's take a look at that. Navigate to the Dashboard in a browser
• The Radius Dashboard is the frontend experience for Radius and provides a graphical interface for visualizing your Application Graph, Environments, and Recipes:
  • Application graph visualization: A visualization of the application graph that shows how resources within an application are connected to each other and the underlying infrastructure.
  • Resource overview and details: Detailed information about resources within Radius, including applications, environments, and infrastructure.
  • Recipes directory: A listing of all the Radius Recipes available to the user for a given environment.
• So that's the Dashboard - it's built on the open-source Backstage platform which allows for accelerated UI development and also means you can extend it with plugins and customizations to suit your needs.

Step 6: deploy the application to the cloud

• My next step would be to take my app to a production-like environment in the cloud.

• Note that for this demo I don't show you any CI/CD mechanismsm since that's beyond our scope for now but I acknowledge that in a real world scenario we wouldn't manually execute all these steps in our terminal.

• In this scenario, my operations team has set up two environments for me to deploy to: one in Azure and one in AWS, each with their own set of applicable Recipes available for me to use, which I will show in a bit.

• I deploy the application to Azure by running:

rad deploy app.bicep -w prod-azure

• Similarly, I deploy the application to AWS as well:

rad deploy app.bicep -w prod-aws

• The deployment takes a bit to complete, but once it's done I can access the application in the cloud by navigating to the URL provided in the output logs, similar to how I accessed the application locally.
• Once deployed, I can also see the application graph that Radius has created for me, which shows the connections between the resources in my application:

rad app graph
rad app graph -w prod-azure
rad app graph -w prod-aws

• Remember that we deployed the app to Azure and AWS using the same app.bicep file, but you'll see that the datastore in Azure is an Azure Cache and in AWS it's a MemoryDB.
• Radius knows how to deploy cloud-specific resources leveraging the Recipes for each environment, which means that I, as a developer, didn't need to worry about it since everything was already preconfigured by my operations team.

Step 7: more details about Recipes

• The driving force behind all the convenience we've seen in deploying to cloud environments is Radius Recipes, so let's spend some time talking about them. Open and share the Recipes directory on screen
• The basic anatomy of a Recipe includes three main components:
  1. Get some data from Radius
  2. Create the thing or resource
  3. Return data back to Radius - this is how the behavior of Connections is configured
• Operators or platform engineers create the Recipe and developers use them but cannot change the settings (e.g. networking and security)
• You can also see that Terraform Recipes are supported, which means that you can leverage your existing Terraform code and modules with Radius as well.

Wrap up and Q&a

• That's it for the demo - I hope it helped you better understand Radius.
• Does anyone have more questions?
• Did the demo and Radius concepts resonate with you?

For reference: app.bicep file

import radius as radius

// Make sure application is specified.
@minLength(1)
param application string
param environment string

resource demo 'Applications.Core/containers@2023-10-01-preview' = {
  name: 'demo'
  properties: {
    application: application
    container: {
      image: 'ghcr.io/radius-project/samples/demo:latest'
      ports: {
        web: {
          containerPort: 3000
        }
      }
    }
    connections: {
      redis: {
        source: db.id
      }
    }
  }
}

resource db 'Applications.Datastores/redisCaches@2023-10-01-preview' = {
  name: 'db'
  properties: {
    application: application
    environment: environment
  }
}