The Modern .NET Show

Episode 83 - Dapr and .NET Microservices with Davide Bedin

Embedded Player

Episode 83 - Dapr and .NET Microservices with Davide Bedin
The .NET Core Podcast

Episode 83 - Dapr and .NET Microservices with Davide Bedin

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

Hello everyone and welcome to THE .NET Core Podcast. An award-winning podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.

I am your host, Jamie “GaProgMan” Taylor. In this episode, I talked with Davide Bedin about Dapr, the Distributed Application Runtime, how you can leverage it to manage your microservice based application stacks (regardless of technology used), and his most recent book Practical Microservices with Dapr and .NET. I’ll let Davide explain it in a moment, but Dapr (D A P R) is different to the ORM called Dapper (D A P P E R).

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Jamie

So thank you ever so much Davide. Just just to set that correctly from the start, it is Davide isn’t there? Is it?

Davide

Yeah, so it’s Davide, but Davide is fine. Okay.

Jamie

Okay, well, we’ll do it correctly. So Davide, then thank you ever so much for spending some time with me this afternoon. And I really, really appreciate it. Because you know, you’re very busy gentlemen. And thank you so much.

Davide

Thank you very much for inviting me. I’m really happy to be here and talking with you.

Jamie

Thank you so much. So we’re gonna be talking today a little bit about Dapr. And a little bit about the book that you have on Dapr and .NET. But there’s a couple of things we need to clear up just real quick first, is there are two different things: Dapper (D A P P E R), and Dapr (D A P R). And we’re going to be talking about the latter (D A P R) rather than the ORM system, right?

Davide

Yeah, exactly. And, and by the way, I also in my experience, I had the chance to first work with dapper the or the or, I probably spend more time on this than for example Entity Framework for what is worth. And so yes, Dapper, sure with D A P R is the Distributed Application Runtime, which I’m most passionate about it. And on which I’m really focusing, since the last year.

Jamie

Sure. Excellent. So I guess before we continue on talking about Dapr, and your work with Dapr. I was wondering, could you let the listeners know a little bit about you? For instance, they may know from the description that you work at Microsoft. And obviously, we’ll put the caveat in. You are speaking for yourself, not for Microsoft.

Davide

Yeah, thank you. So in fact, let’s start with the presentation. So I’m Davide Bevine. I’m from the beautiful northeast of Italy. So if you picture me, I’m halfway between Venice and the Dolomites. And I currently am cloud solution architect at Microsoft. So a cloud solution architect, nowadays is a common role. And but for those who doesn’t know what, what a cloud solution architect does is, I work with enterprise customers to help them adopt/use the cloud Azure from Microsoft, in the best, most effective possible way. And I have been a cloud solution architect in Microsoft for the past seven and a half years.

And before that, I was an independent software vendor, an ISP. And this is the experience from which I have my development background. And I was in the retail software management system sector. And so I always combine the experience as being a customer, first of Azure and Microsoft .NET, and everything else. And then I became an advocate from the Microsoft side. So I’m sure that the way that I saw Dapr, and how enthusiastic, I am, it comes from really both experiences. What I wanted to have a long time ago, when I was a developer, and what I see now as a cloud solution architect that can solve many, if not most of my customer issues.

Jamie

That’s the great thing about these tools, is that we discover them, and then we go, “hh, if only I had this tool 5-10 years ago.”

Davide

Yeah. And probably is something that tells a lot about our age, I suppose.

Jamie

Oh, definitely.

Okay, and so before we go on to a little bit more about Dapr, let’s talk about the book that you’ve written as well. Because full disclosure, I’ve I’ve had a chance to read the book. And I knew nothing about Dapr going into the book. And I feel, you know, there’s, there’s more than enough information there for me to actually start using it with a real world application.

Davide

I’m glad to hear that. So we were probably at one year from when I started working on the book. So Dapr - and for the rest of the, this podcast, we’ll see Dapr but it’s the Distributed Application Runtime - has been something on my radar for more than the last year. So because it’s a project that started one year and a half or more, and I follow it.

Also, with some colleagues, we try to build something, you know, during the, during the lockdown, you had more time to study. And so I took the chance to learn more about Dapr. And I, with my colleagues, I published a series of articles on LinkedIn on our learning process of Dapr. And from that starting point Packt, the publishing company, contacted me asking me if I wanted to write a book on Dapr. And so obviously, these are the kinds of opportunities you have to take. And I have never thought of writing a book. And I’m really glad that so many people are reading it and find it useful.

