The Magic of DAPR with Cecil Phillip - .NET 185

In this episode of Adventures in .NET we learn about DAPR and how it can make all of our lives easier. Maybe you like microservices or maybe you don’t, well DAPR is here to help with implementation and getting all the different parts of your application talking to each other.

Special Guests: Cecil Phillip

Show Notes

In this episode of Adventures in .NET we learn about DAPR and how it can make all of our lives easier. Maybe you like microservices or maybe you don’t, well DAPR is here to help with implementation and getting all the different parts of your application talking to each other.

Sponsors


Links


Picks

Transcript


Hello, and welcome to another episode of adventures in dot net. I'm Sean Klebbe, your host. And with me today are your cohost, Caleb Wells. Hey, y'all. Hey, y'all.

Don't blow away, Caleb. Stay with us. Oh, I'm here. I'm good. No.

I hope all the rest of the hurricanes throughout the season miss you as well. So Thank you. Thank you. Alright. We also got Wailu.

Howdy, Wai. Hey. Hello. Good. Good.

So and our guest today, special guest, Cecil Philip. Hi. Welcome, Cecil. Hi, everyone. Thank you for having me on.

Thanks for joining us. Definitely. Yeah. Thanks for joining. To get things started, why don't you tell us a little bit about yourself, Cecil, and how you got into programming and what you do now?

Sure. No problem. So originally, I'm from the Caribbean. I was born and raised in an island called Antigua. And you know, I lived there for about, I wanna say, the first, like, 19 years of my life.

But at that point, it was, you know, one day my dad, he brought a computer home. And, you know, this was a while ago. Right? This is when Compat Presarios and stuff like that were still, like, you know, the type of computers people were buying. I had one of them.

So Yeah. I mean, they were they were pretty I think they were pretty popular at that point. Right? A lot of folks were buying, like, Compaq, you know, branded comp computers. But, anyway, he brings his computer home.

And, you know, back then when you bought a computer, it came with, like, books. You know, you like a computer, and there's a stack of books, like manuals and all kinds of stuff. Like, this is how you do the thing. And inside one of those books was like a intro to computers, quote unquote. But it was really a book about, like, HTML and CSS and, you know, just random things you could do on a machine.

And I remember one summer I was, you know, I was just bored. I didn't have anything to do. So I started flipping through this book, and I'm like, oh, okay. It says type this thing in notepad and hit save and then double click on it. And so, you know, I did a stupid little thing, and then I put my name on the screen.

Now today, like, that's not, like, the most exciting thing to to do in software development, but for me, I was just like, yo. This is the most amazing thing in the world. So I'm going. I'm calling my friends on the phone, and I'm like, hey. Yo.

You need to come to the house. I just I just put my name on this computer thing. It's on the screen. Like, you need to see it. Like, it's crazy.

Right? But I think, like, that little moment for me was what it was. Right? Like, that was the switch that kinda, like, sparked my curiosity and kinda pushed me to go forward. Because, again, you know, when we think about what was going on at that particular time and also, you know, what was happening in the country that I was from, having computers in the house was not a common thing.

Never mind, you know, we we never had computer classes or computers at all in high school. Right? So this was this was just, like, a a completely foreign machine. Like, the only thing I knew you did on it was play solitaire because that's what my dad did all that. He played solitaire and he played minesweeper.

Right? And I was like, okay. Well, solitaire machine. But then, you know, over time, like, I saw, you know, little stores and shops start to open up in the country and folks were, like, fixing computers. And I was like, oh, well, maybe maybe I could do that.

Right? Like, maybe I could fix computers for a living. I could have, like, Sasa's computer shop, and that could be a thing that I do. So when it was time for me to leave to go to college, I was like, hey. Well, I wanna do computer stuff.

I wanna do computer science. I'm gonna learn how to fix machines, and then I'm gonna come home. And I'm gonna open a store or a shop or whatever the case is, I don't gotta do that. But, you know, just like in everything in life. Right?

Like, perspective is such an important thing, like, when you make decisions. And I say that because, you know, my perspective of computers and the industry and, like, what's possible was solely based on the people that were around me playing solitaire. Right? And the people that came to the house to fix the computer when, like, the printer wasn't working or, you know, our dial up was making not the right noise or whatever the case is. Right?

But now I I go to college and, you know, I got my first laptop, you know, so the first machine that actually belonged to me. And I started, you know, writing programs in, like, assembly and Java and c plus plus and, you know, I'm talking to these companies that come over to career fairs talking about, oh, well, you could do this thing and that thing. And, you know, I remember Microsoft was there and Corel was there. You know? This is gonna date me, but, like, Macromedia was there.

Like, all these different types of Don't worry about being dated. Caleb and I have taken work here that well well before you. We're we're we're all dated. Right. But these but these are the kind of people that were coming by, and they were showing us all the things that were possible.

And I'm like, you know, I had no idea. So you needed to tell me, like, I could leave, you know, where I'm from. I could come here in the United States and I could work for these companies and I could do these things and I could build software. Like, I don't have to, like, fix machines. I don't have to be someone's handyman and, you know, I could do more than that.

I didn't know that. So again, that's why I said, like, perspective is such an important thing. Right? And so, you know, with me moving from one place to another, like, my world kinda opened up a little bit more. And I was able to see more and understand more.

And so from that point, I was just like, well, let me let me see how far this thing can go. Alright. Let's just every time you set a goal, like, you kinda make new ones after you meet that one. Right? And so, you know, so it's so far it's worked out pretty well.

You know, today, I'm employed at Microsoft as a developer advocate. And I think a part of my job that I really enjoy the most is being able to turn on those light bulbs for other people. Right? Being able to give them that perspective and share that type of information that I might not have had, you know, again, just based on my surroundings and the environment and, you know, the things that were available around me. Cool.

That's awesome. Quick. I'll real quick, Cecil. I wanna let you know that your voice level changes quite a bit depending on if you're speaking at the mic or not. So I'm gonna try and not move.

Okay. There There we go. Alright. So do you think you're still interested in opening up a shop, or are you good now at Microsoft? You know, I definitely don't think I'm gonna try and fix computers for a living.

For sure. Like, that's definitely not that's definitely not a goal of mine anymore. But, you know, I am definitely always interested in in trying to help other folks learn not only just the business of computing, but, you know, like the economics of it. Like how can it help you and your environment, like your country, you know, like make the lives of other people a lot better. Right?

And I think those for me are, like, some of the most rewarding things that we could do, particularly after you've been in the industry for a little bit. You know? So I'm I'm I'm in the industry about 10 years now. So I've I've worked in corporate. I've worked in small companies and big companies.

You know, I've built products, and now I'm kind of, you know, doing education as an advocate. And for me, like, at this point in my career, I wanna say I've felt most fulfilled. Because, you know, being able to help folks do types of things are really interesting. And so I think if I was ever supposed to believe and do something different, it'll probably be something along those types of lives. Whether it's opening up some type of educational company or a system or mentorship type program to be able to help other people, you know, understand the capabilities and what's possible in the industry.

