 Hi everyone and welcome, thank you all for joining us today for this live stream event. My name is Rebecca and I'm the event planner of the Microsoft Reactor New York. We recommend at this time to check in to receive some session resources. I actually have a few extra links I'm going to be adding in there now. So if you happen to check in, just refresh your page in just a few minutes and you'll see some of those other links coming through. Go to aka.ms slash reactor check in and enter event ID 14995 for those resources. Our code of conduct, I'll quickly just go through it. Microsoft Reactor seeks to provide a respectful environment for both our audience and our presenters. We encourage engagement in the chat, but just be mindful of your commentary or remain professional on topic. If you are joining us through YouTube live stream, just be aware that to interact in the chat, you do need to have an account created there on YouTube. So if you want to set that up now, you can. Otherwise, if you don't have an account and you just want to stream and you have questions later, feel free to reach out to the reactor and we'll try to get those questions answered for you. Event guidelines, pretty straightforward. The event's recorded. You will not be appearing in that recording. This will be available later on Microsoft Reactor YouTube for on-demand access. So if you can't stay the entire time or if you want to reference some things and circle back, it will be available there. I'll share the link to the YouTube channel momentarily. If you have questions, as I mentioned on the previous slide, feel free to drop those into the chat. Give comments. Let us know where you're coming from. Let us know what you're hoping to learn from today, your experience level, anything. Just hang out, have fun. And then today. So today's session, the reactor is joined by Jay Gordon, a cloud advocate here at Microsoft, and Maddie Stratton, a developer advocate for Pulumi. I'll bring you guys up to the screen here. So today, Jay and Maddie will be going through deploying a serverless container using Azure Container Apps. And Shona's kind of how to do that. The session will go for about 60 minutes, give or take. And yeah, it's time for questions throughout. So hello, hello, welcome. Thank you, Maddie, for joining us. Jay, thanks for coming back again for another round. No problem. I will let you all, you know, introduce yourselves more thoroughly. Mine was just super brief. Sure. Take it from here. Absolutely. So hey, thanks everybody for joining us today. My name is Jay Gordon, and I am joined here by a friend and a fun dude, a good person from Pulumi, Matt Stratton. How are you today, Matt? I'm doing good, Jay. It's kind of an unseasonably warm day here in Chicago. I think it might be all of about 55 degrees. So I'm enjoying it. It's not too... Oh, it's 61. 61 degrees here on December 15th here in Chicago. Yeah, it's pretty chilly here in Brooklyn, but that's par for the course. So you got that from us from a couple of days ago. That's so good. You got the 60s coming. You'll have a nice weekend. So we've got a limited amount of time today, and I wanted to be able to jump right in, Matt, and really start people on what we're going to be talking about today. If you have questions we ask, you just put them in the chat. Like Rebecca said, if you want to follow along, there will be tons and tons of links for you to access. If you go to that reactor check-in and use that event ID, you'll be able to get everything that you need. So let's talk about our agenda today. It seems like it's a long list, but it's not really that long. We're going to start off with what is Azure Container Apps. We'll talk about what are some of the use cases. We'll look at environments, revisions. We'll do a quick demo. Then we'll talk about Pulumi. We'll demo Pulumi, and then we'll finally close out. We'll have resources. So this should last about an hour, and we hope that you get a lot out of it. So here we are. We're about to get started. And the first question, Matt, I'm sure that you want to have an answer to, and I know everybody else probably does, is what are container apps? I would love to know that, Jay. Sure. So container apps are a new serverless container platform for building modern apps and microservices. It's built on AKS, which is Azure Kubernetes Service. Every application runs on that. It has CADA, Kubernetes Event Driven Auto Scaling as part of it. So you can drive the scaling of any container in Kubernetes based on the number of events that need to be processed. So if you have a bunch of stuff in, say, a MongoDB database, or you have some stuff set up in Kafka and you want to be able to do to keep an eye on what your queue is like, CADA can help you when it comes to the scaling based on how much that actually needs to be processed within those data sources. We also have Dapper, which is a distributed application run time. It provides APIs that simplify your microservice connectivity. So whether your communication pattern is service to service invocation or PubSub, Dapper will help you out. And then Envoy is an L7, Layer 7 proxy, and Communication Bus designed for large modern service-oriented architecture. That's a big mouthful. So what we can do is actually deploy multiple individual container apps into a single container apps environment, which acts as an isolation and observability boundary between a group of container apps. So container apps deployed to the same environment, logs, to the same log analytics workspace. So Matt, would you like to go? Oh, that's just going to say. So what are some use cases for this? Because there's a billion different ways to run containers in different places. What's a good use case for ACA? So yeah, we've got a few here. Public API endpoints is one of the great ones with scaling based on HTTP. We've got background processing, which is for transforming data in a database. In this particular case, its scaling is determined by the amount of CPU or memory load. We have a Q-rear application. So if you have messages coming into some sort of Q-system that you're using, you can scale determined by the number of messages in that Q, what I was talking about before with Cata. And then we can deploy and manage microservices architecture with Dapper. So we can create a robust application, have it with different microservices, and have Dapper provide all the runtime and everything else that you need for those. Sound good? No, I like the Dapper part that gives you a lot of flexibility, I think, in just a different abstraction, which is that. Yeah, and what's great is that the team working on Dapper, which is open source, are putting out new features all the time. They've really worked out on that, worked really hard on making that project really great for you. So container apps are in environments, and environments are an isolation boundary around a collection of container apps. So you have a secure boundary around a group, and then container apps deploy it to the same environment are deployed in the same virtual network, and write logs the same analytics workspace. So why would we use these, Matt? So I mean, I think it's a couple different ways, right? I mean, there's definitely security boundaries. So a lot of times we think about environments just as part of like an SDLC, right? So you're going to have a different setup for your dev and your QA, your test, your scale, your prod. Now that being said, good practices, they shouldn't be that different. They should look the same, but you're going to potentially have different security boundaries, different resource allocation. But you can also, environments are not necessarily bound to your SDLC as well, right? Like maybe you're thinking from geos, different geos, different places where you're going to put that. So it's just sort of what's something. So I always like to think about an environment as it's an instance that they should all look exactly the same, except like the shape of the dial is the same, but what you set the dial to might be a little different, right? So sure. And so along with environments, we can basically deploy our container apps as microservices. And microservices obviously are segmenting all of your different portions of your loosely coupling portions of your architecture into separate services that exist on different sets of pods and containers. So Azure Container Apps provides a foundation for deploying microservices featuring independent scaling versioning and upgrades, service discovery, and as we've mentioned before, DAPR integration. And while container app features the building blocks for running these, the use of DAPR provides an even richer microservices programming model. And DAPR includes features like observability, pubs up, service to service implication, TLS retries and more. So Matt, I was going to say, so what languages can I write my container apps in? You know, you can run in any runtime, any programming language or development stack of your choice. Right now, only Linux containers can be used. And you can define multiple containers in a container app. Groups of containers are known as pods. The containers are in a pod share hard disk network resources and experience the same application life cycle. So a part of this are revisions and revisions are an immutable snapshot of a container app. And the revision scope changes are any change that it triggers in new revision, while application scope changes don't create revisions. You can have up to 100 revisions remain available before being purged. You're not charged for inactive revisions. And they're most useful when you enable ingress to make your container app accessible via HTTP revisions are often used when you want to direct traffic from one snapshot of your container app. Typical traffic direction strategies include A, B testing, blue, green deployment. So these are ways to utilize old versions, mix with new versions so that you can add your revision. So once your revision is no longer needed, you can deactivate individual revisions, or you can choose to have them automatically deleted. So you can take a look at that little setup. And there is a traffic splitting rules configured in this example. So the 80% of the requests will go to one set of pod containers. And then 20% will go to another. So let's say you're introducing a new version of your application. And what you want to do is have just a certain segment of your users go to that one. You can do that within here. And then we said dapper that event driven run time is a part of it. Available dapper APIs for container apps include service to service call pops up event finding state stores and actors. You just simply deploy your services with the dapper components and you can get everything up and running that you need for your microservices. So moving along because we're going to keep this going, right, right. Let's talk about pricing container apps are billed on the total number of requests executed each month and executions are counted each time an app is executed in response to an HD request or an event. The first two million requests are included free each month. And they're billed based on resource consumption measured in a vCPU seconds and gigabyte seconds. The first 180,000 vCPU seconds and 360,000 gigabytes per second each month are free. So there is the ability also by default to scale applications to zero. So when you're no longer in need of these applications, you can go all the way down, save your money and not necessarily leave a service running 24 seven. So Matt, do you want to take a look at how to at least do this before we show how we can do this with Pulumi? Why don't we take a look at how we can do this in the Azure portal? Yeah, I think it's a good idea. I think it's always always great to sort of see the thing that's great with using a portal or something like that is we can we get a visualization of kind of the options. Some of the things we're going to try to do because you kind of need to know what you want to do before you want to automate it. And I saw there's a couple of questions and the chat to somebody asked a question about deploying with Terraform. I'll talk about that a little bit when we get to the Pulumi part. You might not like the direct answer I'm going to give you, but so what I'm doing here is I'm going into my portal, going to the container apps and clicking create. And that'll let me go ahead, create a new container app, create a new resource group to keep everything in. I'll give it a name. I'll use demo app. I can create an environment. And like I said, we have all these isolated environments that we keep everything in. So we can have them also scooped by region. So this is going to be my fraud one. I'll use that Canada central one. It's in preview of the service. So it's a limited number. We also can specify a log analytics workspace. I'm going to create a new one. I'm just going to call it workspace for demo app. Then we'll click okay. And all this, you know, pretty quick, obviously, then we'll click create for that service. The fastest clicker in the West, Jay. And we can see here we have a quick start image we can use, but if we decide we don't want to, we can use ACR, Docker hub, public or private Docker registries. In this case, we're just going to use a simple hello world container that's already built. We can see we've got our application ingress settings. And now we have all of our information here within Azure resource manager that will create everything. And so we'll click create and we'll submit the deployment. It'll send everything over to the Azure resource manager API. And in a few minutes, we get our service. And you can see I get an HTTP URL or a GPS URL. There's our application. It's up and running. And so we can take a look. We've got a whole bunch of options for different things, like being able to set up continuous deployment with your GitHub account, specifying a specific Azure container registry, specifying specific Docker images, service principle for 80 management. Then there's also the ingress. You can choose what port. I'm just moving real fast secrets. We can add secrets in order to have encrypted secrets moved in between our application. So we can just add key value. And that's pretty much the fast version of just building an application. And I know you've got some more to show me. And now it's time to talk about Pulumi. So why don't you tell me a little bit more about what Pulumi is. Absolutely. And then we're going to give you a little bit of every little bit of background on Pulumi, why you might want to use it, and then see how we can apply Pulumi to do to work with ACAs. So I like to think about this idea of cloud engineering, which might sound very similar to some things we talked about with DevOps in the past. But really what we're when we think about engineering in the cloud, it's thinking about we have one way to build, to deploy, and to manage our modern cloud applications. And so we start with cloud resources. Those are things that are living in Azure, all sorts of cloud resources, and we use them to build our infrastructure platforms. And we deploy our cloud applications onto them, and then we have to continually manage them. So when we say it's one way, the thing is it's really your way. And that's one of the key ideas about Pulumi is that we support all sorts of different ways of being able to do this kind of this kind of work. So if you kind of go to the next slide, please and thank you. So why do we think about this being the path to cloud engineering? Like we want to be able to harness the modern cloud. The modern cloud is complex. And we're thinking about bringing the cloud closer to app dev and applying these engineering practices. Now, what Pulumi is, is Pulumi is Infrastructure as Code, or I like to think about it as infrastructure as software. Because I've been in the Infrastructure as Code config management space for a long time. I was a big part of the Chef community for a long time. I've used pretty much probably every single way you can do IAC. And a lot of the IAC stuff, we say it's Infrastructure as Code, but really, we're creating infrastructure using some code. And I'm not trying to gatekeep about what is code and what isn't. That's not what's important. But what you can do when you're writing a Pulumi program, which I'm going to show you one, the Pulumi program is the thing that's going to create and keep your infrastructure the way that you want it to be. But the cool thing with Pulumi is you can write that in the programming language that you're already comfortable with. So if you know Python and you love Python, you can write Pulumi programs in Python. You can write them in Go. You can write them in any .NET language, and as well as JavaScript and TypeScript. I'm going to show you some stuff with TypeScript in a minute. And why does that matter? Why is that interesting? Well, I can't tell you what you find interesting. I can tell you what I find interesting. There's a couple of cool things that come about when we're using a programming language like this. Number one is we have access to that entire ecosystem, the robust package management that exists in Python and in NPM for JavaScript, all the testing libraries, all those parts and pieces, besides the fact that you might already know that language. And it's a programming language. So we have crazy things like loops and conditionals that you can do, abstractions. We can create our own packages. So there's a lot of power that comes with using a programming language to build your infrastructure as code. And if you go to the next slide real quick, we've got one more just to sort of think about how Pulumi works, and then we're going to take a look at it. One more slide over. This is kind of our model, right? So we have a project at the top level. And inside that, we're writing a Pulumi program. And these programs are made up of resources. Resources are those building blocks. So a resource might be a resource group. It might be a VM. It might be a network group, right? And they take and pass between themselves inputs and outputs. And I'll show you how that works. And then we talked about environments before, right? So remember when I said that an environment was kind of just an instance, but maybe the configuration is different. In Pulumi, we have this idea of stacks. So a stack is an instance of your program. You run your program, but maybe with different configuration data, like what region do you want it to run in or something like that? So that's how those can connect and go back. And the one thing I want to tell you about before I dig in and show you the code that I think is really cool about Pulumi in Azure is in order to use Pulumi to configure a thing. You use something called a provider, right? The provider is, you know, there's providers for all the major clouds. We have Kubernetes providers. We've got PagerDuty. We've got Datadog, all that stuff. And of course, Azure. And our Azure provider is what we call a native provider. And what that means is all the resources of that are built nightly according to the API spec published by Azure. This is really important. That means as soon as there is a new feature or a new configuration or a new capability in Azure provided that Azure publishes that to the API, it will be available in Pulumi the next day. That's a big deal. And the reason I'm bringing this up is there was a question. Someone said, I'm really interested. How do I deploy container apps via Terraform, for example? And the answer right now is you can't because the Terraform provider is going to have to be updated to add that. We had it right away. There's even, even the Azure CLI needs a custom extension for that. So Pulumi can do it. That's a powerful thing of the way that that code gen happens is where that really comes into play. So I'm going to show you how this works. We'll flip over and I'm going to share my screen. Yeah, you just get your screen. Very cool. And we'll do a little, now I'm not going to necessarily live code this for you because this is not a Mavis beacon teaches typing. But this is some example code that will be our Pulumi project. And I'm going to give a little walkthrough of what this program looks like. And there's a couple, again, this is a note, this is written in TypeScript. Now I could have written this in Go. I could have written in Python. It would all work the same. We don't really have the time to go through four different programming languages. I see that my friend Engine is in the chat and they always want me to do it in Go. But I'm telling you, tomorrow on my live stream, we're going to do Go. Today, we have TypeScript. Sorry. I keep promising it. Anyway, so a couple of things, if we take a look at what a Pulumi program looks like, we have a YAML file that's just sort of giving the configuration that says this is the name of the program, the project, and the run time is no JS, right? This is identifying what's different. Nothing terribly interesting in there because we can see these are the packages that come into play. And one thing I want you to notice, I'm here in Visual Studio Code right now. And you're going to see there's a bunch of type ahead and autocomplete. And this isn't because I have a Pulumi extension of VS Code. This all comes for free from TypeScript. This is just because it's a package. And that's, again, the power of using a real programming language. But really, what matters is we have our index.ts. And this is our TypeScript program that is going to run our stuff. So I'm going to walk you through this real quick, or maybe not so quick, just a little bit. We'll take a little time. We'll sort of look at what this is doing and see the interesting things that we can do. And I can already see that you've got ACR container registry there for where we're going to be storing our image, operational insights so we can get information on how our application is performing. And then we've got resources and web. Why don't you tell me a little bit about what those are, the resources and web force? So these are all different packages. This is our imports that we're saying these are the NPM packages that we're going to use and where they're going to come in. So of course, now and the reason what this program is going to do is we're going to create a resource group where everything is going to live. We're going to create a container registry. I'm going to build a Docker image, push it to that container registry, and then that's what we're going to deploy to the CUBE environment for the ACA. So what's happening, these imports, this is all just our usual JavaScript. We're just saying we're going to be using resources from these things. And you'll see where they come in. So first thing we're going to do is everything, hey, we're going to add, we need a resource group. This is a boundary. So we're going to create a resource group. And you'll see it's, again, look at all this robust information about how a resource works. And that's all for free. So we're creating a new resource group and we're naming it RG. Now, naming things in Pulumi, you will see when this resource group gets created in Azure, it's not actually going to be called RG. It's going to be called RG- some other identifier. So Pulumi does an auto naming thing and it does this to prevent name space collisions, right? So that they're unique. Now there are times when you don't want that to happen, right? You might need a very explicit name. So you can override that. But, and we're going to do something where we're going to see all the details that happens. But yeah, the first thing we need to do is create a resource group. Cool. And then we're also creating a workspace and operational insights workspace like, like Jay talked about. And so, again, it's called Log Analytics. But we have, these are all the different parameters. And there's multiple parameters we could provide from these are, but these are the ones we know we need it. And the first thing is we need to say what resource group is it going to be in? And because this was a programming language and it's, we created this as an object, it has a property, which is its name. So I can pass the, it gets created here, and then we can pass it along over here. Whatever the name is that gets created here is now an output that gets you that is usable over here. So I have a question for you. So that area where you're putting an RG for the prefix right here, is that able? Yeah, is that able to be, I guess, genericized so that you can pull it from say, parameter somewhere? Or does it have to be hard coded into this portion? It does not have to be hard coded. So you could pass that as a configuration item, like maybe you want it to be specific. And I'll, I'll show you and just in fact, actually, I'll give a good example. One of the things that we need to do that is going to be, remember, I said you might have different configuration based on the stack. So the first thing we need to have here is right now, I don't have any stack. So I'm gonna, I'm doing, I'm gonna, I'm gonna give myself a new stack called dev just to give us something to work with nothing really terribly exciting happened there. But one of the things I need is I need to say what region is this going to go what location is it's going to go in. So if I say plume config, and as we learned, and it's central Canada, is that yeah, okay, because this is one of the places where ACA is available. And what that did is it created this other YAML file this plume.dev.yaml and you'll notice it has this. So let's say for example, you wanted to pre you wanted to name the resource group after the stack maybe, or after the environment or something like that. Well, here's the fun thing, man. This is just a string. And you're in JavaScript. So you can do whatever you want. Right. You could you can you can concatenate it. You can pull it. Pulumi knows the name of the stack that it's currently in. So you could query, you know, you could bring that in as part of its object and put that in there. So again, this is just we're passing in a string, but this can be whatever value just the same way that this is not a string. Maybe you created something earlier that you wanted to name it after you could reference back to that. So that's actually not a terribly uncommon thing that you just said. Like maybe we would set the config to say what environment do we call this? Or again, map it to the the stack name and because that could be useful during your CICD process of being able to specify like, okay, if we push to this, use this config file to do the build and then eventually the deployment to this particular environment. Yep. Absolutely. Absolutely. Why do I keep losing my word wrap there? Okay, cool. So so that gave us our our log analytics. And again, the important part of this is we're able to see that. And then also if we were to take a look here, I'm trying to see if there's any other this this actually might be all that there is to configure for log analytics. So that's okay. So then we also need we're creating some shared keys that we're going to use to pass these things around. Again, look, we created a workspace, we can reference back to that. Here's here's the ACA interesting part here. Now so now we're going to create that cube environment, right? And it gets to go in a resource group. We already know what our resource group is, we can go grab it, right? And the same thing, it takes some parameters around the log analytics. Well, we've created that it we've created some shared keys. And we're running this apply, which is basically saying is how the an apply is how we take an output from a different resource. And we can do something with it, like turn it into a string or turning it into another object, which lets us let's us work with that. So now this is saying cool, we have a new cube environment. And again, this is the string that identifies its name, because if we were to take a look at it, we can see what goes with a cube environment, right? Like it has its name as its string, and then it uses these web cube environment args. And we can see what those options are. Now, so that gives us our cube environment. We also like we said, we're going to create a container registry, and which is in the same resource group, all that good stuff. And you don't know a container registry is just an Azure hosted Docker registry where you can put your and you can build and keep your images. Because we want to have somewhere to go push this this image to now you wouldn't necessarily always keep these things all in the same exact Pulumi program, you might you might already have a different container registry, but for purposes of my demo, I'm not going to go keep one just hanging around. Oh, that's right, we are doing a Go session on this in in January to all sorts of fun. And so again, we get that we're able to get the credentials from the weather when the container registry gets created, it creates the admin user because we did admin user enabled. Now we can query and get those credentials. But none of this is ever going to be be seen by a human, right? These are all objects being passed around. And then we have over here I have my note app. This is the app we're going to do so you can see, you know, it's not very exciting app. But we've got the code, it has a Docker file. This is the app that we want to deploy. So we say we're going to create a new image and we're using the Docker provider, which is why I am on my different computer because I wanted to build because I can't build an arm image and push that to ACA. So we have to do I had to dust off my Intel MacBook to do this. Fun fact, cool. So again, I'm going in there and I'm saying, you know, this is all the Docker stuff, right? What's the image name? And I can do this Pulumi interpolate so it knows what is the actual server for that image to go to. Here's the login, all that stuff. And then now finally, we've done all the pieces and parts. It's time for our container app, right? And all we're doing here is just sort of taking all those Legos and putting them back all those Lego, I should say, putting them back together, right? What's the resource group? What cube environment? We set our ingress, right? So we're a target port is 80. The, you know, which registry is connected to it. And then what template we're using this, this my app template that we've, which is again, going back to that image. So and then when all is said and done, it would be pretty helpful just like you saw in the portal, there was a little clicky click for the URL to get to your app. It's one of the things we can do is we can we can kick outputs out of our Pulumi program, which maybe we might pass along to another program or they're available to us at the command line. So we're exporting another very a constant called URL, which is basically saying we're doing Pulumi interpolate. So we're, we're creating a string that says take the configurate, you know, the ingress of this, do an apply onto that. And this should then give us our entire URL. So that's going to kind of give us our, our stuff. I wish I knew what I changed that made that dirty, but let's find out. So we've got our stuff kind of set up. One of the things I would have done, except I've already done this. So you'd have to do an npm install to make sure we've got our packages. They're already installed. A couple other things that I have already done. I'm logged into Azure at the CLI. And that's just because Pulumi is going to use those same credentials. I could pass them along in environment variables, I could put them in profiles, all sorts of different ways, depending how it goes. But I'm already already set that up. And I'm also long, easy login, just easy login in this case, right? So it does not require to do it that way. That's just the easiest way to do it for a demo. The other thing to that I'm going to talk about super quick is Pulumi has to have a, you have to have a way to store your state, right? You're, you're saying we're creating desired state of infrastructure, right? I want my infrastructure to look like this. Well, how does Pulumi know what it looks like now at any given time? So you have to have somewhere to store the state and we store those in what we call backends. And there's multiple different types of backends. You could, you could use blob storage. You could put it on local file system if you want. One of the easiest ways is to use the Pulumi service, which is a SaaS. It's free for individuals. But you just hit that API. That's sort of the default one. I've already logged into that. So if we do Pulumi, who am I, you can see that I'm logged in as Matt Stratton. So what will happen is now I'm going to run my program by running Pulumi up. And what Pulumi up is going to do is it's going to compile and run my program, but it's doing a preview first. It's not actually doing anything. And actually, as an example, if you see this view live, if I were to click on there, it would take me to the portal. I could see basically everything that's in here. So here's what we see. It says, okay, if, if you were to run this program right now, this is what it's going to do. It's going to create seven new resources. It has to create the stack because that stack actually hasn't been created in the Pulumi service yet. I just created it locally. It has to create this Docker image. It has to create the resource group, the registry, the workspace and all this stuff. And if we go into, I'm going to, I'm going to resize this here. If I go into details, it's going to show me exactly what it's going to do, right? So some good examples here. If we go back and take a look at what it thinks it's going to create, look at the resource group name. It's RG. Is that randomized? Yeah. Yeah. It's added that to there, right? And the registry is registry, et cetera, et cetera. So we can kind of see, but let's go ahead and say, yeah, kick this thing off. And one thing that you'll, and so we can see it's sort of chugging away. We can see all the stuff it's doing. And it's, that's the wrong name. It's Canada. Canada Accenture. Canada Accenture. So I could have gone in. There we go. I always like to see mistakes in real time. Yes. Oh, then you should watch me do demos all the time. That's all they are. What I could have done here, and I should have, is if I had done, I noticed it only has to create five now because it actually did a couple of things before it had that problem. It created this stack. Item potent. Yes. Yes. Item potent, which means that every time you do something, you should get the same result. And you could do, if I did Pulumi up dash Y, that would just go ahead and skip. I like to think that stands for YOLO. I have been known to, I never, I never show my funny aliases in a demo. And I don't think I have it on this machine, but I do have Pulumi YOLO alias to Pulumi up dash Y. Because we don't necessarily need to do the preview in this case because we already knew. I'm going to see if I can get this. And what's great is, since everything that you've created is in code, we can keep it in our source control. So we can always go back and look at what needs to be changed and see if a change didn't work for us. Also, what's an interesting pattern you can do as well? Speaking of putting it in version control is you can store your Pulumi program along with your app. So that's a common practice as well as you might inside your application. Sort of, we have that a little bit where my node app is, right? So if this was my version control, and it wouldn't have to be at this level, you could have a folder inside it called infra is a common pattern. And that has the Pulumi program. And then you could wire that all up with GitHub actions. So that when you, you know, on a merge or something like that, it will actually go and run the Pulumi program and do all of the stuff. And it knows all what it's doing. There's a couple other really powerful things that we aren't going to get into today. But you can really get your application to know how to deploy itself using something called the automation API. So you can, if you were writing a node app, you can actually use Pulumi inside the app itself using our API without having to kick off the command line. So that's really cool when maybe you're building like a developer portal or something like that is a really interesting case for that. This also helps you a lot with like GitHub. So one, this is not what we're showing today. But one of the things I've seen people use Pulumi for is managing their GitHub. So like when you have to create a new repository, for example, in your organization, instead of having to, you know, if you have a pattern for that, people just go in and put in a pull request against the info repo that and then Pulumi can go and build all that stuff. And even so far, so as I know a lot of organizations, their entire way of creating a new service, they just go in and add a few things and they just do a PR into that repo and then it goes in it and it builds all the stuff to it. So, and okay, so here we go. We have ourselves now, it went ahead and built that. And if we were to go ahead and if we just want to curl, and you can see because so we can get that Pulumi stack output. So we just interpolate that. It'll say what it wants to be. It's going to hit that. And we get to see your custom Docker images running in Azure container apps. Now I want to show you one thing. We aren't necessarily going to have to run it. But if we were to go take a look at our actual application, and instead of having it say your custom, you can just sit here and say, hi, Jay. I love punk rock, right? Me too. I know you, man. Right. So now if I were to sit here and say, so I made a change, notice I didn't make a change to my Pulumi program. But if we run Pulumi up, it's going to sit here and say, okay, let me check the state. Let me see what's up. And I'm going to take a look at this Docker image because I did change it. And it's going to say now, because Docker likes to kick out a lot of extra stuff, we, you know, it says, aha, I have to do an update because this is different now. And so if I were to run this, this only takes a hot second. So we can go ahead and do that just to prove our point because it doesn't have to go and build the cube environment or anything anymore. All it's really has to do here is rebuild that Docker image because the template of it changed. And then just kick that up to the registry, pop it out. And then update the version of the application within the ACA. Within the ACA. And then we should see, as soon as that's done, if we go ahead and just hit that curl statement again, we should see our brand new Fancy Pants website. And I just want to remind everybody, if you'd like to take a look at the upcoming session on Go, there is this Go at Microsoft session. You can take a look at that. I know Maddie, you said that you're going to be doing a session on Go as well on Pulumi. So we really, really appreciate that. And also reminder, if you want to take a look at some of the Pulumi examples, you can go to github.com slash Pulumi slash examples. You can see some things that you can get started with. And here we go. Yay, I love punk rock. Yeah. So yeah. So tomorrow, if you'd like, I'm doing a session on the Pulumi live stream at twitch.tv slash Pulumi and we'll be configuring and working with Datadog using Pulumi to manipulate some Datadog configuration. And I will be doing that one in Go instead of TypeScript. So that's at 3 p.m. U.S. Eastern Time, twitch.tv slash Pulumi. Should be a good time to tune in for some fun. Now, the last thing I'm going to do here real quick because so I spun all this stuff up, but I don't want to keep this hanging out. I'm done with it. So I just do a Pulumi destroy. And what Pulumi destroy is going to do is it's going to all of the resources that my Pulumi program has created. It's going to go and remove them out of Azure, right? It's going to delete the resources, which I want to do because I have no reason to keep this app around indefinitely. And don't want my CFO coming at me and being like, hey, Maddie, what's this like $3 charge on our subscription or whatever? Because again, actually to be fair, if you think about it, that's probably what I just did here probably wouldn't be very expensive, right? The way you said, I mean, there's no... I've got 2 million, 2 million, 20 million. How many connections? I think it was 2 million. And you also barely any build time Azure Container Registry. And it's cool that you can just say, hey, destroy and all the resources that we had created just go away. You don't have to go into the Azure portal or create another AZ command to destroy the resource group. It'll all happen right here. So you have a single place to do all your things. And it will get all of the connections because you know how sometimes you're like, oh, I got to do this thing, this thing. Oh, but before I delete this, I got to get rid of this and blah, blah, blah. This will take care of all of that. The other thing you can do with Plumi that might be interesting to consider is if you do create things, you can do a Plumi import. You can point it towards your cloud infrastructure, towards your stuff in Azure and it can import that and start to give you a good starting point. You're going to still want to tweak it because I don't trust the robots 100% about anything. But if you already have some stuff in place, you don't have to start from nothing. And the same thing, you can also import from Terraform. You can import from ARM, ARM templates. There's all sorts of really great and easy ways to kind of get started. So we want to kind of flip on. This will just take a second. That should watch everything delete. And I think we got a couple... Yeah, I think all these links are in the check-in, but we could kind of maybe... Yeah, so if you want to go, there's a great blog post on introducing Azure Container Apps that came out. There's also a really amazing demo that Jeff Holland, who's part of that team, he put it on YouTube. If you just look up Jeff Holland, sorry, I forgot to put it in here. I should have. You can take a look at all the container apps preview documentation, ACA docs at that aka.ms link, Azure Container Apps product page, aka.ms slash ACA product. And then if you want to take a look at a Astro microservice sample, if you go to GitHub, aka.ms slash ACAGH, you could make use of this new way of working with a container orchestration on Azure without having to use individual Azure Container instances or having to manage that or to have to manage an entire Kubernetes cluster. Even though aka.ms makes it easy for you, this is built on top of aka.ms. And you can just provide your application code and you don't have to worry about manifests and things like that. We're going to take care of that for you. And Matt, I know you've got some resources as well on Pulumi and here we go. Yep, so a couple of things. Again, I generated these short links really fast, so they aren't the most memorable, but if you're watching this later and you can freeze frame, plus all the links are in the check-in page. But a couple of things. So first of all, there's our link for getting started with Azure. So that's just kind of a quick start to kind of see some of the things you can do with that. The Pulumi registry is our list of all of our providers with all sorts of documentation and stuff. So that's a link to the Azure native provider in the registry. That blog post was written by my colleague, Mikhail, who, Shilkoff, who you might have noticed his name in the get-to-name that was coming up. So some commit history in there, yeah. Yep, yep, yep. But it's cool because in that blog post, there's links to... I was showing the example with TypeScript, but we do have the Go, C-sharp, and Python examples as well. And then similarly, that if you go to Pulumi, github slash Pulumi slash examples, it is a wealth of code examples in all different languages, all different providers, all different stuff, a lot of great resources. Some is written better than others, by which I mean the stuff that's written better is not written by me. The less better is some of the ones that I wrote, but we're getting... I'm working on it. I'm working on it. And... I know that feeling. I know that feeling very well. Yeah, but yeah, every week on Thursdays, I'm streaming on Twitch, if we got different Pulumi stuff. Maybe we'll have Jay come on sometime. He and I like to jam. And yeah. So I'd love to... Hit me up on Twitter at Matt Stratton if you're doing cool stuff or trying to do cool stuff or just even boring stuff. I'd love to hear about it. Yeah, stuff is great. I'm really into stuff myself. And you can find me on Twitter as well at JayDestro if you want me to find you some more resources on this. If you have questions, I can also go back to the product team and have those discussions if necessary. There's been so much that's been great to talk about today. And Rebecca, I have enjoyed doing these sessions recently. They're really great. And I know that there's a lot more coming up. Where can people find out about those? Oh, thank you, Jay. That was a great transition. So this session is part of the Microsoft Reactor Programming. You can find us on Meetup. We have 12 physical spaces internationally. So if you search for the Microsoft Reactor, just pick a location that's kind of in your time zone close by, sign up there. Right now, most of our sessions are virtual. So you have the access from afar. If you happen to live nearby, eventually in-person sessions will return. And you can check us out face-to-face. You can also find us at microsoftreactor.com or on Twitter. And we send out a monthly newsletter, aka... Sure. Sorry. You know you're good. I'm really, really looking forward to getting back to that New York City reactor up in Times Square. It's a really great place. There's tons and tons of room for people to kind of do things. I used to host sessions there. And I do miss it. No one to see all your beautiful faces. Yeah. So thank you all. Thank you, Jay, again for coming on again. Maddie, hope to see you all maybe again sometime with that. Yeah. After we'd happy to have you. Absolutely. We'd be happy to have you. I think you got some things in play, so... And thank you to our audience for tuning in, for commenting. Check out all of the resources. Let us know. See you at the next one. You're the real MVPs. See you all later. All right, bye.