And yeah, and since the publishing of the book last December. And, yeah, I’ve been doing a lot of conferences because I really wanted to spread the knowledge and my enthusiasm for Dapr.

Jamie

Excellent. So just so the listeners are, what was the title of the book? Sorry.

Davide

Ah yeah, absolutely. it is Practical Microservices with Dapr and .NET.

Jamie

Excellent. Like I say, I’ve read through it. We had a pre-interview call a few weeks back, and I showed you that I have lots and lots of tabs. I like to do that. Because I mean, with a book like that and with other technical books, there’s almost always something really useful on every page, right? But what I like to do is I like to put a tab on an incredibly useful, “oh. This is a great point,” or “this is a command I should learn,” or “this is an important thing about the theory behind how this system this technology is working.” So yeah, I’ve like I said, I’ve I’ve read the book myself, which is gonna come across a bit weird, because I’m going to be asking you some leading questions. But that’s how we do things.

So yeah, like we’ve said earlier on, this is for the Dapr - D A P R - the distributed application runtime, not Dapper - D A P P E R - the Orm. I mean, they’re both very, very useful, right? Like you said earlier on, you started out using Dapper - D A P P E R - rather than Entity Framework, and that’s totally fine. But that’s not the subject of today’s today’s interview.

So I know from reading a book that I can use Dapr to sort of manage my application stack, right. If I have a bunch of microservices, I can throw dapper at it, it doesn’t matter magic, and it’s good to go right. Is that Is that how you would describe it? How would you describe Dapr?

Davide

Well, yeah, I agree with your point of view. So in general Dapr offers a set of building blocks, there are seven living blocks right now. And these building blocks are the you know, the outcome of our long and vast experiences by Microsoft in developing and operating massive hyperscale distributed solutions and also, you know, helping customers achieve the same. So, from all these experiences and best practices come out, and with Dapr they are manifested as the building blocks. So you have a building block, if you need to manage the state, in your service, or if you need to establish a communication between one microservice and another or implement other patterns.

So the idea behind Dapr and, what I verified as a need from my perspective as a solution architect, is that enterprise developers should focus mostly on the business logic on the real value, they’re adding into code.They should avoid being slowed down by the complexity of a framework, by managing the dependencies of libraries that will be used for the plumbing code, in order to connect your code to discovery mechanism for services, or a library for managing record or a datbase, or the library to send a message with specific messages in system, you know, this kind of stuff.

So this is the kind of scenario that I suppose we all share. So I at least I have it, it has been my ongoing pain in my previous experience, that the more your system is, gets complex or evolves. If you’re lucky enough to build a solution that lives long enough, you will have the burden in keeping track of the dependencies you have. And more and more, you will also might need to combine different contributions by different members of the organisation or teams that might use also other languages. You know, because I tackled I approached the description of what Dapr is, in my book from the .NET perspective, but Dapr is a runtime for any language. So it’s really it’s really about this is the perspective that Dapr has originated from, and the goal that it has to achieve.

Jamie

Sure, I mean, I agree with you completely in the you know, regardless of where you are, in that stack of building applications, the thing that you should be focusing on is the building of the application, right? Not necessarily the wiring together of all the services. Whilst that is very important, when you have a bug is usually not in how the services are wired together, it’s in the code somewhere, right? And giving that power back to the developers to actually to build their blocks of functionality, and allowing a system to step in and wire it all together, I think is absolutely wonderful.

Davide

Yeah, I agree. So if I can give you an example of something I consistently faced over my, my career. So I’m really passionate also about, for example, Azure Service Bus. It’s really, my probably my favourite Azure service. And it has been instrumental in all the work I did in my solution I built. And, but you know, it’s a library that you have to carry around with your project. And once you have many services, which will happen if your aim is to adopt an architecture such as with microservices, you will have many components, each of these using the Azure Service Bus library. And obviously you will tend to think that you have a specific way of using Service Bus or any other messaging system. And so what I did was, let’s build some common practice that applies to our scenario in the way we deal with this or that feature of service bus. And overtime, we had to maintain also this part of the code. But really, when I see things in the past from from now, I think that in most if not all the scenarios, I could have used the default approach and maybe just configure some settings in, for example, the locking or how the session was handled. But I was not having as much value as I thought I was trying to solve a dependency, no problem, but a dependency burden with by adding more complexity.