I think that really, I think that that multiply effect is what draws a lot of developers into the passion of IT. The fact that Yeah. What they can do can can make multitude of difference to other people's lives, whether that's good or bad. Well, it definitely does. I think what's important too is is it important for for new folks to always feel like there's someone there that they could talk to from a very fundamental level.

Right? Mhmm. Regardless of whether you're talking about high school folks or, you know, older folks that are transitioning over to different careers, it's it's always important for for me and for them and for all of us to be able to say, hey, I I have a problem and I could reach out to this person or these people to kinda help me with it. And, you know, those are the conversations that kinda drive the industry when you think about it. Right?

So imagine this. I want to I wanna be start a start up. Right? I know I need technology, I need programmers, and I need all these types of stuff. Probably the first thing I'm gonna do is be like, hey.

Do I have any friends that have start ups? And then one of you gonna say yes. Akeel is gonna say yes. Sure. I use, you know, I use AWS, and I use Python, and I use Go, and da da da da, whatever whatever.

And I'm gonna be like, you know what? I'm gonna do that too. Because I know Caleb, and Caleb is using things, and it's, you know, he's obviously done it longer than I have and it's working for him. Now I have someone that I could talk to and ask the question. Right?

Which is very different from, like, a book or a Pluralsight video or, like, a YouTube thing. Right? Like, there's a person, and there's a relationship with that person. And so but now, like, that conversation has just influenced some of my technology decisions. Obviously, as companies grow and evolve, like, things change.

But, like, that initial conversation is gonna be like, hey. If I need help, can I talk to you about it? Hopefully, you'll say yes. Hopefully, we're good enough friends and he won't turn me down. Hopefully, we we'll be okay.

But that initial conversation is gonna be like, okay. I I see you doing it and you're being successful. Now let me see if I could do that with whatever my particular focus happens to be. So how long you've been at Microsoft? It's about about 3 years now, actually.

July 2020 made 3 years. It's funny. I was just talking to someone about it today. And, you know, when you think about time, right, like, I never I don't know. I had no idea how much time had passed.

Right? It doesn't feel like 3 years at all. Mainly, it's because it feels like we just have so much more work we gotta get done and so many more interesting things that we could work on. But it's been 3 3 really interesting years. Like, I've been on the developer advocacy team this entire time.

If you're if your folks aren't familiar with our what our team does, we focus on essentially developer experiences. Right? We try to make sure that whether you're a startup or a student or enterprise, you know, whether you're doing open source stuff, whether you're using dot net or Python or Java or whatever the case is, you know, whatever whatever platform, whatever programming language, we wanna make sure that you have a really good experience using our tools and services. And so a part of that has to do with us, you know, getting that feedback and bringing that back into the product team, and then also bringing you know, taking some of those new features and those changes that we we our team created, and then bringing them back up into the ecosystem to be like, well, you know, you said you wanted us to do this thing and we've done it, you know. Let us know what you think about it.

Let us know if this solves your problem. I think it must be so exciting to be in the develop accuracy team in Microsoft right now compared to I mean, just compared to what seeing what Microsoft has done in the last couple of years, you know, that shift towards Azure and open source tools and, you know, they they become a much more developer friendly company these days. Yeah. I wanna say well, I wasn't at Microsoft prior to prior to Satya. But, you know, I could say from from what I've seen from the outside and what I've seen now that I'm on the inside, it's it's really great to be surrounded by such a diverse group of folks with different perspectives on technology.

And so when I say that, what do I mean? Like, our particular team, just as an example, you know, we have folks that are heavily rooted in the Java community, on the Go community, and the JavaScript community, and also obviously the dot net community. But a lot of these folks wouldn't wouldn't be categorized as quote, unquote Microsoft folks. Right? They'd be like, oh, Microsoft.

I don't wanna work there. They're not doing anything interesting or anything that I necessarily care about. And I also don't feel like Microsoft cares about my community. But you can see today, like, the state of the world is a lot different. Right?

At least when it comes from Microsoft and and how they choose to interact with developers and how we choose to support developers. And so now being in a team with all of these different folks, the conversations are so interesting. Right? Because now, you know, there's so many different ways to solve a problem. Right?

And sometimes too, like, the way you solve the problem is based on the context. Right? Well, hey. Am I using this framework or that framework? Or, like, what type of support is for this protocol over here or there?

Or maybe can we put 2 things together and make something new and different. Right? And so that's one of the things I'm really grateful for is to be able to collaborate with all these different folks in the team. Again, folks that I probably never would have worked with or, you know, gone to the same conferences as or met online, and then really just be able to share those types of experiences with everyone. I grew up about 25 20, 25 miles out of side of Redmond in the mid eighties, so I've really seen Microsoft since the beginning.

And I remember the day they went public, and I'm just really sorry I didn't buy any stock then. But but I really like the Microsoft of today. You know, seeing all the different phases that it's gone through, I really like what they're doing, being a lot more transparent, really open, really trying to support all the different types of communities, not just the Microsoft community, you know, what was typical so called, you know, the Microsoft community. They're Yeah. You know, now they're supporting Linux, Mac, everything.

They all the cloud, everything. So they really want to make everybody as happy as they can. Right. I think one of the things you'll well, we could probably all agree on is that to be successful in technology, you you have to be open to everyone and every possibility. Right?

Whether that means, like, differences of mobile phone operating systems, whether that's differences of, you know, desktop computing operating systems or, you know, differences in terms of, you know, how I choose to use the Internet. Right? Like, we have to think about all these different things and and see, well, if we wanna be successful as as any tech company, like, we have to be able to engage and work with customers and and and people wherever they happen to be. Right? So, you know, some of you all might be writing c plus plus or an assembly language.

Right? You know, some of us might be writing some other things like Haskell and Go and, you know, Python and c sharp. Like, there's so many different things there. So, like, how do you how do you create an ecosystem that kinda supports all of that? Right?

And then also make them feel like, hey, I don't have to change who I am as a developer to be able to play the game. Right? Like, we want everyone to have the same fear chance to come in and and be a part of what's happening today. Yeah. When I was at Microsoft Ignite, yeah, last last year, you know, a big emphasis and theme was on inclusion, you know, personal inclusion of all different people.

And I really think that's a a good way to go. It's no matter who you are, if you wanna be a developer, the system should be open for you and support you and and wanna enable you to make whatever you, you know, see yourself building. Yeah. I think that topic of inclusion is such such an important one for a lot of us to talk about, And it's really good to see the amount of of tangible evidence from Microsoft in terms of how they're choosing to actually make progress, how they're choosing to listen, you know, and how they're choosing to support a lot of folks when it comes to diversity and inclusion. You know, we we see very often all the time from different industries and different companies, you know, when something happens, then all of a sudden people are very much in support of whatever the trending thing happens to be.

