 Hey everybody. This is Andrew Connell with the Cloud Dev Clarity Episode 6 show. Today, Julie and I are going to talk about something that get a lot of questions about. We thought it'd be a great topic to cover today. So it's all about the Azure Resource Tour. Now, it's not everything. We're going to talk about what we use, why we use it, and what some of our favorite things are that we have inside of Azure that we like to use a lot, and why? Hello, Julie. Nice to see you again, Andrew. Good to see you too. It's been a little while since we got together and did this. That's right. So we've had a few weeks since we released our first five episodes, and we've had some pretty good feedback so far. I'm excited. I was very, I was a little surprised, pleasantly surprised. I was a little surprised at the number of people that were pumped up about what we were doing and why we were doing it. I think we hit a nerf. The reasons that we had for starting this really resonated with other people too, and that felt really good. Yeah. Nice. Yeah. It's always nice when you have an idea about something, you're like, I really think that we need to do something like this, and then I'm doing this because I know that I feel like, I like to get together and talk to you about it. I mean, we talked about this in our earlier episodes, but now I do I like to get together and talk to you about this kind of stuff. But I like the I just like to cover the topic and just it's fun to talk about it. And it's cool validation to see when some people that you know or something you don't know jump in and they're like, oh, my God, this has been so needed in the community or whatever. It's like, yeah, cool. Yeah, I totally know what you mean. Cool. One thing I do want to we do we did want to cover before we really dive into this is I want to I want to kick off. Let's show this little teaser here is that Julie and I want to stand up a little bit of a community or at least a place where people can interact with us and talk about upcoming episodes, talk about the current episodes going on. And the way we're doing this while we're still publishing these to YouTube, we are also going to be having like a live studio audience that you can jump in. So if you've ever watched a show like Saturday Night Live or any of the sitcoms, what we're doing is we're streaming this our recording to Discord. And we're doing it on the Voigtanos Discord community. So we've got a link there where you can learn more about how you can dive in. Voigtanos.io slash Discord. I'll show you really quick what the way this is going to be set up here if you want to take a look. So the way the way it works is that once you join. Oh, look, Julie is in the audience. The way it works is that once you join the community and like I said, the link there on the on the on the screen where it's Voigtanos.io slash Discord explains how to do it. You basically going to go in, you're going to join the Discord server, which is really just a Discord account or a Discord community. You'll log in once you've connected to it. There'll be a place where you have to go verify that you've read the terms and conditions and all the stuff. It's all listed on that page. It's linked there on that on the on the screen. And then once you get in, you'll see sections for like different events. We use events for a lot of different things, but you'll find an event here where we have like this when you see is our our live show for episode six, the one we're doing right now. And there's a button where you could say that if you're interested or not, and that'll let you know when we're going live. And then like right now, there's a section for Cloud Dev Clarity where you can learn about, you know, episodes that are as they're published. And then when Julie and I connect to doing a new show, like we're doing right now and in the entire pre-show, we'll connect the audio and we'll stream it live into Discord so anybody can jump in and listen to what's going on. And then at the same time, you can also go over to the episode chat and you can have like a conversation in the background with other people who are listening in on the show or under the recording. Ideas about future episodes, stuff like that. So you can just kind of keep in touch with what's going on with this and we'll have that up during the show. We primarily are going to be doing the when we do the show, we're primarily going to be focusing on just the conversation that Julie and I are having. But I mean, there may be times we kind of look over there, we take a peek and it's like, hey, look, you know, this person saying something or this person saying something and we want to go through, we want to show that or talk about that. So we may bring that up, but no guarantees we're doing that. We just thought it'd be a good good way to interact with us. Yeah, gives us a way to to, like you said, interact with people. And, you know, hey, if people use it, great. And if they don't, they don't. But if you have ideas for the show or feedback about the show or things you want us to cover or whatever, it's a great way to share that information, not that you can't do so in the comments in the YouTube videos themselves or, you know, reach out to either one of us on Twitter or whatever. So lots of ways to do it, but that's just one. Absolutely. Absolutely. All right, show. Let's move on to the meat potatoes. Yes, meat and potatoes. I like potatoes. I like potatoes. I like them roasted with ghee and salt. Gee, it's key clarified butter. I can't have butter. I know, I'm sorry. Really good, but it's got no milk fat in it. You might be able to have it. I didn't know. Well, maybe I take my potato, baked potato, nice, baked potato and like sneer and Crisco and then put some sea salt on big rock salt. We didn't have a conversation. We'll have a whole thing about the cooking of the potato. Episode seven, we bake potatoes like cloud of clarity. That's what we're doing. All right. All right. Meat and potatoes. So today we're going to talk about is about Azure resources. We get, I get a lot of questions like, what am I supposed to use? I was actually on Reddit earlier today and I saw someone like, you know, what am I supposed to choose to store my data? What do you use? And I think I want to stress this from my point of view. I mean, you've got to be a different opinion, but we're going to share like what resources we most commonly use in our day-to-day Azure lives when we're building an app, whether it's something that lives inside of a SharePoint or lives inside SharePoint or Microsoft Teams or Viva or any of the Microsoft 365 stuff. But when we need to have extra resources where we're going to store or host some content or some data, what do we end up using in Azure? So we get a, we have our list. It's not exhaustive on everything inside of Azure. Oh no. Yeah, no. We have our own reasons of things where we like or dislike stuff. And I would very, I would be very curious to hear from people who are watching this episode, what are we talking about that you disagree with? What are we not talking about that you thought that are your favorite resources and why? And the best way to do that, leave a comment. Leave a comment down below for sure. I have to say you and I come at this from very different perspectives based on just why we use Azure. I think of it as a, that too, but I was more thinking I think of it as an extensibility platform for the platform. We came as a Microsoft 365 developer. I did come from that, we've talked about this, the SharePoint on-prem days where when you wanted to extend the platform, you used a farm solution or a sandbox solution or whatever it was with a SaaS product like the Microsoft or Paz product, depending on how you want to think about it, with that kind of product, you have to come at that from a completely different way. Extending that platform is a different thing. And so I think of Azure as the natural extension, the way that we extend the platform. So I come at it from that perspective and I think you come at it from a slightly different perspective as using the platform mostly to run Voitanos or to automate parts of your business or whatever that might be. So it's interesting because we'll have different perspectives on these things although we'll use many of the same things. Yeah. I use it for the same things that you use it for but that's not my primary use case. My primary use case is what you described is to run my business. But yeah, I have everything I can, if it's not like a SaaS service I'm using that's outside of Azure, like for example, my courses or my videos are all stored. I use a service called Wistia for streaming the videos. And so my videos aren't in Azure, they're backed up to Azure, but everything else about my company, everything else is stored inside Azure, so. Right, right. Okay, so why don't we kick it off? Yeah, dive in. And then let you go first. Well, I think we should start with Azure Functions because I feel like that is, as serverless compute goes, it is the low hanging fruit, easy to get in, easy to get started, easy to scale, I think. You can really start to build upon it and do more and more and more with it. I think there's ways to go beyond it but it's certainly the low hanging fruit, right? Because you can be, I mean, I'm going to say very clearly that this is not something I think should be done but you can use it to even automate PowerShell scripts, right? You can go to the platform, you can create a new Azure Function, you have an editing pane right there, you can be right in the browser and putting your PowerShell script in there and then HDT trigger, timer trigger, whatever it might be to run that PowerShell script. And so from a low hanging fruit, I just want to get started with Azure type of place. I feel like it's a real easy entry for many people and they have a lot of flavors, right? You can, the platforms, I said PowerShell but you can, Java is one, you can write C-sharp which would be .NET. And then there's not only .NET core, there's .NET standard and then you can do several different versions of Node are supported. So there's a lot of variety, right? Lots of ice cream flavors for you to choose from. There is, yeah, I agree. I mean, like you got other, the other options that people probably look at, it's like, this is, I guess this is the category that I look at is, where am I going to run my stuff? Where am I going to host my website? Where am I going to go through and run my stuff? And host website, that's not what an Azure Function is really for. It's really more like, I think that the quintessential place, the thing that scenario you would look for for like running and getting Azure Function is to have some sort of an API endpoint. Yes. That or doing some sort of an event-based scheduled process, meaning like an HTTP triggers what's going to trigger this request off, right? Right, right. Contents being added to a queue or something is being added to storage. Some event is going to happen that's going to kick off a process to run. Whether that be a timed event, because let's think back to server-based, right? Back in the day when we would have a server, how many times would we use the task scheduler to schedule a nightly job that we wanted to run? So we have that ability in an Azure Function, we can say, hey, this is a timer trigger, it's going to run once a day, once an hour, whatever it might be. You mentioned the queue ones, those are really powerful. And I think often people are a little fearful of them, like, what the heck am I supposed to do this? And how does this all orchestrate? But that, when I sort of said, you're low hanging fruit, you can start and then you can escalate queue triggers. Huge for that, really cool for event triggering by saying, hey, I have maybe an Azure Function where it's an API endpoint, where somebody asks a question or whatever and maybe that question or that request trigger, puts a message on a queue, that means that a job will run against that queue later and deal with some of those messages that are left for it. And so you can get really powerful as far as orchestration goes by just assembling Azure Functions together in certain ways. I think that's, it's very powerful. Yeah, I agree. I agree, I totally agree. The flavors, like, so any like, so let me just tell you a little special stuff that I'd like to do with Azure Functions. We can go much deeper in this. And a lot of the, like I said earlier, a lot of these topics we're going to go over, I'm sure that we could possibly have another episode where we talk about each one of these individually. So if you're watching this and you're curious, I mean, let us know in the comments if that would be interesting to you. But like for me, every single Azure Function setup that I'm gonna have, almost all of them are done on premium, not on the consumption plan. The consumption plan is cheaper, but it takes longer to spin up. And so if it's an endpoint, like an API endpoint that you're gonna have, I want a quick response. And so taking 18 seconds to spin up from a cold, go find available resources, go provision those resources, then spin it up. I don't wanna wait. Yeah, I mean, although on the flip side of that, if I've got a really small business that I'm working with that has very tight budget constraints and depending on what that thing is that they're requesting to do, I don't know that I have a problem with that. If I'm trying to keep them to a few dollars a month or close to zero a month for some low consumption type of thing, I'll take a consumption plan and deal with a wait, it depended. So let me flip that around. If it's an HTTP trigger, I want it to be premium. If it's gonna be any other kind of trigger, I'm cool with it being consumption. Right, right, right. No, I hear you, but I even have HTTP triggers that I'll leave in consumption for sure. Okay. And it doesn't bother anybody because they're waiting for a SharePoint page anyway, so they don't care. It's gonna take 20 seconds anyway. Let's be honest. That's true. The other part with Azure Functions is I'm 100% Linux. I do not use Windows. Are you? Interesting, okay. I use Linux for all of my platform stuff if it's an option. I try to avoid Windows at all costs. I find with Linux to be faster. I'm no argument here at all. We've talked about this in the past. There's sort of that. You get stuck in a rut and that's what you do and you don't really take the time to do something different. I'm definitely in that sort of rut. And so we were sort of talking about what we might wanna work, explore more. For me, absolutely getting out of that rut that says I have to use .NET and write C-Sharp. And you know what I mean? So if I was switching to node-based TypeScript slash JavaScript things, then yeah, exploring the Linux platform over the Windows platform makes a heck of a lot of sense. So I totally agree with that in principle, but full disclosure, haven't gone there. Just haven't made that switch. I guess the other one too for me is that almost all the continuous deployment and automation stuff that I do, everything is using Linux runners. And so it's like, stay one way. Yeah, absolutely. And that actually is a really good argument about why you might want to because as I have started to do some of that automation, you and I have talked about this a little bit, one-on-one separately, but as I start building up those automation, CI CD ways to deploy and to manage my deployment cycle, then you're making a huge point about the fact that you kinda wanna stay on the same platform. Yeah, I mean, nothing wrong with it, it's just... No, but I agree, I agree. Okay, so next question. Next point. Yeah. You wanna do storage? Yeah, let's do storage. Yeah, yeah, yeah. What's your preference? Or you want me to go first? Well, I was gonna say again from the wanting to shift thing, I had again, just stuck in a rut, always been a SQL Server person. You want data, you put it in a SQL Server, you have some tables, that's how you do it. I can write queries in my store procedures in my sleep. So that has been always the way, but I have recently just started being like, why am I using a SQL Server when I need like two tables? And that's about it. Why am I paying for that whole thing? So I have switched to some table storage, but you've got way more... Well, so with storage is, lob storage, file shares, please somebody tell me why that's useful. Like a map drive. Yeah, I know, but Jesus, really? Map drives? Yeah, I agree with you, yep. Okay. Cues, this is where your cues go. So we were talking about Azure functions before, when the messages get stored for your cues, they go in cue storage, that's also part of storage. And then you got the table storage. So those are the basic kinds of storage. What are the other kinds? Because you do a lot of them. So I don't use SQL, I can't, I couldn't tell you the last time I had to write a SQL statement. I don't remember the last time I used a relational database. You need some help, I'm here for you. I might need it one time. So, but I do find that I just don't have a need for like relational stuff anymore. I mean, it doesn't, I'm not saying it's obsolete. No, I don't think so either. For me, it's more like relationships, or it's like how our things are related. And I know you can do that with like, relational integrity and stuff. For me, the big one that I prefer using now is document storage. So that's like Cosmos DB and using more like document databases. The downside of document DB is more, it can be expensive, but they've been much more friendly with their setups. I totally wore the wrong shirt today. I can, you can tell that it's like summertime and I've been in the sun quite a bit. So like, I'm wearing like a V-neck T-shirt and I'm like, oh, it's a good tan, it's okay. Unless you've seen Mark Anderson in the summertime, you got nothing. His white hair, he is so dark. It's crazy. And with the white hair and he's got blue eyes, it's like, Mark's in Rhode Island. So, yeah, so for me, like Cosmos DB is big. That's where you can talk, you can do like, you can still do like use the tables query style to being able to get the data back out. But I'm a big fan of Cosmos DB. The other one too, is that if I'm just doing like, like short burst style data where I don't wanna like store it and store it and then have to come back, read it back out right away really fast. I want things to be really snappy. That's Reedus. I love having a hosted version of Reedus, throw a key in there, let it expire after a certain amount of time. It's a really interesting scenario and one that I haven't had need for, but if I ever do, I'm definitely gonna go down that road. It's just not something that's come up. So I don't, you know. So here's a great way to use it. I'll get, it's a real world thing that we'll talk about in a second. You know, when you do an authentication, someone comes in, you wanna authenticate. So you have to go obtain an access token from like Azure AD. To do that, you're probably gonna be using something like the authorization code flow. So you're gonna get back an authorization code. You wanna use that code and then go fetch and get the access token. Well, to make sure that someone isn't like hijacking the request, you use a state variable or a state string that you pass in that Azure AD is gonna read right back to you. Yep. I store that inside of Reedus. So the state value I generate, whatever the original request is, I serialize it or I do a one-way hash on it or I stick it into a, like for me, I actually stick it into a jot token. Store that jot token in Reedus and the state value, I get a hash of that jot token and then that's the state string that I send over to Azure AD. So when they come back to me, I take the state and I look for it inside of Reedus that's only been there for about a minute or two and it pulls out. If there's something there, then I know it's a legitimate request. If there's not something there, I know that you've either taken too long to do the authentication because it's a key expired or you're hijacking me, but I don't have to worry about like cleaning up the data afterwards and all that stuff. Reedus purges it for me. And it's blazing fast. That is a very smart move. Yeah, that is really smart way to use that. Interesting. So those are two of my favorites. Yup. One that kind of goes along with the storage side too is like, if you have to do a certificates or settings for your app. So for setting or for certificates or things that need to be like encrypted and not like clear text kind of stuff, key vault. Yeah. Yeah. Yeah. Yeah. And this was one of the things we're gonna talk about which is app registrations, enterprise applications. That is a service principle. Service principles are a type of management identity and managed identity in Azure is probably the best thing since sliced bread. But pausing on that statement to be able to use key vault. I think, I don't think people know that if you need a certificate you can go into key vault and say create me a certificate and it creates the certificate. You don't have to do the whole command line thing. Create the certificate, export it, blah, blah, blah. You don't have to do any of that. And all of that key vault stuff then you can if you need it like so if you're gonna store things in key vault that you might need like let's say in your Azure function or somewhere else in Azure you can reference that key vault. And because of this thing that I wanna go into a little more depth this is a managed identity. You can tell the Azure function will have access to your key vault and thereby you can have a slot or an app setting that says, hey, this app setting is for some secret that I have in key vault that I wanna get back. I want the Azure function to have access to. And basically because you have told key vault that the Azure function has access to it you can pretty much wipe your hands of that and know that that's like a whole, you know. It's all behind the scenes. It's all clean. It's all behind the scenes, it's all clean and it's in there and one person does it and creates it and then everybody just walks away. And I think as far as like having to have a human be involved. And I think especially when you get into the regulatory environments where you need to have those separations of concerns and all that kinda it makes your life so much easier when you can say, yeah, we have this one account that's the account that goes in and creates those keys in the key vault. X, Y, Z person has access to those credentials to do that. But after that, there is no human involvement in the access of that data. And so it's really easy to document what you're doing and you don't get a lot of questions when you can put that in front of an auditor and say, yeah, this is what it is. Boom, they're gonna be so happy. They're gonna be like, yep, okay, that's fine. Move along, makes your life a lot easier. So to that extent too, the other one that I love to use is app configuration. And that's great for like having like, these are my settings for dev. These are my settings for production. And those can also map to a key vault valued or you can store like secure strings or not just like certificates, but you can actually store like connection strings or passwords or stuff like that. Absolutely, yeah. So like I use that in my Azure functions where like I have a property, I used to store a ton of stuff in the app settings or in the app settings inside of Azure functions. And now I just store like two or three things. And one of them is like for the slot that goes, you know, what is this? This is staging or this is dev, this is production. And then my app is written to say, I'm expecting certain properties in app configuration, but to know which proper setting I'm looking for or which environment I figure out, what am I running in? I get that from the environment variable and the slot that I'm running inside of Azure functions and then it knows how to go get that settings. Now I can have complete decoupling of my settings from the runtime and just let the configuration of the app setting tell the runtime, are you dev, prod, staging, et cetera. Right, and that becomes really powerful, excuse me, especially when you start down that CI CD pipeline where you're trying to like orchestrate a bunch of stuff. And if you've encapsulated things in that way, it makes your life so much simpler than like copying out like 400 different properties and pasting them over and over and over again in different places. Yeah, no, that is definitely, I like that one as well. Do you wanna do the identity search? Let's talk the identity, let's just talk it through one more time. I like flew through it and I think you probably know this even better than I do, but I had me figuring, we're not having that episode today. I don't have my Rita, it's late enough, that isn't happening. I actually had a, I was today years old kind of moment, a couple of years ago now, but I had a today year old moment when I went, when somebody finally went, oh no, app, enterprise applications are just your service principles. And I went, wait, what? Is that what the hell those things are? The name is terrible. Yeah. Like, oh. Whoa. Julie overload. Let's confuse people even more than it's already to be able to be confused by the different kinds of authentication you can do and the way you do that, whatever, authentication versus authorization versus whatever. So you have an app, so Azure AD has a section for app registrations. That section is where you define what an application might need access to. So if you disagree with how I'm describing this, I would love you to step in and give more names. You're on a roll. I'm gonna let you run. So app registrations then are how you describe your application. So it gets an application ID, there's some configuration stuff about it. You can say this, it has these permissions to these APIs that are out there. So that can be things like, you know, Microsoft things like the graph or SharePoint or any of the other API endpoints that Microsoft provides or maybe your own API that you've defined and registered. So you can give that, say that this app has access to these APIs and which ones they have as a default. So there's more to that. Let's not go there. You can set up again that managed identity thing but for access to the app, you can specify whether, oh God, now I'm gonna forget all the stuff cause I'm trying to do it from memory, which is terrible. You can define what kind of authentication type. So the style, like- Which are, what's supported flows? Thank you. Which are all flows. Yes, thank you. That was what I was trying to come up with. The supported types of flows. So we can define all of that kind of stuff. So you defined your app. And the other thing that defining your app does is you're also gonna say one of three things. You're gonna say this app is for only things in my tenant, right? Or it's cross tenant. And I think there's a third thing. Multi-tenant. Multi-tenant, but there's- There's a personal one too. Personal, that's the other person. So it's like- Yeah, so the single tenant, just my company. Multi-tenant, I'm like an ISV building something and any company can use this app. Right. Including me. Or it's and or it's also available in a personal scope. So you could authenticate, not just the Azure AD identity, but you can authenticate with like a Microsoft account in a live.com or hotmail.com account. Right, that's the third one. So that's where you define everything. And then the thing that got confusing until I really realized that that was what it was for is that there's another section called enterprise apps. That's above it, because it's alphabetical. Not, it's verse alphabetical. Is enterprise apps. And enterprise apps are the service principles and a managed identity is a type of service principle. And this is where I was like, who, okay. And there's a couple other, like you have a user principle but that doesn't go, that's separate. That's AD, that's separate. So those are security principles as well, but not here. And this is like also like if you, if somebody else has a multi-tenant app that they've created, when you authorize, am I using the right word? When you authorize that app to have access to your tenant, that service principle for that gets created in the enterprise app. So that's where you find that. And that can also be, there can be legacy ones for like SAML tokens and stuff in there. There's like a lot of different uses for those things. The way, so the way that I understand this or the way I, the way this is explained to me, which is gels is that when you create an app, when you do an app registration, it is just like the definition. So think about that like old school. That's like when you create a workflow, you're creating a workflow, but by itself it's nothing. It just describes stuff. When you create, when you add that app to your tenant, which if you're doing single tenant, it's all happens at one time. If it's multi-tenant, you're basically saying, yes, I let this app actually do stuff inside my tenant. That's when it's creating an instance of that workflow in the app thing. We're creating an instance of that app registration. In my tenant. And if a single tenant, when I create the app registration, it creates the instance at the same time. So that's a real configuration. You can have a app registration without the instance, but it's useless. It's just a definition. Right, right, exactly. Yes, you did a much better job of explaining it. That's why you're the educator. Well, that's good. Somebody better be. Yeah, so that was the part that always messed me up for a little bit too and just trying to understand what our service principle is. And it's like, oh, it's service principle. So when I want to do like a managed identity, and I want to give like an Azure function the ability to have the reader RBAC role on a storage account, it's I just say like, create as a managed identity. And what that basically does is, I will create a service principle for that Azure function resource and give that resource. And the permission or the permission triangle, which is there's the thing at the top point. There's the permission that they're being granted. And then what are they being granted the permission to? So that thing is granted this permission on that thing. And so the service principle is the instance of that, like the configuration of all that. Right, right. It's the triangulation of that. And that is the powerful special sauce that allows you to just create a whole bunch of things in Azure and have them all have access to each other without you having to authenticate to each thing. And that is crazy powerful. And once I started doing that, I was like, oh, why haven't I done this forever? It's really, it's really cool. It's really, really cool. So I know we got a couple of things we want to run through and we're starting to get, we're starting to max out on our time that we've got. So why don't we do this? Why don't we do like a little rapid fire one or two things. And then what is something in Azure that you are interested in that you want to learn more, play more with? So rapid fire, like I think that we both have a couple of things on the same list, like CDN, a content delivery network. Huge, huge use case. App insights, we both use it. The only thing I wanted to say about that is if you have one of those, if you are very cost conscious, go and watch your costs when you have created your app insights because if you're really verbose in your use of app insights, the costs can go up a little bit. So you need to know what you're doing there. Sometimes I'll build something, be very verbose at the beginning while I'm debugging and making sure things are going well and have an app configuration that basically throttles my logging back for when I'm in production so that I can just move it back and forth. So I have all that verbose logging but I'm not gonna incur costs when I don't need to incur costs. So that's a good one. Yeah. Yeah, so I'm gonna put them all in the same thing is app insights slash Azure monitor slash log analytics because like Azure monitor is all of this telemetry kind of monitoring stuff. Log analytics, that's where all of your telemetry data goes. So you can do like direct queries against it using the Custo language or whatever. And then... Set up alerts. You can set up alerts with that which is very handy as a consultant. Well, that's an app insights though, right? No, it's the monitor. It's, well, you use a log analytics query to set up a monitoring thing and it'll send if you say if I've had X number of things that meet this query in certain amount of time send me an email with the details. So I use that a lot in my consulting world where I'll say I'll set these notifications up so that if something's going really wrong for a client with something that I've given them it's gonna start email me. So I know what's going on or SMS or whatever you want to use. So those are some big things there. Let me, okay. So then I think that's everything. Is there anything else we want to make touch on? I don't see anything. Oh, well, ACAs. Well, so that's the part where it's like what are you interested in? What do you want to play more? Oh, okay. So what do you have one on your list? I already said it that I wanted to start going instead of being stuck in my little path with .NET and C sharp. I'm gonna try to expand my horizons with doing Azure functions with like node and because it's not like I don't use it. I write types of all the time but you know. So the big one for me is around containers specifically it's container apps or Azure container apps. Otherwise known as ACAs. And that along with using it in conjunction with something called Dapper the distributed application platform runtime which is let you kind of run like a sidecar essentially it adds like an endpoints. If you create a container that's got a bunch of like endpoints in it to respond different requests you maybe have to do things like authentication. You also have to deal with things like how do I store stuff to a Azure storage or the SQL or the Cosmos, whatever. Dapper is a sidecar you can install so that you can go to the local host slash storage slot and then post something to that. And depending on what you've configured up with the Dapper sidecar it has like a standardized endpoint standardized protocol so that I can post data to that storage endpoint and how the Dapper sidecar is configured. It's either gonna send it to Azure storage or SQL or the Cosmos. So I don't have to worry about all these different languages. No, no, no, no. Oh, it's more than that because it's gonna do the it's gonna know how to talk to each of the other things. Yes. Got it. So it knows how to do PubSub and it can connect to PubSub with like PubSub is kind of standardized but the way you talk to RabbitMQ and the way you talk to like the Azure storage queues they use a different protocol, different stuff. If you talk to it through Dapper, it's one and I can just swap out the provider. It's like a provider model kind of thing. Oh, interesting, very cool. So the thing that I like about the container apps is that I love containers because I love the idea of that the way I run it I build it and run it on my laptop it's gonna run the exact same way in the cloud. No matter what it's the exact same full control over the environment all the way down to the OS level but not having to deal with all the details of a virtual machine. The thing that I like about Azure Container apps is that it's essentially Kubernetes without all of the other infrastructure that you have to learn to be able to run Kubernetes even though we have AKS I have to learn about all the stuff about networking and I have to learn about discovery service and all that stuff Dapper handles the discovery service so I can find, you know do I have another container somewhere in my environment that's running, I don't know, is my inventory service I can just say that that's the inventory service and go to Dapper and go go to the inventory service and Dapper's like, I know where that is, I got you. Oh, that's great. The thing that I like about the ACA stuff though is that it abstracts away a lot of the stuff that you have to do with Kubernetes but it's still Kubernetes. And so I don't have to be a Kubernetes person to be able to leverage Azure Container apps. And what I'm trying, what I'm starting to kind of get to play more with is using ACAs to strangle out my usage of Azure functions so that I'm starting to take some of the Azure functions that I've created and switch them over to being a bunch of microservices implemented using Azure Container apps. And I have a, you use API management resource to like let you go from api.voitanus.io slash whatever the endpoint is to point to a specific Azure function. So the goal is to stand up an Azure Container app with a bunch of microservices for that one endpoint and then just take the API management and say instead of pointing to Azure function now point to the Azure Container app. I gotcha, yeah, yeah, yeah. And I've got a specific business problem that it's actually gonna allow me to fix that can't do with Azure functions. And the reason I like that is because running Azure functions on your laptop versus running it in Azure is a different experience. It is a different, that is valid. That is very valid. But with Container apps is a hundred percent the exact same thing. Yeah, yeah. And if you've got a complex business problem to solve it may be the better way to go. Yeah, I mean, so here's a classic scenario where I can't solve something right now with Azure functions. I created this little service that allows me to pass in a value on the query string that generates a page, a webpage with a couple values in it. So it's how I do what are called open graph images. So when you paste a URL into Facebook or Twitter or whatever it shows you that big picture preview of it. So I dynamically generate those. The way I do that, pass in a URL, check to see if the image has already been generated. If not redirect to a page that uses CSS and everything to lay out how I want the image to look take the values out of the query string and plug them in for like the dynamic URL, the dynamic text and then the image that I want to use to show in that and the like the highlight thing. You look at any of my blog posts on Twitter you'll see they use that. The challenge and then I have to get a picture of it. So I use the headless version of Chrome to load that webpage, take a snapshot of it and save it as a PNG to Azure Storage. I gotcha. And then I return a 302 back to the requester of that image in the future. Check to see does the image exist? Yes, just redirect them to that. Don't read it during the image. Well, an update with puppeteer requires you to have a specific dependency installed if you're running on Linux. Can't do that. I can't do that because I can't change the runtime in the Azure function. Yeah, no, that's true. Yeah, but you can as a container because you can define your own. Yeah. Exactly. So that's the appeal of it. I played around with a little bit of it. I'm surprised at how easy and simple it is to spin this stuff up without all the overhead and the scariness of Kubernetes. So Azure Container apps, that's my hammer and I'm running around. Nailing everything. Just don't nail your shirt to a tree. Yeah, so my goal would be is that I would say that if I could snap my fingers, like give me two or three weeks and I can migrate my entire Azure function app that I have right now in my entire workflow over to a bunch of microservices all running in Azure Container apps. And it looks like I can do everything that I'm doing with Azure Container apps instead of using Azure functions and I can get out of Azure functions. It'll be interesting to see how your price comparison ends up being too. You know what I mean? That's a good point. That's a very good point. Like is it apples to apples? Is it more? Is it less? Be an interesting thing to know. Yeah, that's a good point. That's a good point. You do have more control over it but you also have less, but there's also more magic to it. So like with an Azure function, with a consumption model, you can scale down to zero. You can do the same thing with Azure Container apps but then with an Azure Container app, I could say you could scale down all the way down to one instance and spin up and scale up to a certain cap under these specific like heartbeat conditions. Sure, okay. Anyway, future episode. Yeah. All right. Well, I think that wraps it. We've gone a little long. So I think we should wrap it up. So what did you all think of this episode? Let us know by dropping a comment below in the comment section and hit the subscribe button. If you wanna be notified the next time we have an episode going out and you will be notified via that nice subscription feature that YouTube has. We'll see you next time on Cloud Dev Clarity. Thanks everybody. Thanks everybody.