So when you use Dapr, the publish and subscribe building block, for example, gives you the ability to send messages to other parties or microservices you are not aware of in the operation, and to be invoked whenever an event messenger from the same publisher subscriber gets notified to you because your code express to Dapr interest for these topics. And so everything boils down to Dapr which lives in a sidecar. So you can think of it as a process that is running side by side with your application. It will be this sidecar to use the library for service bus. And what it will do, it will invoke your method on your microservice to notify you that that something happened - an event a message has been received - and asking you to process it. And then you reply with success. You also can say, “Hey, I’m not able to process it right now, please retry,” or you can also fail if this is the case. And all of this will influence the rest of your workflow. But you will not have the need to take care of the the specifics of the library and the system you’re using.

Okay, so in a sense, also, if you have a situation in which you are confident that you need to control directly the way you consume or send messages and events to any messaging system, you can - and you should continue to do so. But for most of the scenarios, I think you can benefit far more from a large community that is working together on a very good starting points with the publish and subscribe building block, and focus on the business logic. Because probably if you are an enterprise developer, your core business is not in the plumbing code, it is in solving problems with your code.

Jamie

I absolutely agree with you. It’s like you said, you know, your your paycheck doesn’t necessarily come from Oh, there’s a problem with service bus comes from is, you know, is this customer able to reserve and purchase this item, for instance. Yeah. And

Davide

also on bill to build on top of this. Is that probably the way that the publisher subscriber leverages a user is mass and on average, Ha, rabid mq, TT all the other components, it probably is the best the best approach unless you have completely different scenarios. So this is best practices getting into code. And so I see a lot of value in leveraging this approach with sidebars.

Jamie

Sure.

Davide

And, and so dapper takes care if that, doesn’t it by using is it? It’s Kubernetes, isn’t it? Well, so you have different options. So proper, the runtime can operate in self hosted mode, and Kubernetes mode. So we’ve sub service, which is the one you will probably face first because if you instal dapper the command line interface, the tooling in your development machine, you will have, you will see dapper running in a suppose that way. But there are some scenarios in which you might want to use copper on group of machines or notes, generally speaking,

the other type of this will also be supported. Okay. So the other deployment mode is with with Kubernetes. So, in this case Dapr builds upon this very popular orchestrator for computer resources, and is the way that dapper gains. It’s also portability. Because dapper can work on any Kubernetes cluster that is cncf, cloud native computing foundation compliant. So Microsoft Azure, your on premise, environment, and any other cloud vendor. Okay. So this is one of the aspects that gives Dapr this strong advantage of portability. And when you instal it on dapper you will have, you will see that in Kubernetes, you will have four, if I correctly remember, for Kubernetes services that will help distribute the configuration of the component that you choose to use. So maybe on premise, you might use rabbit mq for the component for publishing subscribe, but once you are in Kubernetes, on Azure, you will use Azure Service Bus. This is just the change of configuration. And it will be one of the four services that dapper has in Kubernetes that will let all the micro services know No, of this configuration and how to apply it and also takes care of many other aspects. But yes, these are the tools so Kubernetes and self hosted.

Jamie

There was gonna be my next question was obviously, you know, this is dapper is something that was being it’s being developed in the open and there is a community of developers around it. But obviously one of the one of the the, one of the groups, shall we say that is helping to push the development of dapper is obviously Microsoft. And obviously, some people will be saying, Oh, well, can I use that with my Amazon cluster or with my Google cluster? Or, you know, my linode or whomever? And you just answered that straightaway. So I don’t have to ask that question again. No, no. Well, there is one more aspect to this part is maybe not on the features of dapper, but

Davide

the way that the project is, is moving forward. So there are if you want to know more about dapper there are clinicals every two days or something like that weeks in which the team and the contribute or explain what they’re working on. And you see, if you if you look at one of the last goals, you see how much time is. here is someone from outside of Microsoft talking about the new feature they’re working on, or the really the new features that already have been published. So the community is really, really important and really active. But more than that, is that the the adoption process of dapper to the cloud native computing Foundation has been started. So that’s also something really important. And it’s part of the the importance that Microsoft sees in contributing to open source communities.

Jamie

Sure, sure. I think that’s, that’s a it’s a topic for another day, I think. But there’s a great push from Microsoft to be here. Let’s build things for other people to use. And it doesn’t matter whether they come to as your or whether they go to AWS or, you know, whether they host internally or whatever, let’s just build some great tools for people right now.