And then it's not trending anymore, then we don't hear from them again. Right? And that's that's that's very common. You know, one of the things I'm definitely proud about is the consistency that comes through Microsoft. And and I think maybe too because I'm internal, I could see a lot more of it.

But just because, you know, a certain topic or a certain issue socially is not trending anymore, doesn't mean, like, we forget about it. Because for some of us, that's our life every day, day to day. And, you know, when you think about, you know, walking into a room and being able to see people that are like you, or, you know, they're from the same place that you're come from, or, you know, they've had similar experiences that you have. And being able to see, like, even a mixing pot of that type of team or that type of company, like, it it does something for you from a morale perspective, right, and from a trust perspective. And now when we think about building teams, right, from a a perspective of longevity, right, like, that's how that's how your employees are gonna stay with you because you have to build that trust and that faith to make them feel like, hey.

You're you belong here, and I want you to be comfortable here, and I want you to succeed here. You know, this really does kind of lead into our topic today, dapper, because, right, it's it is inclusive of multiple programming languages and frameworks and stacks. And I've watched I watched your video and a couple of things. We'll add to the show notes, but really interesting framework. Can you tell us a little little more about that and how you got involved with it?

Sure. I'm really excited about the Dapr project. So for folks that are listening and might not know, so Dapr, d a p r, stands for distributed application runtime. And what it is or what are the main goals of Dapr is to make it easier to build microservice like, you know, cloud native, you know, distributed systems applications. Right?

And so so what does that mean? Like, how do I do that? When you look across the gambit of, you know, what we consider to be, like, the microservice ecosystem, like, there's a lot of stuff in there. Right? Like, you'll hear folks mention Kubernetes and Istio and Helm and Prometheus and stuff.

Right? Like, you just keep hearing different names thrown out at you. And, you know, when your boss comes to you and say, hey. We wanna start looking at this microservice pattern or architecture. Now you're gonna be like, oh my gosh.

Like, who am I supposed to get started? Like, there's so many different names and so many different technologies that I have to kinda piece together to kinda play in that world. Right? And it's intimidating. Right?

It's stressful and it's a little intimidating because you don't know where to start. Like, what's the first puzzle piece? I'm like, where do I get the rest of them? And one of the things Dapr does is it tries to make that easier for you by creating, like, an extraction around some of the more common patterns around building microservices or around building distributed applications. So when you think about a distributed app, like, what are some of the main problems that you might have?

Right? Like, I have one or many services, and then I have one or many instances of those services. How do I know where they like, what's the location? Right? How do I how do I share configuration across all these services?

How do I share security settings and those types of things across all the services? How do I wire up things like messaging and do distribution distributed tracing and like, there's a lot there. Right? And that's when we start our reach for, like, these different puzzle pieces to try and piece them together. But what Dappar does is well, they're like, okay.

Well, we'll we'll work out the the integration part of a lot of those those building blocks. And then all you have to do is figure out, well, what are the pieces that you wanna use? And then, you know, once you add this connected to Dapr, Dapr will kinda just make that happen. So so that's a very high level example. If we talk about some of the very specific ones, Dapr offers things like, you know, publish subscribe because when you think about building distributed apps and messaging, messaging is a huge event.

So it offers a publish subscribe building block and component. It offers distributed tracing, and it supports the OpenTelemetry standard, which is pretty cool. You know, it also supports service discovery and service implication. So, again, using service discovery, I don't have to know where my service is. Dapper knows where it is.

All I have to say is, hey. Do you have a service that could do this thing? Here's the payload. Could you let me know when it's done? Right?

And then Dacker will be responsible for finding the service, poking the service, and returning those results to you, which which is great. You know, things like caching or, you know, distributed state stores. You know, things like actors. Like, all these different types of components where usually it has to go out and okay. Well, I need to pull in Redis.

But not only do I have to pull in Redis, I gotta find the Redis SDK. Okay. Now I need to find RabbitMQ because I wanna do messaging. But I gotta set up Rabbit, and I gotta pull in the SDK into my particular applications. Maybe I'm doing Python or dot net.

Like, what does their SDK look like, and how do I wire that up? I don't really wanna do all of that. Right? And then what happens if something, you know, something happens and I need to change the component? Like, what if I need to change the provider I'm using for caching?

Right? What if I need to change the provider I'm using for services scrubber? Now that that's a nontrivial change to make. Right? Because now I have to go and uninstall all these packages and SDKs from my respective applications.

I gotta, you know, I gotta redo the whatever the new thing is, and then I have to push that update across all of my services, across my cluster, wherever it is that they happen to be. With Dapr now, it becomes so much easier now because it's it's more so of, hey. I'm gonna change a configuration. Right? My configuration might points to my point to Cosmos DB and application insights.

So it might points to something like a Zipkin or, you know, some other component in the ecosystem. But from the perspective of my application, I don't really I don't really know about that. I just know that, hey. Dapper, can you store state? Yes.

Here you go. Some state. Could you store that for a bit? Hey, Dapper. Could could you tell me if you have a service that does this?

Yes. Here you go. Here's my payload. Dapper, can you do PubSub? Yes.

Here you go. Here's, like, a message. Could you publish this on the queue or through the message bus and figure that out? So when you think about now from a deployments and updating perspective, it makes your life a little bit easier. Right?

Because now there's less change to your code that you have to manage. Right? And then also too, like, it allows you to play in that ecosystem where I could kinda, you know, pull in and pull out, you know, swap in and swap out different components without changing my application. And so now I can experiment with that world and see how things work and see what's the best fit for me. And then, you know, realize whether it's today or 2 years from now, I could very easily change out those components to suit my need at the time.

So would you say that it's similar would would it be similar to something like is it is it a framework that essentially allows you to decouple your each component inside a distributed application so that it's it works independently, and then you can handle all the integration for you? Yeah. So dapper so if you're familiar with the sidecar pattern, dapper essentially implements itself as a sidecar. Yeah. On the So we we might be familiar with the sidecar, but some of our audience may not be.

So why don't you explain a little bit about what that is? Sure. Sure. So with with the sidecar pattern, what happens is you whenever you deploy your application, you'll probably have, like, another host process or another thing that's running right next to it. And instead of communicating with other things on the network directly, you can instead just communicate with the sidecar.

And so whatever's inside of that that process or that code or or that service that's running, it will be able to talk to some of the other ones that are on the network. It might be on, you know, on the same network, on different machines, they might be across the cloud, on different hosts, on different places. But essentially, you know, your sidecar is gonna be responsible for, like, those pieces of functionality that you might wanna make use of. So now from your app's perspective, like, you're always on local host. You're always communicating on local host.

