- Intro
- Talking points: customer conversations
- Talking points: pain for developers because of manual processes and troubleshooting connectivity
- Tell them what you're going to tell them.
- Show
rad init- Talking points: it's easy to setup my local development environment.
- Introduce app
- Talking points: easy to use an existing application, no SDK or major changes, works with your existing containerized code
- Todo application that I need to add Redis to. This might normally require a ticket, instead I'm going to use recipes.
- Open Bicep file:
- Talking point: Why are we defining an abstraction? To simplify and tailor for developers. Focus on code and requirements instead of infrastructure.
- Talking point: IaC feels good for the kinds of things we need to do to manage and upgrade apps
- Talking point: We stared with Bicep because it's really rich and powerful. There are other ways to use Radius, and we'll see more later.
- Code the app definition:
- Deploy and test (local dev):
- Deploy (cloud):
- Show application graph (cloud):
- Show helm chart and compare:
- Show eShop diagram:
- Show eShop Bicep:
Hi everyone, my name is Ryan Nowak. I’m a developer on the Azure Open-Source Incubations team at Microsoft, and I’m the creator of Radius.
As part of building Radius, we talked to over 70 customers about the challenges their developers face managing applications. Our conversations highlighted the complexity application developers face working with Kubernetes and cloud resources.
What we heard is that it’s a pain for developers to get access to the cloud resources like databases. It’s doubly a pain to wire those up and troubleshoot access problems. That would normally require a lengthy back-and-forth with someone like Ryan. This is why we created Recipes for on-demand provisioning that follows the organizations policy controls.
I’m going to show you how I can use Radius to deploy an existing application to a local-dev environment on my workstation, and then deploy to the cloud using the recipes and environments that Aaron configured for me. This is an example of how Radius can help platform engineers and developers collaborate to use the cloud in a way that enforces organizational standards.
I've working in side of a Codespace with a local Kubernetes cluster running. I'm going to use rad init to set up an environment for development.
Run rad init
0:11->0:25
You can see here in the output that Radius included recipe for local-dev. Radius includes these recipes to get up and running with the dependencies of your application in development scenarios. Let me tell you about the app.
open Dockerfile
*0:33->0:40
This is the Dockerfile for a TODO application that I’ve already created and containerized. We’re starting with an application that I’ve already built and containerized, because Radius works with your existing code and containers.
open app.bicep
0:53->1:01
This file was scaffolded by Radius when I ran rad init. We're using the Bicep infrastructure-as-code lanugage which is being developed as an open-source project at Microsoft. Describing my cloud-native application with Bicep is one of a few ways to use Radius. We like infrastructure-as-code for managing applications because the way it behaves is ideal for deploying, upgrading, and managing things. All of the functionality in Radius is backed by an API, so it's easy to build other experiences.
We've extended the set of types in Bicep to include cloud-native primitives at a developer's level of altitude. Many customers we spoke with have tried to build their own abstraction layers to firewall-off developers from infrastructure like Kubernetes. These projects are hard to get right, and the customers we talk to aren't experts in building dev-tools. We're building Radius in the open with the goal of creating a universal cloud-native abstraction for everyone. Right now that just means Kubernetes, but if it's a success then we'll take to other places as well.
So Radius gave me a starting point, my job is to customize this file and describe my requirements and dependencies.
My application needs a database, and specifically a Redis Cache. I think for many of us we’d need to file a ticket, or ask someone else to do this. Instead I’m going to use a Recipe and have Radius create the Redis cache.
paste recipe
1:10->1:18
When I deploy this, Radius will use the Recipe that’s been configured in the environment to create the Redis Cache. In my local-dev environment it will use the local-dev Recipe provided by Radius to host Redis inside my cluster. In my cloud environment it will use the Recipes that Aaron created for me to provision the correct cloud resource.
I’ve got my container and my Recipe for Redis, but I need to say something about how they’re connected.
paste connection
1:18->1:27
By adding this I've declared a connection between my container and the Redis Cache. Radius will use this connection to configure the settings I need to talk to Redis. We want this to feel like magic to developers. You should be able to say what you need and have Radius provide it for you.
Since Radius knows about the connection, it will also catalog the infrastructure and the communication between these components. This builds the Application Graph that helps everyone understand the architecture and relationships of the application.
Let’s try this out in my local-dev environment.
rad run + open applcation
1:31->2:19
AARON CAN YOU CUT THE PART AFTER THE ZOOM OUT WHEN I"M CLICKING AROUND AT 1:41->1:52
So the application is deploying now. Radius is going to execute the recipe to start up Redis, then it's going to deploy my container and make sure everything starts correctly. Lastly it's going to give me streaming logs and a port-forward so I can try it out.
Through the magic of codespaces, I can open the webapp even though it's in a Kubernetes cluster inside a codespace.
video continues until 2:19
explain connections
2:20->2:31
You can see the settings that were injected by Radius here. On this page we can test out the TODO functionality.
test it out
2:31->2:56
Now that I've done that, let me show you the application graph in text form using the rad CLI.
rad app graph
2:58->3:30
You can see my container and my Redis cache here, as well as the connection between them. Radius also catalogs the infrastructure associated with each component. In this case you’re seeing Kubernetes primitives because that’s what the Recipe in my local-dev environment created.
Aaron set up environments for me in both AWS and Azure. Since I'm relying on the recipes configured in those environments I don't need to make any changes to the application. He's good at his job so I know the resources are going to be created in the correct way.
run rad deploy side by side
3:42->4:02
Let me fast-forward to when that is done. And to prove that it worked, I’ll show you the application graph output for each cloud.
run rad app graph side by side
4:05-4:25
You can see that I’m using the hosted Redis services in each of these clouds.
So to sum this up, we showed you how I could onboard an existing application to use Bicep and Radius' cloud native application. I can get up and going easily in a local-dev environment on my workstation. When I go to the cloud I can use the environments and recipes that are prepared for me by operations experts, and I didn’t have to change my application code to move from testing to the cloud.
On another topic.
When we talk to customers about deployment, we heard repeatedly that it's hard to migrate existing applications. We also found plenty of people that have already adopted and want to keep using Kubernetes-native tools like Helm and Flux.
So we added the ability to use Radius directly from Kubernetes without our abstraction layer.
show Helm and Bicep side-by-side
4:54->5:20
This is the same application, but it's a Helm chart instead.
This Recipe CRD let's me use the Kubernetes API to do anything Radius recipes can do.
Up here I declare annotations that enable Radius for the deployment and declare my connection.
So everything I showed you so far is a using a pretty simple application. But we wanted to make sure Radius works for more complex architectures. To prove that out we took the eShop sample and radified it.
show eShop docs page and diagram
5:28->5:39
As you can see from the diagram this is a complex microservices application with several different architectural paradigms.
The deployment scripts for eshop includes thousands on lines of shell scripts and helm charts. You don't see the application in all of that noise. With the environments and Recipes Aaron setup for me before, I can easily deploy SQL, Redis, and RabbitMQ without needing to specify any of the infrastructure. When we move this into Radius we can replace all of the infrastructure management with Recipes. As the developer it's not my job anymore, so that's about half the code gone.
One of the things I like about Bicep is that it's great for managing complexity. When we move this into Bicep we can use features like modules to organize and simplify the code.
Here's a demo of deploying the application.
run demo
6:22->end
Just run rad deploy and Radius handles the deployment and configuration. we're just getting started and we can't wait to see what you build,