Davide

The focus is really on developers. And developers must be able to move wherever they want, depending on situation, they will, they cannot think in advance. So let’s build tools that help them face these challenges.

Jamie

Oh, absolutely. I mean, I don’t know whether you’ve been on many projects where the requirements have changed very suddenly. But I can understand, it’s happened to me quite a few times.

Davide

Yeah.

Jamie

Okay, so we’ve talked a lot about dotnet and dotnet. Developers, and obviously, this is a dotnet focus podcast, but is dapper specifically.net technology. Like, if I had a service that was, say, a Node JS or NGO or something like that, can I still use that? But to sort of wire everything up? Is it? Yeah,

Davide

absolutely. Well, dapper has been developed. And he’s been the route in go. Okay. So, but what you see what, and so it wouldn’t be irrelevant. If you want to, for example, contribute with a new component, okay. Or you want to contribute to a feature set. So you have to no go. Okay. But for the developer point of view, which is always my point of view. So I’m, it’s like, I’m an enterprise developer. So I relate myself my code to dapper via API. So obviously, my book is focused. And it starts with dotnet.

Because it’s my background, okay. And so I feel more far more comfortable in working against the dotnet SDK, that helps me bridge my choice on C sharp, and net, to the technology that runtime I’m using so dapper bot, also over the book. And it’s something that I strongly suggest to anyone that is approaching dapper. Start looking at dapper from the API perspective, then, once you understand the tool, how does it work, and really how easy and simple is the structure of the BI they’re really easy to understand. And to to see the concept behind it. So once you have this knowledge, then you can use the API directly from your coat, if you don’t, do not want to use another SDK. But as I said, from dotnet, it has been really helpful to have dotnet SDK for dapper, and there are SDKs for all the languages you mention. No GS, absolutely Python.

So go, absolutely Java. So there are SDKs for reach SDKs for all of these languages, but there might be also situations in which you might prefer to interact with Dapr directly with with the API. So it’s it’s really any language, you can use any language with dapper, even the ones that do not exist yet. Because they will be able quite probably, they will be able to invoke REST API. Right. So in that sense, yes, it’s any language? And dotnet is the starting point for my book.

Jamie

Excellent. I do. I do prefer it when it’s, to a certain extent technology agnostic. Yeah. Because like you say, it then doesn’t matter if you have a component, or let’s say, you’re building something that does analytics on some retail data, right? You may want to do some machine learning things with it, which point Python might be the best way to do it may not be. And so you can wrap your Python code into a service into a micro service, attach that to your data provided application stack. And guess what? It just works, right? Yeah, absolutely. And I, I related to the experience you described, and because it’s something I went through many times, so situations in which

Davide

once you’re not anymore, the only one deciding the or influencing the language that your shop or your organisation is using. And so, in my case was C sharp, you realise that the world is much larger, and there are larger organisation in which different skills come together. And there might be languages that are far more popular in, in the community, from which those skills are common example, for example, Python, that you want to embrace. And not only enabling them to use knopper, but making them equal first

Jamie

class citizen or equal citizens even more. So they can use logic that might have been built with C sharp, and the same applies in the other way. Sure, sure. And, like I say, I really like that, because, I mean, again, I’ve been on projects before where there’s, there’s this binary blob, which is in another language, and nobody knows how to change it. And, you know, when when there’s perhaps an operating system update, oh, we can update the server. This was years and years ago, but we can’t update the server or the runtime because we don’t know whether it’s going to affect the binary that exists. Maybe it was in Java maybe was in Python or some other you know, some other language you know?

And it sounds like that I could help with that.

Davide

Makes me it makes far more easy to to define your architecture as unique. So the fact that you might need to have another microservice it with dapper you will have you will avoid the initial tax on Yes, but how worried comes all the way from the libraries, the practices that I have to use to start where are they located? What template I’m going to use and if a new micro service comes with another different need that shift the language or the libraries or the components that have to be used, so for example, they have to react to events coming from a calf cast Creek stream, right.

You will not have the complexity in getting started. Because so proper, simplifies the the adoption also of our microservice architecture.

Jamie

Sure, sure.