You're always doing stuff that's right here. But instead of, again, like, pulling in different services and components and different packages or whatever, I just have to figure out, hey. Is Dapr running, like, right next to me? Like, literally right next to you on the same box. Like, is Dapr here?

Yes. It's here. And then once I connect to it, now I have access to whatever else is on that cluster of connected nodes or Dapr. Right? So, again, like, the great thing about that sidecar pattern, again, is because, hey.

I don't need to know about too much about, like, the network topology. I don't have to worry too much about firewalls and, you know, passwords and those types of things from my applications perspective. Instead, I can just talk to, like, the service that's running on the machine right next to me, and I could talk to that instead. And then that will be able to do some of that mediation of all these other services and building blocks and stuff. How does Dapr integrate these services?

Is it container based? And what do you need to do to get Dapr up and running on your machine? Is it a nougat package? Or or what are the steps? Sure.

That's a really great question, and it's one of the things that I, like, I'm really passionate about. From a perspective of, dapper should be able to run wherever your application is. So what does that mean? That means that if you're using containers or not, you could still use Dapr. Whether you're running in a virtual machine or not, you could still use Dapr.

Whether you're in Kubernetes or not, you could still use Dapr. All it is today is just an executable. So if you're running on Linux or or OSX, you could install it via homebrew or package manager of your native OS, whatever it hap wherever it happens to be. You could pull it down directly from GitHub. All the releases are on GitHub, and, you know, Dapr is also open source, so you could always check that out as well.

But it's it's just a very lightweight executable. So you, you know, you download Dapr, you, you know, you dapr run and you pass it a set of configuration files, or you point it at a folder and maybe that folder has, like, a collection of configuration files for different components that you wanna use. And then and then that's it. Then you just start talking to it locally, like, on that same machine. So in terms of how you configure it or set set it up, now it supports, like I mentioned, some of these different building blocks.

And those building blocks are essentially, like, the actual implementations of those patterns that I talked about. So, again, if we wanna talk about PubSub, my PubSub might be backed by Azure Service Plus. You might be backed by RabbitMQ. You might be backed by Redis. Right?

From the perspective of my application, again, I don't care. I just talk to Dapr. But from the Dapr perspective, like, when I run it, I need to pass it a selection of configuration files. And, usually, Dapr is configured using YAML. I know different people have different opinions about YAML, but, you know, that's just the state of the world.

We have to use YAML. So you pass it a set of YAML configuration files, and you essentially say, dapper, I have a a state thing or a PubSub thing or a metrics thing. And here is the here are the credentials for it. Here is the host where it lives. And go go ahead.

Go for it. Right? And just it'll just it'll just set it up for you. But even from that perspective, you don't have to write any source code per se. Like, you have to do some configuration, of course.

There's YAML files to write and whatnot. But there's no code for you to write in terms of integrating those pieces together. The the components are written in a way that they know how to set themselves up in those respective services. So, again, I'm gonna use RabbitMQ again as another example. So if you're familiar with RabbitMQ, which is a a service broker or a messaging service, you know, right, RabbitMQ, you have the concept of queues, you have exchanges, and you have connections.

Once I set that stuff up inside of dapr, it'll go ahead and create those things for me inside of RabbitMQ, and my app can make use of them through dapr, but, like, I don't ever have to manage those. Right? I don't have to make sure that, you know, the exchange is connected to the right queue. I don't have to make sure that's using the right you know, whether I'm using fan out or, you know, you know, a direct exchange or anything like that. Like, Dapr will just do that for me.

And, you know, we adjust as it spins up. When the application spins back down, it'll clean up all of those, you know, all those artifacts that are created so that it still keeps your system fairly clean. And, again, it does this for everything else it supports. Right? I believe there's also support for GCP Pub Sub, the Google the Google one.

It supports SQS from Amazon. It supports, like, an Azure Service Bus, ActiveMQ, RabbitMQ. Like, it supports a lot of these different things, which is great because I know one of the big questions folks always ask me is, hey. If I'm using a thing in the cloud, but I wanna test locally, like, how can I do that? I was like, wow.

That's hard. Right? Like, because not everything in the cloud has, like, a local version of it. And so one of the use cases that I like to use is okay. Well, let's say you wanna I keep talking about queues because that's the one that we use the most.

But let's say you wanted to do a a distributed metrics thing. Right? Like, so you wanted to use something like Azure application insights to keep my logs and metrics and all these types of things. But what if I'm not connected to the cloud? What if I wanted to use something else like Grafana or Elasticsearch or something else to capture my logs and and do some of that?

Well, instead of me changing my code, I could just point Dapr to something else that runs locally. And then I could run-in and test it on my machine or, you know, a VM or whatever the case is to make sure that that scenario works. And now whenever I deploy, the only thing I really need to think deeply about is how do I change the dapper configuration to point to something else. But, again, that's not a source code change in my application. That's that's me messing around with YAML and trying to not make mistakes to try and make sure that it works the right way.

All this sounds, almost too good to be true. Yeah. I mean, I I thought it was. Yeah. I thought it was too.

I was like, because this could this really work? But, you know, I'm I'm a curious person, and so I I spent some time kinda digging through their source code repository. I mean, all again, all these components that I'm talking about are free and available, at least from the dapper perspective. And you could just go on GitHub and look at it, and you could see exactly, like, how component is implemented. You could see just exactly how the configuration works and, you know, there's documentation, there's samples.

And so it I mean, it it I mean, the proof is in the pudding. Right? Like, I just recommend everyone go ahead and try it out. Right. You know?

And I know they're adding new things to it all the time. So, you know, you might go check it out tomorrow and see that there's some new building blocks and new components that are in there. So when somebody gets started with Dapr, what's kind of a first thing that they should build to kill just as as a proof of concept and to get to get familiar with how to, you know, use Dapr? Sure. So, usually, when you're you're building a distributed app, right, and you wanna use Dapr, I would I would look and see which one of the components makes sense for your use case.

Right? So let's say you had a a store. Right? You had a online ecommerce store, which is, you know, usually a pretty common use case for distributed applications. Now I might have a, like, a checkout queue.

I might have a pub sub queue that does, like, order processing or something like that. And you might decide, okay. Well, that's the part of my application that I wanna start with. Right? And I know Dapr supports PubSub.

Or, you know, maybe again you wanted to do distributed logging and tracing and your app is already split out into multiple components, but you don't really have a good way of doing that. Right? So, again, like, I'd say whatever whichever one of the components makes the most sense for you, like, I'd reach for that first and, like, let's do, like, some little first, like, some little proof of concepts to see if that works and if that makes sense. I know when I first started, one of the components that I reached for first was service discovery. Because for me, that was that was important for a demo that I was working on.

