Search
Search
Davide Benin
November 23, 2021

SE Radio 487: Davide Bedin on Dapr Distributed Application Runtime

Davide Bedin, a cloud solution architect at Microsoft and professional Dapr enthusiast joined host Jeff Doolittle to discuss his book, Practical Microservices with Dapr and .NET. Dapr (the Distributed Application Runtime; https://dapr.io) simplifies cloud-native application development by providing standards-based solutions for common application requirements. This approach provides a clean separation of core application logic from typical infrastructural concerns. Davide’s book helps application developers get started using Dapr with an introduction to its core building blocks. Some of these are discussed in detail during the episode, such as service invocation, state management, and publish & subscribe. The conversation addresses topics related to Dapr as a community-driven open source initiative that adopts and implements according to open standards, such as those published by the CNCF. Practices for adopting Dapr in both greenfield applications and existing systems are discussed. The relationship of Dapr to container orchestration technologies such as Kubernetes is also explored.

This episode sponsored by Shortcut.

Show Notes

Related Links

From the Show

From IEEE

From SE Radio

Transcript

Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Jeff Doolittle 00:00:16 Welcome to Software Engineering Radio. I’m your host, Jeff Doolittle. It’s my pleasure to invite Davide Bedin as our guest on the show today for an exploration of Dapr, the Distributed Application Runtime. Davide Bedin is a cloud-native architecture enthusiast with strong and relevant experience with cloud platforms. As a cloud solution architect at Microsoft, Davide is responsible for the guidance and support of enterprise customers and embracing the cloud paradigm, a key enabler of their digital transformation. His recently published book, Practical Microservices with Dapr and .Net, helps software teams rapidly build cloud-native microservices by reducing or eliminating much of the boiler plate and plumbing, which are typically involved in building such solutions. Davide, welcome to Software Engineering Radio.

Davide Bedin 00:01:06 Hi, thank you very much for inviting me. Really excited to have this chance to talk about Dapr.

Jeff Doolittle 00:01:10 Great. Well, speaking of, what is Dapr and why should our listeners care about it?

Davide Bedin 00:01:15 Yeah, so Dapr is the acronym for Distributed Application Runtime. It’s a project that originates from Microsoft probably a couple of years ago. So, yes, we are celebrating these days the second anniversary. And so, I started getting interested about Dapr since the very beginning. So, even a small disclaimer, I’m not involved in the development of Dapr and not part of the product group. I really consider myself as a professional enthusiast of Dapr. And so, pretty much since the beginning, combining my experience as a developer and an independent software vendor before joining Microsoft and also the experience I see with my customers, I immediately felt compelled to learn more about Dapr. So, as Distributed Application Runtime — and the runtime, from my perspective, is one of the most relevant letters in the Dapr acronym because it differentiated from framework — so, when you start to think about distributed applications, multiple components, which have the need to communicate and operate in a varied environment, you will soon face a need to have dependencies to frameworks, in order to do any of the building blocks, any of the operations you are used to managing state having invocation between one component and the other. And so, this is the area in which Dapr distributed runtime aims to bring benefits to the users.

Jeff Doolittle 00:03:17 So, when we begin distributing there’s unique challenges, and it sounds like what you’re saying is Dapr is specifically meant to help address the challenges of moving from components that, say, run altogether and memory with the same language and the same runtime. And now what we’re doing is we’re saying we’re going to have a runtime that’s going to allow us to handle a lot of those challenges of distributing components that are often left to maybe framework dependencies or maybe language specific dependencies, and maybe be able to detach ourselves from those dependencies?

Davide Bedin 00:03:51 Yeah, yeah. So, this is really one of the objectives of Dapr is to give you the ability to choose freely based on your architecture, your style, your languages, and also, the frameworks, whether you want to split your distributed application in many or fewer components, because it will remove as a runtime. It will remove what I both consider attacks on the need for your component to sustain over time, assigned top dependencies. So, we can start, for example, with the ability on one component to communicate with another component, which Dapr provides a building block for named a service-to-service application. So, if you have the same language in both components, which has been my past experience while this might not be that complex, what’s your reality is much more complex because as you said, there are different languages and each language might have a different framework and these frameworks will have a different roadmap and they will probably not move in sync, in order to support that mechanism, remote procedure call, or multi-vocation framework in one language and the other. So, it will get complicated.

Jeff Doolittle 00:05:33 Yeah, and that’s kind of the tip of the iceberg, isn’t it? I mean, as soon as you’re communicating over something other than direct memory, or maybe a socket or something like that, now you’re going to have other issues. Like, what about security? What about reliability and security? I could go on and on, right? But I’m imagining these are the kinds of problems that Dapr is addressing, which had been addressed. But to your point, it’s addressing them in a way that allows a breadth of access because different languages in different teams — who maybe would have had trouble integrating before — it sounds like Dapr is intended to lower that bar to those different approaches and teams integrating their components together. Is that correct?

Davide Bedin 00:06:15 Yeah. Yeah, absolutely. So, in a sense, Dapr is not only a language-agnostic approach to building microservices — because in the end these days, most of us are building architectures with microservices — it also enables future languages that have not been invented so far to support because it brings the barrier of entry as low as an HTTP API or APCI too. But, the overall point of Dapr is that it is a runtime that using the sidecar pattern leaves side by side with your application. So, if I’m starting to use Dapr in my Oracle development machine, my sidecar will be another process. But when we speak about microservices, probably we are — and this notion I’m moving forward, we were speaking about continuing orchestrator something like Kubernetes — so in that environment, your sidecar will be in another container living side by side, in the same part with your application. So, the HTTPI will be available to you in a very simple, consistent way using standards, whatever they are already available or established; and instead of frameworks, dependencies in your code, you will interact and you will be evoked by a sidecar working side by side with your application.

Jeff Doolittle 00:08:07 Okay, so let’s make sure for listeners who aren’t familiar with the sidecar pattern, I think maybe there was a little bit of description there of what it is, but maybe more explicitly what exactly is the sidecar pattern, because that’s broader than just Dapr. So, that’s a pattern Dapr is adopting. So, maybe give us a brief overview on what the sidecar pattern is.

Davide Bedin 00:08:25 Yeah, so when you think about, let’s say even locally on a single box, you can have a piece of code working inside of your process. Okay. And this happens when you load a library from a framework. And so, that code will execute inside of your environment. So, you share some of the benefit and dependencies with a framework you’re running, let’s say your language of choice is Python, and probably you’re using framework still in Python. And probably you have to get to a certain alignment on the versions. So, something that you can do with sidecar is to split the overall application, your code, for example, from whether it’s a common function, a common feature that you want to provide to all of your application or lie on another component, a third-party component, and you make it run on another process separate from yours. And so, in this situation, you have many advantages.

Davide Bedin 00:09:42 One is that the resources in your processes are only used by your application and that anything that happens in the two sidecars your application and the one that you are using does not influence the other. But it’s more about the separation of responsibility and expectations. So, the way to be able to interact between one sidecar and another could be various Dapr choose to implement locally reachable API. So, going back to the example of running locally in your development machine, you know, that the local house, the default port, which is 5,500, you will reach the Dapr sidecar or process for that you have instantiated for your application. And pretty much the same with certain level of change will happen if instead of your local machine, you are running into a Kubernetes cluster.

Jeff Doolittle 00:11:00 So, the service that I’m dependent on, I’m really dependent on this middle piece, this sidecar that stands in the middle between me and the other service that I’m dependent on, and then decisions about whether I’m accessing that locally or remotely are encapsulated within how I configure that sidecar.

Davide Bedin 00:11:17 Yeah, yeah, that’s pretty much the concept. And the goal with the Dapr is that if you have distributed application has, let’s say two components, each component will have its own sidecar. So, if I have component A that is written in MAT, and component B is written in note, they will both communicate, with their own sidecar. So, let’s say my local environment, I’m going to have each of my application, and my components will have its own sidecar. If I run in Kubernetes, component A and component B will be separate parts because this way I will, for example, be able to scale it independently. Okay? So, what we were used to do with yams, we probably placed component B on a different kind of yam maybe more or less resources. And maybe we scale this way in the very old days with container orchestrator engine like Kubernetes, you accomplish pretty much the same goal, having multiple parts of the same component running and dealing with all their requests. So, this is pretty much how Dapr relies on the sidecar pattern in order to give you the ability to interact with any other application, regardless of the language, regardless, where are they located. Could they be in the same note where your application is located? Could it be in another note and most of the time it will be on a separate note. It will not influence the way you write application. Because you will still have the sidecar at your disposal that you can reach with an HTTPI. So, every language is able to be use to interact with an HTTPI.

Jeff Doolittle 00:13:40 Right, right. So, as I’ve said before on the show, and I say it a lot for people who know me personally too. The two hardest problems in computer engineering are information hiding and dependency management. And really to say dependency management in a way is to say information hiding, which I could get into another time, but you’ve mentioned dependency management and things already. And I think it’s relevant here too, that if I’m using the sidecar, I’m able to hide a lot of information about what’s happening behind the sidecar on the other side of any components or services that I need to be able to interact with. And that isn’t to say, I don’t worry about them. Obviously, as soon as you distribute, you’re going to have to deal with latency and retry and things you wouldn’t necessarily have to locally, but you can make those decisions in how you configure the sidecars. And now it sounds like Dapr is trying to address those major issues, information hiding, and dependency management.

Davide Bedin 00:14:38 Yeah, absolutely and so, far I mentioned the service-to-service in vocation, which is a building block, one of the seven building blocks called Dapr. But the value in what you are describing is more evident when you switch to state management and the publish and subscribe, which are two building blocks because with state management, well, we could probably have a one hour talk on just the state management, but to keep it very simple and short, let’s say your component has the need to keep some state assigned. So, your code can be simpler because it will be a stateless service and your state will be handled by someone else. So, you’re shifting one of the difficult responsibility we tend to have in distributed application, which is to keep state between different holes from the same plant. So, with state management, the responsibility will pass to the Dapr sidecar, but then starts to probably the value of the extensibility of Dapr.

Davide Bedin 00:15:57 So Dapr comes out, with probably then more than 70 components already available and other coming out, being built by the community in order to store the state in different services, whether it’s Redis, cache, whether it’s CouchDB, or a cloud vendor operated database as service. So, Dapr does not only have the aim to be language agnostic, but to be platform agnostic. And we mentioned Kubernetes, we mentioned local environment, which are the two deployment option, but it’s also, cloud vendor agnostic. So, if you go to the documentation of the Dapr, you will see that for state management, but also, for publish and subscribe, you will have support for many of the services provided not only by Asia, but also, by the other cloud vendors.

Jeff Doolittle 00:17:07 Okay, so you mentioned building blocks and I get the sense that that’s a pretty important element here. And you said there’s seven. We don’t need to list the seven necessarily, but previously to the show, you mentioned that there were a few core building blocks. And so, state management is clearly one of them, as you just mentioned. And is there anything else on state management that’s worth mentioning before we maybe dive into a few of the other core building block?

Davide Bedin 00:17:30 Yes, absolutely. So, the concept here is that you called your components counting on the availability of the API by Dapr on the sidecar. So, you can interact directly. You can use an SDK for pretty much any of the language available today and present in the market, but the choice, on whether you are placing the state on an Asia as they be, or as you are locally landing on Redis this now does not sit into your code or your code configuration. It’s a component defined in yaml format, which is pretty common to everyone that has to deal with Kubernetes. And I mean, not that did they want to deal with Kubernetes but they have to deal with it? So, it’s something that will be decided whether by you, whether by the operation team, you will be able to via configuration of components, Dapr components to switch your application from running local, to running magically on Asia with, by just changing a component configuration. And this applies to all the other building blocks. So, the next one probably publish and subscribe I think, service-to-service states and publish subscribe are probably the one that you use the most time.

Jeff Doolittle 00:19:12 Okay, so service-to-service basically, meaning I have one service, I know what service I want to call, and now I’m going to call that other service. I imagine the sidecar is going to help me with dealing with the location of that service so, that I’m not coupled to that as the caller, but interface of that service is what I can depend on. Is that a fair assessment?

Davide Bedin 00:19:34 Yeah, so Dapr does not intervene in the definition of the payload. You are going to pass to the other component because it has an opinion on how to build a distributed application, whether microservices architecture, but it leaves to your language choices, your framework, how to deal with the payload. What you have to specify with service and vocation is the name of the other component in Dapr the ecosystem, and then the method you are going to call to the other side. And so, your requests from your side of the car will go through the environment on Kubernetes. It will then use the Kubernetes mechanism to find the corresponding services, which you will not have to care anymore about. And we’ll pass the payload to the method you specified. So, between Europe components and sidecar on both hands, it can be HTTP to keep it simple, very easily readable. You can also, use see if you have the need, but the great thing is that between the sidecar of Dapr, which as I said, can be distributed over many different notes. Communication will happen in GRPC and will be secure. We have MTLS. So, you get many benefits by default by just interacting with a simple HTTP API.

Jeff Doolittle 00:21:19 You just mentioned a new one there too, which I think is important to highlight. You mentioned MTLS, which is mutual transport layer security. And so, I believe that’s the correct, and we’ll put a link to that in the show nodes in case I’m wrong. And even if I’m right, you still might want to look that up. So, I’m also, getting, I want to say quote for free nothing’s free, but I mean, to me, I’m not having to implement now transport layer security between my components. Dapr is giving me giving that to me?

Davide Bedin 00:21:46 Yeah, yeah in Kubernetes, there are a number of Dapr system components. One of this, has the responsibility to give the ability to any proper sidecar to establish mutual secure channel of communication between each other. And so yes, you get MPLS as a feature of Dapr.

Jeff Doolittle 00:22:11 And then once you have control, sort of have that pipeline of communication between two components. And since now you have this runtime and the sidecars between each side, you can pretty much manage that pipeline by adding whatever. I mean, it feels a lot like middleware with a mediator pattern, sort of like if you’re doing spring apps, or if youíre doing applications with ASP net core, you can inject middleware into your pipeline and do pretty much whatever you want at that point. It’s just sounds like that brought to more of the service-to-service, you know, application, application level.

Davide Bedin 00:22:48 Yeah, yeah, yeah, absolutely in a sense it’s really as you described and something I recently experienced. So, I had the chance to have a ìhackfestî as we call with a customer about Dapr. And it has been mainly around on and other language that I’m not familiar with. So, I was a bit worried that, you know, being a .net developer in the past at least, my focus is always looking at, you know, the SDK, what the SDK provides. And so, my worry was a, but what if the corresponding SDK for the other language does not match the library is the frameworks that the customer will use was using and not for this preference or using this SDK or not with Dapr but as an experiment, we chose to round the access by interacting directly with the HTTP API of Dapr. So, this customer had that language, that framework, which was used to pass a lot of data inside the payload or as headers and we really did not have to patch anything because as I previously, Dapr does not mandate what you put in the payload and in the headers you passed. And so, it has been kind of eye-opening for me that I consider, I spend a lot on Dapr to see how easy is to, well I don’t want to downplay with easy, but how efficient it is to insert Dapr into an existing framework that might do things in a way that is different for me, for example, what to asp.net does with you know, with all the attributes of asp.net framework.

Jeff Doolittle 00:25:04 Right, so, you were able now to integrate with services components written by this other team, without having to first understand their language, their framework, their development tools, everything, you know, they’ve built chains and pipelines and everything. Instead, you were able to consume it and interact with it using Dapr and then vice versa. You’d be able to deliver something to them in the other direction as well. So, that sounds really powerful. And yeah, so taking that now and moving to the next building block, you mentioned before, which is publish and subscribe, which basically is one services sending out a message and it doesn’t necessarily know, it really shouldn’t know who’s listening, but other services can subscribe to those messages and receive them. So, talk a bit about that and how Dapr implements published subscribe in a way that’s maybe different or an improvement on typical approaches.

Davide Bedin 00:26:05 Oh yeah, yeah. And so, with the publish and subscribe, as the goal of Dapr is to offer a consistent set of APIs from the API perspective, it doesn’t change a lot. So, instead of invoking your publishing on payload, but this is one of the building blocks in which I speak from my personal point of view,it gives a lot of sense to observe your existing approach to the publish and subscribe and maybe think about if even inserting Dapr and substituting the way that you deal with sending and receiving messages with Dapr means gives you value. I think it will really give you a lot of value and a lot of help because it will transform the way your components, your microservices are listening to events, to our complete even driven approach, because a lot. So, I spent a lot of time with Asia service boss and other technologies. And so, each one has its own way of dealing with the consuming of messaging, whether it’s by looking at the content and then deciding whether to process or consuming darkly by reading, you know, each one has its own approaches.

Jeff Doolittle 00:27:42 Sure, an example like RabbitMQ or SQS, right. They’re all unique in some ways and respects.

Davide Bedin 00:27:49 Absolutely. Also, because they have different history, different use cases from which they originated and group so, old, great reason to be different. But if you are creating a new Greenfield application or your, you want to innovate on an existing one, the fact that there is a sidecar is side by side with your component that is being configured to use on Asia, let’s say Asia service bus, and maybe a RabbitMQ. If you are working locally or you have on premise installation of your solution and counting that it will be the sidecar responsibility to properly use in the best possible way, the libraries for consuming these services. And you will not have a different approach in your code to react to messages coming from some of service bus or RabbitMQ. It will be the same because your approach will be driven because in fact, the side of the car, will ask your components, uh, first, if you are interested into subscribing to any topic that is exchanged in the messaging in the publish and subscribe, and it will ask for the end point that the, sidecar has to call to inform you that the new message or event has been received. So, you will simply find out a lot. This is really helpful from my experience and the perspective I have during these days working with customers.

Jeff Doolittle 00:29:45 Yeah. And something you said, I really appreciate it as well. And it’s come up before you’ve mentioned development locally versus, you know, directly against cloud resources and assets. And I’m a huge fan as much as possible. And I push it pretty far as possible to do development entirely locally because when the internet goes down or Github goes down or whatever else goes down, especially if you need, oh, I can’t get to SQS because my AWS cluster is this or that, or my Kubernetes cluster is once again, you know, on the Fritz, it’s like, well, hold on. I can do everything locally. And that ability you just described, you know, I’m not going to run a full you know, SQS instance locally, although I’m aware that there’s solutions for that. And it escapes my mind right now, but there is a project that that’s a stand in for a lot of those Amazon cloud services. And I’ll find it and put it in the show notes, but I can also, take a different track, which is I can run RabbitMQ locally, but I can be confident that I’m going to get the same behavior out of Azure service bus. When I switched over to the cloud, there’s a ton of power in that. How has Dapr doing that behind the scenes? How in the world can it, you know, manage this, it must be doing some sort of magic or using some other existing tooling to pull this off?

Davide Bedin 00:31:02 Well, nothing magic. Dapr well I think it’s really, I sometimes also, think about, well, this can be true, how easy it is but they usually people very fast on why I didn’t had it before in my life, but there’s, this is a completely different story. And so, Dapr is an Open Source project and is written entirely in lingo, okay? So, it relies on the components for each of these technologies, the 70 more components available by using the corresponding pro library for each of the service. So, you have right now a large community that is using the same software you are using from different perspective. So, knowing that your client library, client to the messaging subsystem, the messaging system of choice that is being used on different set-up, different scale, different languages, but it’s the very same library. Well, you have probably more cases than the average on that keeps you the task that someone else will see the way to improve it and to update the components. Or if you have a compelling need, you will choose that it can be you, as an individual, as a component, a customer, who can contributor to improve that component for the benefit of the overall community.

Jeff Doolittle 00:32:52 Sure. But what about actually running this stuff? I mean, I imagine I need to download some things to get started. And then I say, okay, well, I locally, I want to run these things with, with these versions of say messaging or state management, but then in the cloud, I want it to be these things what’s happening locally in order to enable this all to happen, is Dapr doing everything itself or is it relying on something else?

Davide Bedin 00:33:18 Yeah. So, the configuration happens via configuration files. So, they will influence which of the many components for each of the building blocks you choose to use and from that point, you will have the ability to influence the way each component works by injecting a specific configuration. So, with service bus you have the option to configure some settings that might be different than with RabbitMQ, but this difference will stay in the component definition.

Jeff Doolittle 00:34:00 Right, based on whether it’s local or cloud. Do I have to install all of these dependent services myself locally, or?

Davide Bedin 00:34:09 Yeah, yeah, I think that will happen during the initialization of Dapr. So, whether it’s local you run Dapr in it, once you install they come on a line in the phase, or if you are in the Kubernetes environment, you can do the same, or you can use a different approach of which is how a chart. And you specify which version of Dapr you want to run. And this will place, the system components and the code that will be used the, by the possible configuration of your components. So, it will be the sidecar in a sense that would carry the options for, let’s say, use architecture, use for faster the publish and subscribe, or use this or other database for the state management.

Jeff Doolittle 00:35:10 Okay. You mentioned something before. I want to make sure that it doesn’t just fly by. You said the word Dapr and niit. So, Dapr space niit, which refers to the Dapr command line? So, yeah, maybe speak to that a little bit.

Davide Bedin 00:35:26 Absolutely. So, the Dapr command line interface is a tool that you can install on any box that helps you with the development experiences. So, locally you will use Dapr to run an application with Dapr run, and you will specify the name of the application and the other settings. You will not use Dapr run once you run your application in Kubernetes because in that part, it will be someone else’s responsibility to start your thought with the container of your image on Kubernetes. It’s as simple as injecting some Dapr specific annotations into your deployments yaml file because yaml gets everywhere. And so, if you have your application and you have been able to put it into a container, and you want to run it on Kubernetes, it’s highly likely that you already have an existing yaml file describing how your application is going to start, which board does it use, et cetera. But what you just need to do is to inject some Dapr annotation in this file, and there will be no other requirements other than these in order to let Dapr know that your container has the interest to inter-operate with number. And so, Dapr will inject the sidecar into your code automatically, without you, as the developer to deal with all these configurations.

Jeff Doolittle 00:37:24 So, you mentioned container again, and I think that’s pointing to, let’s say, I want to install the Dapr command line interface, which I can go find, probably just, you know, do a web search for Dapr space to CLI and you mentioned it, I can pretty much run that anywhere if it’s using containers, and I imagine I’m also, going to need to take a dependency on some engine for running containers locally?

Davide Bedin 00:37:47 Yeah, yeah. So, locally, well, not necessarily because locally by default Dapr installs, the Redis just in order to give you a very easy and faster chance to run however, a very simple application locally and also, does install locally, one of the components of a system components of Dapr, which is the placement service, which is necessary for the rabbit block, which is the reactors, but you have the ability to install the Dapr also, without this component. And so, locally for example, what I, in my book, what I instruct or teach the reader to do is to use the Dapr run, to run the .net solution, the .net project that in the AVS code environment. So, in that stage, while I’m in the development phase, I’m not already putting all my code in a container deployment option. I’m just telling Dapr to run side by side with my application. So, in that part, there are no containers involved. Container are a very good way to deploy an application to Kubernetes and so from that point, you will have to deal with containers, but if Kubernetes is one appealing computer option for your application, you or the approach, the and the complexities of putting your application into a container. Okay.

Jeff Doolittle 00:39:52 Yeah, that’s great. And back to something you said before, those three services that you’re going to automatically get when you Dapr in it in Dapr run. So, you’re going to get Redis immediately for state management and for PubSub now, of course, keeping in mind, this is if you need persistence, you might need to reconsider, but at least for getting started, you’re building an application code. And so, now all of that infrastructure, you can sort of say, I’ll get to that later. First. I want to get my application code working, and then we’ll get to the, the actor building block later. But basically now I have these three services running that are giving me access to these Dapr building blocks with no additional configuration or work on my part. I can just start writing application code.

Davide Bedin 00:40:41 It’s really just default configuration that you have on your local machine. So, once you ran Dapr in it, by default, you will have two yaml configuration file that, that had been provided by Dapr that binds the local, Redis container. So, if you install Dapr in it, you will get just as a starting point Redis, but that is not a requirement to use Redis even locally because as we speak also, because it’s my experience. I tend to consider the local experience, the development experience. So, I heavily rely on, Redis just to test, if I’m able to run my components, if everything is fine, I use it as a test. But there might be situations in which you will ran Dapr even locally, even on the ends, but you will not rely on Redis. You will rely on MLQ, and maybe a Mongo/Couch, whatever local options you have with persistence of the width. It’s really just a way to ease the experience of the developer and just after you are in Dapr and niit.

Jeff Doolittle 00:42:05 Okay, so we have those core building blocks services-to-service, state management, and publish and subscribe. And then I think where we start to get to another level of power is the building blocks called bindings. And in my research for our interview today, it kind of occurred to me that in many respects, Daprís enabling, what’s been called the hexagonal architecture pattern, which I’ll put a link to in the show notes, which basically it boils down to ports and adapters. And so, you’re back to information hiding and dependency management. You know, the canonical old school inter application was the database is sort of at the bottom layer and then everything, you know, stacks up above that. But you end up getting this nefarious coupling because the data access there gets a couple of the database. Your business league has couple of the data logic. Your front end gets coupled to the business logic, and you really haven’t solved anything.

Jeff Doolittle 00:42:57 You’ve just made a distributed mess now instead of a monolithic mess. And so, now what we’re saying is flip that around the database is outside. Aren’t, you know, your hexagon, if you will, it’s as something you bind to as we’ll discuss here or whatever these other things are, right? You have ports into your system, you have adapters out of your system. So, talk a little bit about bindings and how they can kind of help us with that notion of, instead of having these dependencies leak up through our systems, instead we put them outside so, that we depend on them in a decoupled fashion.

Davide Bedin 00:43:30 Yeah, absolutely. So, if we consider the other building blocks for comparison, so, with service-to-service invocation, you gain the ability to establish direct communication between two components. One knows the existence of the other. With publish and subscribe, you are still establishing our relationship with two application. What changes is that the subscriber is probably unaware of the existence of the publisher. It just knows that having expressed the interest for a message for an event, depending on what you consider, he will receive it. And with this 7th river approach, it will react to the information. And so, these are two ways to have your components in your Dapr application to work together. What I consider the bindings, the input and output binding is a way to extend your obligation to the outside world, to something that is already there and like enterprise streaming platform that has been around for far longer than your application.

Davide Bedin 00:44:51 And it will stay a long time there. And you want, as your application is getting built, you want to consume events that come from that source of information. And so, the messages that you will receive, they are sending in a generic way. There is nothing specific about Dapr in the way that you will find the messages streaming Kafka, stream or in Asia. In Asia, you will configure bookbinding in a similar fashion to what you do with publisher subscribe, but it’s meant to be a way to reach outside of your application integrate. We infer an existing flow of information. So, because what I forgot to mention is what keeps you Dapr, for example, in the publish and subscribe is that by using cloud events, it enables a full end to end visibility for observability, which is another building block because it inserts meta data.

Davide Bedin 00:46:07 So, whether your application internally between components at one time is used as a service-to-service, or if it is using publish and subscribe the way that they will share traces via observability and by leveraging another existing standard, which is open telemetry, they will look pretty much the same. In reality, it will be a different approach, but they will occur at component A and component B interacting at different times in indifferent ways. Once you consume a Kafka stream in other system, you will consume messages as they are. And if you want to give back to the messaging platform, the enterprise service bus, or whatever you want to name it, you will send payload without,reaching them with anything that is not that specific, but is more closer to your application. And streaming an event is just an example, consuming events from Twitter, which is one of the first example you will find when you go to about the Dapr, because it tells the story of binding. But, you know, it’s just an external system that is not necessarily part of your application, itís another application or something really outside of even your enterprise, your company. And you want to find a similar way with components configuration to consume events from it and react to events for it.

Jeff Doolittle 00:47:58 Yeah. And you mentioned something important. I want to make sure we highlight, which is you mentioned cloud events, and that is a really important thing to mention because a cloud events is part of the cloud native computing foundation, short form is the CNCF, which will put a link to all of those things in the shadows. And am I correct in saying that Dapr is also, part of the cloud native computing foundation?

Davide Bedin 00:48:21 So, what I know is that the process of integrating, automating the project has been started. It’s a public process. I’m not familiar with the current status, but if you look over to the Dapr roadmap for which is publicly available and on the top, but you will see the current state of Dapr.

Jeff Doolittle 00:48:47 Okay. So, it’s incubated as a CNCF project. That was what I recalled, but it isn’t necessarily in it yet, but that is, that process is going. And as you mentioned, itís Open Source, but also, then embracing open standards, I think is kind of the deeper story there that Dapr isn’t just reinventing the wheel on a lot of these things it’s adopting what is there as existing standards as well?

Davide Bedin 00:49:09 Yeah. And this is one of the core principle of Dapr is to really use standards or whatever they are available and have traction in the community. So, we just mentioned cloud events. The other one is open telemetry. And so, instead of inventing something new, I think we all agree that is beneficial to everyone to contribute back to the success of an open standard on an open platform by using it, for example. And so, this is open telemetry, for example, is something, and the observability block, is something that I would have really treasured in my past, but really it was not around, even the concept. And so, I had to be able to have my own stock to have visibility of quest going through many components, and sometimes I had to make choices on whether it make sense to split one larger component into two, because the road map was diverging from one part of the features from another one. So, it was one healthy discussion about, should they be two different components or two different microservices? But having something more than one more component to handle, to manage, to bind to the log-in in stock. I built my myself, you know, it influenced the discussion.

Jeff Doolittle 00:50:51 Yeah. It was a limiting factor in a way that you didn’t really want that. There’s always going to be limiting factors and constraints, but that’s not the one you wanted. And so, now we can take a different approach before you mentioned observability, before we move into that. So, bindings, you did mention things such as other enterprise services or things that are not Dapr ready, but I also, want to make sure we hit as well on the other side of bindings, which is, say, for example, connecting to databases and maybe make a distinction between when would you use state management, which we talked about before, versus when would you say use bindings to a database instead of, of state management?

Davide Bedin 00:51:31 Yeah, absolutely. So, with state management Dapr aims to give you the ability to take the burden of keeping a state outside of your components. So, your code can be written, we’ve asked stateless approach, and that’s the value of that component. And by doing this, it doesn’t affect your payload but it adds some information. The overall payload with some decoration, but in a general sense, it will leave it as it is, but there’s something specific to the state and the API are as simple as it’s needed for a state management. It doesn’t provide for the language. So, you are meant to just keep the state between codes and nothing more than this. You will still have your database, your line of business and long-lasting database.

Jeff Doolittle 00:52:35 Right. But the state management is more like key value store. It sounds like it’s just in and out. Yeah. As opposed to bindings maybe. Yeah. Now expand on that a little bit for us with what the distinction would be there.

Davide Bedin 00:52:47 Yeah. Yeah. And so, with inside the bindings, you have the ability to interact with another system. By just sending and receiving our payload. So, I don’t remember which are currently the database supported as both whether input and output bonding, I suppose mostly as output bindings by Dapr. But yeah, the sense here is to pass the information to an external database without any infos on what youíve mentioned.

Jeff Doolittle 00:53:30 So, you mentioned observability is one of those things you wished you had. And I think a lot of us have been there as soon as you choose to distribute, you find that the pain of the lack of observability, if you don’t have it. So, Dapr obviously had this as a building block and you mentioned before open telemetry as well. So, speak a little bit more to why observability is so, important in a distributed application and how Dapr lowers the bar to getting observability.

Davide Bedin 00:54:00 Yeah. So, as you said, immediately, as you create two components, as you split your application into different pieces, you will have far more interactions going through less reliable communication channels and being inside the same process. So, you never account for force and retries when you intermittent pass pm errors, when you interact with a library that you load into your application. But as soon as you go outside of your process and far more relevant as we are considering Kubernetes as the major compute options for microservice oriented architecture, that you will cross also, the network boundary of RPM or nodes in Kubernetes terms, and this will increase the number of situation that your application has to deal. So, and this adjusts for service-to-service communication. So, when you start sending messages to messaging system, with publish and subscribe, it will happen at different times on different nodes, maybe.

Davide Bedin 00:55:23 So, it will not even be in the same sequence of events. So, this is another complication which will happen regardless of the choice. You may call your framework, your language, et cetera, because they, they are part of the reality of a distributed application. And so, with observability building block, and by adopting the open telemetry you out of the box with just the one configuration, which you pass to your Dapr application, you can specify your application to enable the, forward all the traces to a consumer compatible long-term metrics, consumer compatible with the open telemetry stack, which will give you an end to end visibility of all the interaction that happened regardless of the way that you are using the Dapr API. So, if your components and just leverage Dapr some of the building blocks, and let’s say, state management, better service-to-service, these are the, these exchange between one Dapr application to the other and the retrieval or update of the information with the state.

Davide Bedin 00:56:49 These are the elements that will surface and that you can, we’ll be able to see from any viewer, let’s say any consuming application that can deal with that format, that open format. So, the Zipkin is one option application insights can be another one, but also, on our tracing application, performance monitoring tracing or log-in platform can be used. So, it’s highly likely that you will be able to integrate to your existing platform with Dapr because open telemetry is a standard. So, it’s not something magic. It’s just that it’s a standard and so, everyone in the industry is embracing this. So, this is an incredible value from the operational side, also, from the development side, because you know that you’re, once you get an exception and they’re, there is you as the developer and the operation team will be able to see the very same trace, the very same exchange, knowing where it’s taking too much time, how the code is flowing. So, it’s really a helpful development and optimization and operational assets with Dapr.

Jeff Doolittle 00:58:23 Yeah. Troubleshooting bugs, but also, root cause analysis on outages or things of this nature. Absolutely having that ability to do distributed tracing is, is important. And so, that’s great that Dapr includes that as a, very important building block. So, I want to get started with Dapr. Let’s say I have an existing application and I don’t want to have to do a bunch of rewriting redos re whatever. Like, how can I get started using this on an existing system, obviously for Greenfield, it sounds like there’s a lot of power here and things I can do, and that’s great, but you know, it’s obviously, it’s always super important to make sure that the new cool things don’t just leave everything in the dust because we can’t just rewrite everything. So, how do we get started with Dapr on existing systems?

Davide Bedin 00:59:11 Yeah, yeah, absolutely. So, I don’t know, what’s your starting point, but I tend to look for SDK wherever I can, but this just because it’s my background. But as I said, even for Greenfield for a new application, SDK is provided by Dapr for all the language, is a starting point because it accelerates the development. But one option is to use Dapr darkly via the HTTP API. And this is the approach that you can take to the Paris, which is a term that is using the opera community, which means to enable an existing application or even a new application to interact with Dapr via the API. So, yes, your obligation has a, must have a way to request and send something to an API, but it doesn’t ask anything more to the existing application.

Davide Bedin 01:00:31 It doesn’t have to know about Dapr. And probably one of the first scenario that you face on temporizing, an application, which is also, very well documented into the docs Dapr or site is on instructing an English controller, which is a component in Kubernetes which you use to expose your internal application that is running internally into the Kubernetes cluster. You use it to expose it to the outside world, to your customer, to your clients. Okay. And so, what developers had to do was not only to configure, to put that code into a container and then configure a deployment specification to yaml, but they also, had to deal with services from the Kubernetes perspective, how to name, to discover application, how to name application, et cetera. Which has taken care by Dapr. By Daprizing, you just inject some annotations into a deployment script. So, you can do it with engine X, as an example, any other ingress controller, it applies the same.

Davide Bedin 01:01:58 And so, if your application has a way to request, to reach the resource of the HTTP and maybe do some translation, you will be able to use a Dapr. And it’s something that I recently experienced, a scenario that we went through. We chose to take this approach of temporizing, an existing application that for sure already had a place in which it was possible to change the URL of resource of the end points. And we changed it into, from the existing one we adopt a Dapr specific, API end point, thatís pointing to the sidecar. And so, as nothing is mandated about the parameters, the ad that was the body, et cetera, everything gets passed as you put it. So, we have an ingress controller that went back to the documented, the well-documented sample and something that I also, went through in my book. It’s really easy given that you already deal with HTTP API,

Jeff Doolittle 01:03:21 Right? So, if I have a one service that is relying on another service, and let’s say it’s already communicating via HTTP, then I can basically, instead of having it speak HTTP to the existing endpoint, I can have it talk to the Dapr sidecar, and then have Dapr now become the mediator between my service and that other service. And then I can leverage all this other richness, like the observability that we mentioned before and, and everything else that Dapr can provide. So, that’s one way to do it. There’s also, in my research, I found a project called Dapr sidekick, which sounds like it takes what you’re describing and it lowers the bar even further. Are you familiar with that project? And maybe if you are, explain a bit about what it does.

Davide Bedin 01:04:07 Well, I’m not that familiar, but it’s something that I really remember from one of the community calls, which I attend as many in the community. And so, Dapr has bi-weekly community calls open for everyone. So, Dapr has these core channels in which you can talk about all the components in addition to the proper discussion on the top, but in the community calls there are many contributors, like in this case, a sidekick is a project started by mangroves and which they presented a new way to leverage Dapr or for deploying an application, not obviously on the local machine. As we started our conversation, not on orchestrator like Kubernetes, but on multiple Yams. And so, they extended the way you can operate the Dapr sidecar in a way that enable them to rely on Dapr, for the various building blocks in your scenario. Which is from my, really, from my external perspective, as, as someone that is closely looking and loving the community and the Dapr project is something expected. Absolutely, but nevertheless, it’s amazing. It’s something .net specific if I remember and maybe we can put in the notes pointing to the, to the committee calls the specific one in which they talk Sharpies, because also, the process. So far, I have been successful in a way to build something with Dapr, but that example, and many others are relevant also, to understand on how can you build something new that did not already exist new scenarios and contribute back to the community, which is something I have not been able yet to do.

Jeff Doolittle 01:06:21 Well, except you did write a book, which is introducing people to the technology. Iíd say in a sense that’s definitely, a contribution to the community.

Jeff Doolittle 01:07:47 This has been a fascinating overview and I’m sure listeners are aware that this is really the tip of the tip of the iceberg. And if they want to dig deeper into Dapr, I mean, we didn’t really have time to get into two of the other building blocks regarding secrets. You know, you mentioned observability before as something that you always wished you had. And, and now, you know, I would say secrets management is another one of those that a lot of us are always ripping our hair out about like, why is it so, hard? It’s getting easier, but, but still, and then also, the actor building block is so, powerful. We could honestly probably do a whole episode on actors and how Dapr enables actors. But I definitely want to encourage listeners to check out Davideís book. You mentioned the discord channel for Dapr, and there are other books as well.

Jeff Doolittle 01:08:35 And there’s the community calls related to Dapr for those who want to get involved. And just a reminder, this isn’t a Microsoft or a.net thing, although that’s sort of its Genesis, but Dapr is written in go, the building blocks are written and go. And there’s lots of contributions from lots of different communities, which really bears a lot of promise for the future we want to have, which is teams can use the tooling and toolings and languages they’re familiar with but adopt standards for inter operation with other services. And that’s sounds like a future. I want to be a part of

Davide Bedin 01:09:09 Absolutely. And keep using the language, the one they prefer, they need the frameworks they need and also, be a language agnostic, but also, be able to offer to your customer, to their customers, an application that can move around everywhere because the world is getting more complex, we are just playing more and more important roles. So, probably I tend to think as the local environment, as the development environment, but as mum group, it can be even more rich, even off site of Kubernetes environment.

Jeff Doolittle 01:09:53 Absolutely. Well in the book there’s also, some of his repository with code examples and walkthroughs for our listeners as well. But if listeners want to find out what else you’re up to, where can they go?

Davide Bedin 01:10:04 Yeah, you can find me on Twitter and on LinkedIn. My alias on Twitter is @bedindavide and the same on LinkedIn and that too and absolutely can ping me if you want to know something more about Dapr. But I encouraged to go to Dapr, which is the starting point for Dapr, and then read the documentation on Dapr and start from there to learn more about this rich ne runtime.

Jeff Doolittle 01:10:41 Well, Davide, thank you so much for joining me as a guest on Software Engineering Radio.

Davide Bedin 01:10:46 Thank you very much. It has been a pleasure. Thank you.

Jeff Doolittle 01:10:49 This is Jeff Doolittle for Software Engineering Radio. Thanks for listening.

[End of Audio]

SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)

Tagged as:
Join the discussion

More from this show

Menu

Recent posts