So, one of the things that I know about when I was because we’re talking a little bit about microservices, right. One of the things that I know about when I was reading up about that book and after reading your book was There’s a separate thing from Microsoft called Project tie. Right? And I’m thinking, a project helps me manage more microservices to is there? Is there some kind of crossover between them? Or are they completely separate projects. So yes, together, they are separate projects. So if I remember correctly, project di is dotnet foundation project. And

Davide

from my perspective, so in, in the context of the book, so I tie has been an additional tool that I could leverage for the parts of my book, that devils around the body. So, I described how you could use this code by changing the configuration and having to specify different ports for each of your microservice. Because if you wanted to run everything locally, you have to avoid port overlapping. And so an additional way of dealing with this complexity in meeting VS code locally, has been by adopting Thai so I use the Thai for far less than it is capable of. Okay, and so there is a recipe for all time for Dapr, you just specifying the configuration and type configuration file, the projects that you want to start, and it takes care of everything. But yeah, tie in is much more much more than than that. But in the context of the book, I, I only took

Jamie

a look at it from this perspective. Sure, anything that that’s to be expected or they’ve, if there’s another project that you can use, you can leverage to help you with debugging, you’re gonna you’re gonna take a look at it. What I what I really like about Ty dapper, you mentioned it earlier vs. Code is all of these tools and frameworks and and technologies that are coming out now, not just from Microsoft, but from a lot of other providers. They’re all completely free.

And, you know, you said yourself, hey, you know, five years ago or 10 years ago, I’d love to be able to use this. Five years ago, 10 years ago, it would have maybe cost you 1000s of dollars to get something like this.

Davide

Yeah, absolutely. And this is we’re late on this level, and also what I see what I saw, with VS code, which could, you know, you could have a series of podcasts on VS code. To me as a solution architect vs. code has been the lingua franca of because all of my customers, whether they use Java or C sharp or Python, they or Windows or Mac, they obviously have scope. So you have a common experience. And really, it’s incredible what VS code has been capable of achieving?

Jamie

Oh, absolutely. I tend to when I’m doing purely dotnet things, I tend to live inside of Ryder from JetBrains. But what I’m doing absolutely anything else if it’s, if I have a number of services, and maybe there’s a UI and a couple of API’s, and maybe some Python things or whatever, and a Docker thing, that’s that’s Visual Studio code, right? That’s, that’s where I live. When I’m doing stuff like that. And it is, as you say, it’s absolutely amazing. Just the the the things that it can do the extensibility it’s absolutely fantastic. I have to say,

Davide

I completely agree even. It seems like you know, I’m taking the compliments about if Microsoft time I have nothing to do with the school that I really look at it from the perspective of, of a customer. Really Sure.

Jamie

Sure. So you mentioned earlier on, one of the examples you gave was the pub sub stuff, publisher subscriber things with a queue. And now I happen to know because like I say, I’ve read the book, right? I happen to know that you can do direct service to service invocation and you can always Do publish subscribe rate. And this does feel like it’s a leading question.

Would you use one over the other? Or is it it? Because it feels like that’s two different technologies you could use in slightly different ways, right? Oh, yeah, absolutely. They are different, the pay for different needs.

Davide

So other than from the technology perspective, I think that choosing if you want to directly invoke another service, or if you want to send a message to another service, with the acknowledgement that the other service will process it, and therefore do something else. reply to you continue the processing, whatever, it’s, it’s best. It’s a decision that has to be made from the architecture point of view. So if you usually when you first start thinking about your solution, architecture, and you compose it with as many microservices you think are needed, you probably are, you know, describing a relationship between the microservices that can translate to service to service and location.

So what you do with dapper is your code with the help of an SDK or by directly calling the sidecar API of dapper, it will, for example, post JSON payload to another service, which has specific name, and you want to invoke specific method of that service. And you don’t have to care about anything else, it will be dapper to discover where the in your environment whether it is group of VMs or Kubernetes environment, it will be awkward to discover that it has to reach this or that Kubernetes service, because there it is the place where the destination counterparts, microservice is is placed is currently running, okay? And but you know, you have this need, because you want to have immediate feedback of the exchange that you are doing with the other microservice, let’s, let’s see this wave so you have something that it might be too complex to work a straight if you

if you’re at the publish and subscribe, because you have the need to send the feedback to a user, let’s say, well, maybe in that scenario, you could leverage the service service and vocation for one part of your interaction and leave it to publish and subscribe for the rest. But also, I see that publish and subscribe is much more powerful than then these other than just simply postponing the process, which is absolutely great. And most of the issues in our solution architecture might come from the fact that queues has not been used as much as the as the court. But with publish and subscribe. The one of the great benefit comes from the ability of sending a message to an audience of other counterparts other microservices that you do not know in advance. So it is you benefit over time, you know, so if you have to integrate many more microservices that will be added over time to your overall solution. While if they if they can have this kind of relationship. So mainly absolutely a synchronous with publish and subscribe.

Then they just need to subscribe to a topic, knowing that you as the source of the messages for this topic, you will continue to send it and it will be lapper responsibility to manage the subscription because every messaging system has its own mechanism for creating what we commonly named as topic, subscriptions. So, it could be going back to the initial question, it could be the need for a direct interaction, or the ability to add to have two components work at different paces, at different, you know, frequency, and also to interact with unknown or unknown audience that will derive whether you prefer a service to service implication or publish and subscribe. But as with any other building blocks of dapper, you don’t have to choose.

So you just use the feature. And you can have your microservices been able to receive direct invocation, as well as being invoked by Dapr, in reaction to a message in coming into the subscription. So you can even make your services microservices capable of dealing with both of these

Jamie

scenarios genuinely like that, because like I’ve hinted at a few times, you know, some some project will, will invariably the requirements of a project sorry, will invariably change over time. And you may find that, yes, we vote with direct service to service invocation. And then, you know, some new requirement comes along and you’re like, wouldn’t it be so much easier if I can just place this on a queue? and deal with it later? Yeah, absolutely. Absolutely.

Davide

Yeah, I have probably a bias, a favourable bias toward publish and subscribe. And so in fact, in my my Volker, soon, the sample becomes heavily focused on publish and subscribe, because he’s the one that I have relied upon the most, but also, in my experience as developer, but from the my vantage point, you know, by his assertion, I’m able to see many customers, there are I see situations in which instead of service to service, and location is really the way to go. So I often agree with the customers that, you know, they have interaction with, for example, and user, and they have that amount of milliseconds to come up with our sounds. And if everything is done properly, maybe service to service invocation or pattern, and then the building block in doubt or dapper is the way to go. Because it will, it will be easier for you to control the you know, the sequence and make it simpler. Because if you have to coordinate many microservice, there are many approaches. In my book, I describe the one gathers, but there is absolutely place for all of these different partners.

Jamie

I like that. Yeah, I. So there’s this kind of, there’s a little room for almost a Long Term Evolution, I suppose.

With dapper or rather with technologies like that, but they you can you can slowly evolve your I mean, you wouldn’t have to do it slowly. You can rapidly evolve if you wish, your application stack. And don’t just want to say one application because some people think of some people think of a single micro service as an application itself. Whereas I like to think of an application stack just because ways it’s either, you know, many, many things make a hole or, or is it all? You know, but that’s beside the point. Yeah, I like the idea of the sort of Long Term Evolution of the application, you know, having to look at, well, in six months, we’ll need to do a queuing system. So we may as well start looking at it now won’t actually know if, you know, like you said, if you’re using if you’re leveraging something like that, but you can, you can put that decision off until later on. And effectively, you know, maybe write 100 lines of code if that

Davide

on both ends of your, both ends of your queue, to be able to read from and write to write, and probably not even that many lines of code. It just it seems like it makes more sense than the traditional. Right, we’ve got to trash this whole service and rebuild it because Exactly, exactly. This is the really the scenario that dapper that the team that created Dapr saw and wanted to approach with dapper. So there are seven building blocks, services, servicing locations, state management, publisher, scribe, these are the binding input and auto binding, you have observability you have secrets, and then actors, you can use lapper and introduce it into your existing application, maybe because you have you see the value in using one of these building blocks. And then over time, in some portions of your overall solution, you will see the space for replacing the existing approach by introducing another monoblock.

But there is there is room for and it’s the one of the principal of topper to be able to give you the chance to evolve over time and adopt the building blocks you need. When you need it, you don’t have to use all of these building blocks together. Since the stars

Jamie

show it’s a little like the the new programming features that they bring out with C sharp, eight, C sharp nine, you know, you don’t have to use asynchronous for each loops or, or anything like that, right? You don’t need to you don’t need to use them. You don’t need to use pattern matching. But you can if it fits your your project. domain, right, if it makes sense to do pattern matching, then use it if it makes sense to use one of the many building blocks of dapper, which, you know, we’ve we’ve, we’ve talked a lot about that. So far, we haven’t really covered all of the building books, but I feel like that’s, that’s because there’s so many of them. Right? Yeah, that they are so.

Davide

So reaching the the feature, the empty scenarios the the cover, so yes, I think it will be very challenging to go over.

Jamie

Sure, sure. But I mean that that’s why, you know, towards the end of the episode, we’ll talk about places where people can go to learn a little bit more about that. But right.

Now they have enough information to they can go away and use. They can Google Bing, whatever, whatever search engine they use, they can then go Oh, right, I will look this up and I’ll look that up. Oh, cool. This will take me in this direction. This will take me in that direction. So that allows us I guess people to get a better appreciation of the things that they can do.

So I guess, to be fair, we’re coming towards the end. Now I’ve only got a couple more questions if that’s alright.

So one of them is there’s a lot of talk about g RPC, right? Because sometimes you don’t need all of the overhead of HTTP right.

Davide

Does dapper support g RPC? Can I just wire up some services that use g RPC, and guess what it just works? So also, there has been evolution in the way g RPC is supported in the 1.3 version of dapper, which just came out, but from the general perspective, so g RPC is the way that the sidecar of dapper communicate one to each other. So let’s say you have to make services. They relate the invoke the API on the sidecar okay.

And if you are in a Kubernetes environment, there is a good chance that your code and the sidecar which will leave as you know container inside of your pod that these two pod leaves on different notes probably separated by, by network. So, once your microservices invoke the sidecar because it has to, it wants to use the service servicing location building blocks to communicate to the other micro service from that sidecar the communication to the other sidecar on the other hand, happens in G RPC. Even if you use maybe h DB within your code, darkly, or your code via the SDK.

And on the receiving end, the sidecar which cooperated jocassee with the other sidecar, it will then communicate with your, your service, the HTTP, this is the default, let’s say default way of using it. But you have the ability also to use g RPC. On the last mile, let’s say the last leg of the communication between the sidecar and your application and your coat. And there are some situations in which getting the benefit of I would say latency, reduced latency gRPC compared to http in the last leg could justify the you know, the need for using g RPC on that part two.

From my personal preference, I see a lot of value in interacting between my code and the sidecar both ways in HTTP over time. You know, I mean, for me for my knowledge, and my background, I feel far more comfortable in using claim HTTP REST API.

Jamie

And therefore, it’s my favourite way of using dapper, but absolutely you can use you can leverage g RPC on both ends. I like that. Like I said earlier, it feels very much like a, a Long Term Evolution. Right. And as we mentioned previously, just because it’s there, you don’t have to use it. But should the requirements change, right? Oh, no, no, we have to go over g RPC, because the project manager said or because the customer has said or because he thinks that you need that last

Davide

advantage. Sure. So wherever you want to gain that performance gain, that is one place that you know that there are many factors on whether a team prefers gr PC, or HTTP. The important part is the proper support for sure. Sure. So let’s before we talk about where folks can learn more about dapper, let’s talk one more time about the book then. So reminders all what the title of the book is, it’s practical, microservices with dapper and dotnet. And, Ed, also, the idea of the book is really to, to give you an introduction to dapper So, you don’t need to have an existing starting point or topper This book will give you that and I describe most of the building blocks in my creating with you with the reader project solution with NC sharp of ecommerce, very simple ecommerce backend. And so we start with service service vocation then we need to keep the information that’s state aside and then in the form we use state management to to ease our code for.

The responsibility of managing the state in your microservices, which is, which could be another talk in other episodes, and then builds upon this by using publish or subscribe, the bindings, and obviously observability, which is one of the great, great advantages of using a runtime like dapper, and then focus a lot on also the outdoors, which probably are my my favourite building block. And hopefully, I didn’t mean another building block as my favourite before. But it’s quite sure.

Jamie

Yeah, we’ve, we’ve discussed a little bit about on a, on a different episode, we interviewed Russell Hammett. And he talked about the active button. And it is it’s a wonderfully elegant way to solve pretty much almost every solution, every single problem I can think of with any kind of scalable architecture.

Davide

In fact, I would say I listened to that episode. And I realised that I was looking, and I’m looking at the actual building block of dapper from a different starting point. So, and, absolutely, it’s a miracle actor. But the way I was looking at, I realised comes from my experience. And to me, the most appealing point of actors is the is the way that it handles the you know, it helps you solve the challenges between consistency and concurrency. And so, one, if I remember correctly, the starting point of your conversation was the collector is also way, as you said, to distribute the processing the compute on much larger scale, because the unit of computation will not be just the service, but the specific data set for that instance of the actor and the cold. So, but it’s the eyes. I think it’s the power of the platform.

That speaks to different needs.

Jamie

Absolutely, absolutely. And, you know, for listeners who haven’t heard that episode, I would definitely go back and give it a listen to Episode 22. So it’s very early on in the air in the show’s history.

Davide

So how much time ago?

Jamie

Oh, my goodness. So this, I think will be episode 82. So, quite a while ago, I think maybe two years ago.

Yeah. So maybe we need to do a round table about how great the actor pattern is. And then maybe we can start the great movement away from blockchain and crypto, in fact, a pattern and then we’ll just hear it in all of the, in all of the the literature surrounding development, oh, you should use the act for everything. Yeah, well, that would be with everything.

Davide

In life, and in technology, too much of something is always backed. And I come from the wind camp sort of evenly. So you have to be considered in what is too much off, you know. And so also with actors, it solves some specific challenges, some specific scenarios. And if you faced those absolutely go with actors.

But so actors in a nutshell, they combine your code and data and together and they distribute this vast population of instances of an actor among all the nodes that you want to use. And so you have a lot of computing but also you have a very efficient way of managing accessing and manipulating the state because it will be the instance to govern the way that other clients perform action and access the information in the state of the actor, but is not a replacement for state management and the service.

To set the scene location. So it’s not a super building block is the implementation of an excellent implementation of, of the protocol actor that builds on the, you can think about the all the experience that Michael has point Service Fabric down before it. So everything comes into the reactor being the blocker. And as much as I love some services in Azure, it doesn’t mean that you have to use it every time. There is a tool for the for for, for for, for the job. And so it’s one of the seven building blocks.

And you have also to use it carefully. Because it’s easy to, you know, to think about vehicle actor as a way to distribute your data. Yeah, absolutely. But it is not a database. So, probably is better if you keep away from thinking, while I, the state for real, for real operation is already memory, which is one of the advantages of the platter. While it will be easier, easy to query it, then let’s compose state from invoking 1000s or even more of actual instances and build together an aggregate the formation, this is something I do avoid, and probably one of the most common museums resolve the collateral problem.

Jamie

Sure, sure. There’s that there are certainly a lot of a lot of ways to misuse patterns and technologies that we have. Better, I feel like that might be a discussion for another time. Just very conscious of the the amount of time you have for us today. That’s all.

Davide

Thank you very much. But you know, I’m really happy about talking about that.

And as I said, at the beginning, I I see really as the as the solution to most of the challenges I faced. And probably everyone faced in developing distributed application, whether these be microservices or not. Because it’s not all microservices in the world. If you build something you will probably for me micro services. You can use one dapper also to improve an existing application and use it to to help you decompose your mommy vacation into microservices. So I see from this perspective on my cost as a developer, and how it really solves most of the challenges that enterprise developers face today, also within your applications.

Jamie

Sure. I do like that being able to take a potentially a monolith and then breaking it down. It’s a non trivial task for sure. To use a piece of technology tell me to do that. I will happily do that.

So where can folks, so let’s say your listener is listening along. And they’re like, I really want to learn more about dapper. I want to learn more about the book. And I want to let them I want to learn more about David, how do they How are they getting in contact with you? How do they learn more about the book? How do they learn more about that, but what’s your your top couple of resources for.

Davide

So you can find me on Twitter and also LinkedIn. Maybe you can paste the link in the notes. And so I’m really happy to talk about dapper is something that is really in the in my focus today as I as I’m interested into application innovation, and about dapper and you can go to dapper.io which is the starting point for that is that. So my book is the practical microservices with Docker and open access is published by partner and you can find it on online bookstores.

Jamie

Excellent. Excellent. Well, all that really remains to say, though, is Thank you ever so much for spending some time this afternoon. I like I said at the beginning, I fully appreciate you’re a very busy man.

So I really appreciate you spending some time with us this afternoon to talk to us about dapper and how great is your marching.

The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Wrapping Up

That was my interview with Davide Bedin about Dapr and his new book Practical Microservices with Dapr and .NET. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/subscribe for ways to do that - reach out via out contact page, and to come back next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places