And in the past, I've used things like HashiCorp console for my service discovery. And, you know, I'm a big fan of the HashiCorp family of tools. And but I was like, I just wanna do something simple. Like, I just wanna, you know, I just wanna spin up a thing and be able to call another service that lives in another place without having hard coded URLs all over my code or something like that. And so when I I reached out for it and, like, you know, like I said before, like, all I have to do is, like, just do dapper run and say, hey, dapper.

I have an app running on local host port 80 or local host port 8,000. Right? And Dapr actually listens to the port, and he's like, okay. A service is running now on this port. Anyone that asks for a product service or a checkout service right?

Like, once you ask me for it, I'll route you to this machine to that particular application. I will just do it for you, which is, I think, is pretty amazing. Alright. Your example of of a store and, you know, handing things off to a store kinda reminds me of our our last show where we actually talked about Orleans. You know what how Orleans compares to Dapr and which would be better for what?

Sure. So Orleans so for folks that may or may not have listened to that that last episode, and and I always recommend you do that, Orleans is a dotnets project. Right? So that means that it is a dotnetsdll or a dotnetnougat package that you install in your dotnet applications. And so with that, you know, there's good and bad that comes with that.

Right? The good part of it is, obviously, it's dotnet. And if you're a dotnet developer, that plugs into, like, your whole ecosystem of tools and things that you're already familiar with. Dapr now is just a process. It's a it's an executable that you run, and you can run it on any operating system.

You can run it on any cloud, but it's not language specific. Right? It's not language specific, and one, it's not inside of your application. Right? So the difference with that is now dapr runs as a second part to your app.

So that means that if you have a checkout service, you're gonna have a checkout's dapper thing running next to it as a sidecar. Right? If you have a inventory service, you're gonna have a check a inventory dapper thing, like, running right next to you as a sidecar. But it's not in your code. It's not a package, which means that now in terms of how you interact with it, it's very different.

Orleans, like I said before, Orleans specifically is an actor framework. It is a NuGet pack dot net specific thing that's in your app. So in the case that you're you know, I know a lot of big companies use more than one programming language. As much as we'd love everyone to just use dotnet, that's not the case. But, you know, most companies that I talk to use dotnetandsomething.

Right? Like, it's dotnet and Python or dotnet and Java. Right? So now the thing with if you're using Orleans, you could only really use Orleans for your dotnet things. Right?

If you wanted to come to include those in, like, your Python projects and your Java projects and whatever other things you had inside of your environment, you you wouldn't be able to do that. Right? Because it's not it's that's not what it's made for. Right? Dapr, on the other hand, again, since it's just a process, and, you know, you communicate with it just via HTTP.

So if you have any application that any platform that speaks HTTP, you could use Dapr versus, again, having to be a package I have to install and version and and also deploy alongside my code too whenever that thing changes. How does how does Dapr handle your, app security? Because you mentioned, right, in in the case of your separate app, you're not having to do magic strings or worry about about that information inside your actual application. How does it manage that? Sure.

So there's there's a few different components when it comes to security with Dapr. So first of all, by default, when you're running Dapr in production, it uses mTLS. Right? So from that perspective already, like, when your application is communicating with that sidecar, there's already, like, a trusted layer of communication that's happening there. And just in the same way too as Dapr, the side your sidecar talking to other sidecars that might be connected to other instances or services or other different types of services.

All that is happening over m t I s internally also to our u I believe they use gRPC, which runs over HTTP 2. And so those communications across the network are also secure by default, you know, using MCLS and and, you know, that communication. Now in terms of your app itself, now you might have a situation where you have API keys. You might have different types of secrets and configuration matter that again, we don't wanna have that type of stuff checked into our code and we're referencing GitHub and those types of things. And this is when we reach for external systems like, again, HashiCorp Key Vault or Azure Key Vault to be able to store those in a very secure way.

But, again, very similar to, like, some of those other scenarios I mentioned, you know, What if, you know, what if I just wanna be able to use these things in a very loose way? I don't wanna bring in packages and, you know, dependencies on these very specific implementations of secrets management. What if I just wanna say, hey. Do you have, like, the password for this thing? Hey.

Do you have, like, the token for this API? Whatever the case is. I just wanna ask for stuff, and I have you give it to me. And so dapper as its own component supports doing key stores. So again, like, I can I can have a key store as a component configured in my YAML file, and I can have that point to, you know, all one of the different providers that Dapr supports out of the box?

So again, like, we could use Azure Key Vault or we could use HashiCorp Vault or and we can even use a local key store, which is available too. Now now the local key store is only for testing and development. So just FYI, like, for folks there that are listening, that's kinda like the in memory database that you have if any of the framework that people put it in production, but it's only there for testing. Right? Right.

Yeah. Don't don't don't do that in production. Yeah. Let's let's not do that. Those are testing things.

But but, again, like, you have those options that are available to you in terms of being able to secure your your secret matter. Right? And being able to access them in a very secure way. And again, not have to worry about having that type of information embedded inside of your source code. So what what does real world applications today that are that are using DAPL?

The mainly for internal apps or internal Microsoft apps or have external companies been using it? Yeah. We do have external companies using Dapr. I don't think I'm at liberty to, like, start calling names about it. But, yeah, we do have internal and external folks that are using Dapr.

And not just in a in a lightweight, in a very heavy production grade type way. And, I mean, that's that's always one of the huge benefits of of running things in a open source way and and being able to work with great partners is now that we're able to get actual real time and real world feedback about, like, you know, is this thing really battle tested? Can I really run this again in a Kubernetes situation or in a just a raw virtual machine situation or, you know, Does it really support all the scenarios that we're talking about? And so, you know, being able to have customers internally and externally that help us do that is is huge. And, hopefully, after listening to this podcast, one of y'all Right.

One of the folks that are listening will try it out too and send us some feedback. Go and create issues inside of the GitHub repo and let us know what exactly you think about. Yeah. We're adding also some links to the show notes for anybody that wants to get to some of the information about dapr or mTLS or anything like that. So definitely take a check out the show notes.

Yeah. Does does Dapr work with the majority of Azure functionality or offerings? Like, you you mentioned Kubernetes, but what about Azure functions, Something along those lines. Yeah. Yeah.

That's a great question. Recently, there there's a product that spun up. I wanna say recently. I wanna say maybe, like, a little bit over a month ago or so. There is a new extension to Dapr that supports Azure functions as well.

So if you wanna use the Azure functions programming model, and for folks that don't know, you know, Azure functions also runs everywhere. You can run it in the cloud, and you can also run Azure functions locally or in containers if you wanted to. It does support doing connecting to Azure functions to invoke, you know, HTTP methods and and other types of triggers and things of that nature with Azure functions. So that's one integration, like, one native integration with a very specific service. And as of more recently, there's actually support for doing workflows with Azure Logic Apps.

So you can actually run Azure Logic Apps. This might be another thing that folks don't know. You can run Azure Logic Apps outside of the cloud. And so now there's a a project underway to be able to run Logic Apps within a dapper service, like, embedded within a dapper service. And now, you know, you just like you do in Logic Apps, you define, like, whatever your workflow steps happens to be.

Like, I do this thing, then it does this thing, then it does this thing, you know, one after the other in a sequential way. And, you know, Dapr could be the thing that's in front of that that will help you manage it, invoke it, and help you integrate that into your system. So those are some of the 2 more recent ones. I mentioned application insights a little little bit early in the conversation for logging, so that's another thing that we support. You know, Azure service bus support is there.

SQL server support is there and and Mongo not Mongo. Cosmos DB. I'm gonna get in trouble because I said Mongo. No. You're good.

Cosmos Cosmos DB for, for state storage. And, again, like, as as more oh, and of Azure Key Vault, I mentioned that a little while too. So, yeah, there's a lot of supports for the the the Azure the Azure pairings for those different building blocks that Dapr supports. Great. Seems one of the biggest advantages of Dapr is, I guess, that I guess the folks who wanna avoid that that vendor lock in, isn't it?

Like like like you said, you can you can use Mongo if you want to. But if you if you decide that later on you don't wanna use Mongo anymore, you wanted to use Cosmos DB or another another no SQL solution, you can just you can just change configuration. Yeah. When you think about when you think about the culture behind microservices right? So now this kinda goes a little bit beyond just talking about, like, the the technical, you know, bits about it.

When you think about just the culture of adopting microservices, it it's the ability for you to be able to be wherever you need to be and do the work that you wanna do using the tools that you wanna use. Right? So it's ultimate flexibility. Obviously done within the right way. Right?

Like, let's not have, like, one of everything everywhere. But within within the right context is essentially it allows you to use the right tool for the job and hosts wherever it is that you see fit. Right? That's that's one of the once one of the benefits you get out of microservices. But I think also with choice becomes a lot of confusion.

Right? Because when there's choice, there's the, oh, man. Like, I have all this choice now. Like, there's 10 different ways to do x. Which one of these am I gonna choose?

Like, how do I do that? And then not only how do I pick it, after I pick it, how do I integrate it? Right? And then what happens when you change your mind and you're like, oh, man. I don't really like this.

I wanna do something different. Well, what what does change mean? Right? And what does the technical depth of that look like? Right?

Like, what does the timeline for your teams look like in terms of the work that needs to be done to make that update? And and again with Dapr, at least with the building blocks it supports, it makes that life a lot easier, and it makes it easier for everyone. Again, not just folks that are running on one particular language or one particular cloud. You could write whatever you wanna write. You could host wherever you wanna host.

Again, you could you could fully be in that culture of distributed applications, distributed teams, and distributed services using the right tool for the job, and then Dapr just makes it easier for you because you think a lot less about the details of implementing and more so how do I use, like, that service. Crickets. Crickets. Screens. Mhmm.

But yeah. But so I love Dapper, man. I mean, it's it's been a great product to to play around with. One of the things that I'm excited about going forward is, you know, when I first started using Dapper, it was purely by HTTP. I was just like, okay.

That's great. I don't have to learn another thing. I don't have to install, like, a dapper SDK or whatever the case is. It's HTTP, gRPC, and I could go. So when you think about it, any language that speaks HTTP, which is technically all of them.

I don't know about assembly language, but but technically all of those. I could I could be able to play in this world. But but even though you have that supports, you know, that's that's still more code that you have to write. And so one of the things that I'm interested in seeing and I know the team is working on is more native integrations to a lot of other platforms and tools. So, you know, you could definitely look forward since sometime in the future to seeing, like, a dotnetcore/asp.netcoreintegrationpackage that makes the the the the integration into Dapr a little bit easier.

I know, you know, folks in the Python space is gonna be a Python SDK and a Go SDK. Again, just to make things a little bit easier in terms of, like, wiring those up. And again, like, you know, the code that you don't have to write is the best code. Right? It's like because there's less code that you have to maintain in version and things of that nature.

So, you know, as we as we move forward to that point, you know, I think these integrations are just gonna make it make it more accessible to everyone that are like, hey. I really wanted to get into this microservice thing, but it's scary. It's scary and then there's a lot there and I don't know where to start and, like, I have to learn so much. I can tell you from a learning perspective, Dapr you could you could pick up Dapr in maybe half an hour. Right?

And a half an hour is probably gonna be you reading, doing a lot of reading and going through the docs just to understand what's there. But then once you get it, you're just like, okay. Cool. I just run this command and then now the onus is on you to build the service or the tool that's gonna consume that thing. Right?

Which is the code that you'd probably be writing anyway. And so, you know, those those scenarios that make it easier for you to get into the system and make use of the architecture without having to buy into a particular platform or or framework, I think, is huge. Right? You know, folks follow me on Twitter. You might see me rant a little bit about the difficulty of using Kubernetes or the difficulty of using orchestrators.

You know? I'm I'm a fan of orchestrators. I believe that they're great. I think some of the more common ones are super hard for for developers to get into, for beginners to get into. Like, there's a lot of time that needs to be invested in terms of, like, understanding how to even set it up.

Never mind, like, run on it. Versus like, hey. Well, what if what if what if I wanna have a micro microservice? Right? Like, what if I have microservices, but, like, I don't have, like, 200 services or I don't have, like, you know, a huge thing.

What if I have 3 services and I just wanna scale those 3 services independently? Right? You know, me moving to some of these larger larger orchestrators is a little bit of a overkill. Like, it's it's too much. Right?

But I think with things like Dapr and and, you know, some of the other tools that you'll see come out, you know, going through into next year, you know, the focus is really on making it easier for folks to be able to leverage the patterns, making easier for you to pick the patterns too that you choose. Right? Because I think a lot of folks also believe that, hey. If I'm a microservice distributed app, I have to use all the things, and that's not the case at all. Right?

Like, you can pick and choose what makes sense for you. You could pick and choose where you wanna host it, how you wanna run it. And, you know, hopefully, Dapper would be, like, one of those things that makes that that decision and then that's, you know, that process way easier for you going forward. Yeah. So is there anything that we haven't asked about that our listeners should know?

I don't think so. You know, one of the things with with Dapr, I always say is, you know, the best thing to do is to just try it. You know? Just try it. Again, it's open source.

You know? The the team does a great job in terms of, like, listening to feedback and also making sure that they're available to have those types of conversations. You know, they're, you know, they're on Twitter. They have a website. There's a Gitter channel.

So Gitter, if folks aren't familiar, is kinda like a chat room that's associated with a repo, which I think is pretty cool. So, you know, there's a lot of folks that are in the Gitter chat room just talking about Dapr all the time. And, you know, sometimes that's folks from the team, sometimes that's folks from different parts of the world. And everyone has different issues and problems. Everyone's using different languages.

And seeing everyone be there to support each other and answer questions, that's it's it's the best, like, it's the best, like, troubleshooting environment, from my perspective. You know, usually what I'll do is, like, I'll go into the GitHub channel before I go on, like, you know, search through the issues and things of that nature because the responses are really quick, and then, you know, it's it's, you know, it's more interactive from that way. The team also does a I think it's a biweekly call, which is which is great. So the call is live. It's it's through Zoom, but they also do it live and they host them on YouTube.

So and they talk about all the new cool features and things that they're working on as they work up to dapr 1.0. Right? So as as of today, as of the time of this recording, I think dapr is 0.10. So it's not 1.0 yet. So as you can imagine, there's still, you know, breaking changes are still happening, you know, new features are still happening, You know, again, those different SDKs and integrations, new ones are being made all the time.

But, you know, if you wanna be a part of the conversation now, if you wanna influence the open source project today, you know, if you wanna be able to say, hey. Well, hey. Well, I told them to add this feature and they added it, and now, like, it is forever ingrained in, like, you know, the DNA of Dappr. Right? Like, now would be the time for you to jump in and help out.

And, you know, sometimes that could be just helping out with docs and samples or sometimes it's, you know, suggesting new features or implementing new features. Sometimes it's testing out existing features to be like, hey. Well, it works in this scenario, but it doesn't in this one. Would you consider, you know, doing something additional? Right?

Like, being able to have those conversations are really important. Particularly since the product is so young. Because, you know, as software developers, we know, if we don't change it now, probably not gonna get changed later. To be we talk about it, but it's probably not gonna get changed later. So is it ready for production applications?

Yes. Like I mentioned before, we do have folks that are running it in production, but running with the the set of available building blocks that come out of the box. Right? Like I mentioned also before, what you're gonna see is there gonna be more integrations that are gonna come in. You know, the Azure functions 1, we have to get that one to 1 point o.

You know, better integration with Logic Apps, you have to get that one to 1 point o. And then there's tons of other providers. Right? So providers being the implementations that plug into those building box is more, more of those that we wanna get in the box. So, again, like, if folks want to see something like, you know, Azure storage or Azure RedisQ or, you know, name your service, whatever it is, and there's not an existing provider for it, there's not an existing implementation that plugs into dapper, now would be a great time to to add those things and have those conversations about what would support for this thing look like.

Also, again, because dapper is about patterns, if there's a pattern that you've seen yourself use a lot, you know, in your in your work in building distributed apps, but maybe it's it's not something that's in Dapper today, now would be a great time to be like, hey. This is something that we use. This is really common. You know? How can we add this to Dapr?

And if you if you looked over the last few releases, like, most of those features have been community requested features. It's been folks from the community that have used it. I've tried it in their different production scenarios and said, hey. You know, here's something very common that we do. You know, how can we do this with Dapr?

And if it doesn't exist today, like, the team again, there's usually a fairly quick turnaround. The team is able to go in and add it, and then, you know, hopefully, everyone test it. And and then, yeah, we could promote it into a a production grade scenario. It it sounds like Dapper's got a really strong foundation. It's just gonna continue to to grow from here.

Yeah. I think so too. I think one of the one of the things that makes open source successful is 1, having a a strong community. That means that that means listening to your community, interacting with your community, and making them feel involved, making them feel like they're a part of the project. And then 2, being able to, you know, just show respect for and open up scenarios for different people across, like, the ecosystem.

I think once we start to lock things down and say, hey. I'm gonna make this really cool feature, but it only runs in Kubernetes. Oh, great. Well, I don't use Kubernetes. I can't use your feature.

Right? Or this really great feature, and it only works in Go, or it only works in Node. Js, so it only works here. I mean, like, I appreciate innovation across, you know, these different ecosystems, but when you can have something that truly runs in a in a very diverse, in a very open way, then that that opens it up for everyone. And so by default, your community would be so much larger because everyone can get a chance to play and have an opinion and share an experience versus being like, oh, okay.

Well, I don't use that thing that only runs on the MacBook on, like, 12 o'clock in the afternoon. Like, I don't I don't have that thing. So Mhmm. Sorry. It doesn't make sense.

Alright. Well, I think I'm gonna push us into picks. Thanks for that great discussion on Dapr. Yep. Sure.

You're welcome. Yeah. It's good. Interesting. Yeah.

So why, let why don't you start it off and let us know what your pick is this week? K. So I actually recently got, like, a really good deal on a on a VPN. It's called Surfshark. And, yeah, I've been really impressed with it.

So here in Australia, it's, I guess, best thing. But so, like a lot of shows kind of get blocked. We don't get the latest shows, Netflix and things like that. This is really good to bad to just have this VPN and just log into the US Netflix and watch, The Office or Breaking Bad and all that. But also like, cause I because, I I like to to watch a lot of kinda, like, Chinese TV shows.

Although sometimes it's good to actually hook hooked up to the the Hong Kong region as well and see some Cantonese shows and stuff like that. So it's just been really good having, having this VPN. So it's called Surfshark, and it's yes. I I've got a really good deal, so it was, like, 90% off. So yeah.

Yep. That's a good deal. Yeah. Alright, Caleb. What's your pick?

Well, Switch, I don't know. Well, it's actually it's not a Switch game. It is a game, but it's not a Switch game. Because you know I usually pick stuff that I'm using to decompress or relax or, you know, take care of myself. Right?

No. I've actually gotten back into Destiny 2, which is a PC looter shooter kinda game. And they have made the base game with the first two expansions free. And and so I've hopped back in and been playing it for a little bit and and enjoying, you know, blowing up other people for an hour or so here and there. You know, I know folks on that are listening can't see my facial expression, but, like, my eyes lit up when you say Destiny.

Like, so I've I've loved Destiny since the first one. I've spent, like, more hours than I'd probably would have been playing Destiny 1. You know, I I got into Destiny 2 earlier this year. I haven't played it as much as I'd like to because, you know, I have to work. But Right.

Right. I I I'm such a huge fan of, like, that that world of Destiny and then the lore and stuff. Like, I I love it, man. Do you play on you play on a console, you said, or you play on on the PC? Your PC.

Got it. You own a console? I do. I play it on the Xbox. I play it on the Xbox.

Yeah. No. Yeah. I love Destiny. That's great.

Yeah. I love Destiny. That's Destiny is a really good game. Yeah. I'm so old.

I never really got used to using a a console controller. I was just just my fingers just don't work that way. It's been keyboard and mouse just for so many years. It's just I can't switch over. You know, the funny thing is, on the PC, I'm actually using an Xbox controller because I find I mean, I I get it's not as precise or I don't have, you know, minute control, but it's easier for me to do the controller than it is to keyboard for games like Destiny for shooters.

Right? So Right. Right. Right. I think one of the things like, a conscious decision I had to make was I had to separate games from my computer because, like, the computer is, like, work.

Right. Right? And then games are not work. I can't have work. Right.

And, you know, I can't have them together. I need to be a separation. Mhmm. So, you know, like, I'm in my office, you know, folks can't see, but I'm in my office right now. I have to go downstairs and go to the other TV to play the Xbox.

Right? Like, there's no Xbox, like, anywhere in the space. So, like because I work from home as well, like and I've always worked from home, like, even before the pandemic. Like, it had to be a separation from okay. I am leaving work.

Like, I'm walking out of this room. I'm gonna go somewhere else to decompress because if not, like, I'd just be working all the time. Like, could you imagine, like, me playing and then I know, like, teams pops up in the corner. Hey, sounds so good you do this thing. I'm just like, no.

I'm trying to do this raid. Like, leave me alone. Yeah. Well, lately, I've been watching a lot of Diablo videos, especially with the previous stuff for Diablo 4 coming out Yeah. In 2025, probably somewhere around that time frame.

But, yeah, I also have, read that they're they're might be working on a Diablo 2 remake. So that would be pretty interesting to have that, you know, pop up within the next year. So Yeah. That's kind of been my realm that, I'll let I enjoy games that way. Yeah.

If you're a if you're a fan of the Blizzard the Blizzard material, they announced or there's a rumor that's going around that there might be a Minecraft show, like a series that they're gonna do. No. I'm sorry. Not Minecraft. Like a Warcraft series that they're gonna Oh.

I'm Okay. I'm kinda curious about that and to see what Like a Netflix series? Like Yeah. Like something like that. Yeah.

Like a like a like a multipart thing like that. So I'm curious to see if they're gonna do it. I never watched the movie. I know there was a Warcraft movie. I never saw it.

But, like, I'm curious to see if they're gonna do it. Not that good. I thought it was alright, Warcraft. But I I've I've always thought forever and ever because the cut scenes for Diablo were so awesome. I always thought they were gonna make a movie out of that, and they never have yet.

So so, let's see. Talking about, movies and shows, my pick this week. Even though today is the 1st day you can stream Bill and Ted's Face the Music movie, which I really like. I've been watching lately a show on Netflix called Warrior Nun. It's it's a terrible title, but but the show you know, just watch a couple episodes.

You'll you'll get into it. It's really interesting. I won't give too much away, but it's about a girl that dies, but then gets brought to back to life by an angel's halo getting embedded into her back. And that gives her all sorts of abilities and powers and things like that. So Spoiler alert.

Spoiler alert. No. It's not a spoiler alert. That's just that's that's the first first episode. 1st episode.

1st episode. 1st 20, 30 minutes of it, so you'll get to that far, right away. But it's actually really interesting. And I I didn't like how they ended the season, right, in the middle of something, but there's another season coming. So I just have to wait for that.

So And but all all shows do that these days, isn't it? They always have that hook at the end of the season to And then and then they say they say they're coming back, and then 2 times later, they're like, we decided not to renew this show. Or or they come back 6 months later, and you're like, what happened again? Like, I don't that was a year ago. I don't know how many would happen.

Like This was more than a hook. I mean, the way they ended this is, like, right in the middle. You know? He's like, they're not even gonna finish that before the you know, and then then bring something up at the end that that you'll that you'll pick up again on next this is, like, right in the middle. It's like, ah.

You know, I'm glad you had such I'm glad you had such a positive, like, feeling about the show because when I saw the name, I was like, there's no way I'm gonna watch a show named Lorianan. That was that was totally based on just the name. So I I love that you said, like, don't worry about the name. I'll watch the show because the name is exactly why I didn't watch the show. Yeah.

Even my wife, before I hit start and play, she was gone, I don't wanna watch this show. I don't want and then, you know, halfway through the first episode, whatever, we're both, you know, really into it. Yeah. That's that's awesome. That's good.

So alright. What are you gonna pick for us, Cecil? Alright. My pick. So since we were talking about games earlier, I guess folks might have guessed, like, I'm into games just, like, a little bit.

And one of my like, so when my son was born, I have a 8 year old. But when my son was born, I remember I was on leave and I spent a lot of time on the couch, like, holding a baby and, like, watching TV or playing games. And one of the theories that I started to play and I I went all the way through was the Batman Arkham series. So, you know, Arkham Origins, Arkham Knights, and Arkham City. And I think just this week or I think it was last weekend, they just announced a new Batman game or a a game in the Batman world called the Gotham Knights.

And I'm really excited to see that, whenever it comes out. It's not out today. It's gonna be out next week. But it's one of those like, we've been waiting to hear about this game for, like, 2 years now, maybe a little bit more, and they're like, what are you gonna do with WB? Like, what's happening?

Like, where's where's the announcement? So they finally announced it. It looks like it's gonna be a little bit different, though. It's in the Batman world, but you don't play as Batman. You can be the Red Hood or Robin or Batgirl.

Like, you play with, you know, the rest of the family, but not with Batman himself. But, it looks really interesting. I'm really excited to play it, and and that's my pick. Very cool. Very cool.

I grew up on Adam West Batman, so that was cool. That's that's how old I am. I told you. Don't worry about saying you're old. I am old.

Alright. So if people wanna reach out to you, they have questions on GAPR, how can they do that, Cecil? Sure. I'm fairly active on Twitter. Like, I would pretty much, like, every day I'm on Twitter doing something or messaging about something.

But you can always reach out to me on Twitter at sussellphilip. I'm also totally open to folks following me or adding me on LinkedIn if they wanna just talk about whatever. So so that's also a good avenue. On top of that too, I mean, I also do a lot with our channel 9 studios. So Channel 9, if folks aren't familiar, is like Microsoft's video portal.

We had it for years, like, much longer than I've even been at the company. And that's where a lot of, you know, our video shows live, you know, in addition to YouTube. So there's an AI show, and then there's At Your Friday. You know, I help host and produce the On.net show. You can imagine it's all about dot net stuff.

And then we also right now, we're doing a lot of live things as well. So if folks are interested to interacting with us live, like, you could definitely check out our community stand ups. We do on.netlive on Thursdays, every other Thursday. You know, we have our ml.netfolks that they just recently started live streaming as well. So any point in time that you actually want to speak to the people that actually build the product and use the tools, you know, those are always great avenues for you to reach out to them and and have, like, an interactive conversation.

Awesome. Awesome. And if people wanna reach out to the show, we'd love to hear from you. We wanna get feedback on how we can make the show better. You can reach me on Twitter at dotnewittsuperhero.net.

Yeah. Pump up and away. I'm coming to the rescue. Alright. Thanks, guys.

Great show. Yep. Yeah. Alright. Yep.

We'll we'll catch you, everybody, on the next episode of adventures in dot net. Cheers later. Bye.
Album Art
The Magic of DAPR with Cecil Phillip - .NET 185
0:00
01:04:07
Playback Speed: