Okay, so hello everyone and thank you for watching my session about the perfect time. I am Christoph Gig, a cloud search architect at Hagi Group, and also I'm MVP Microsoft. Before going deep into, at that point in time, let me just remind remind me, remind us what is a microservices architecture? Why do we often choose a microservices architecture? First, we want our microservices to be focused on a specific business aspect of our solution. This allow us to gain. More autonomy, flexibility, and scalability. And it allows also the teams to be more flexible independent into the development and the deployment. In summary, what we want smaller services, but more efficient. Of course, this comes also with some difficulties. So for example, the debugging process and the testability. For example, you want to debug a feature or a fix a bug that implies a lot of services of your architecture. You have to run all your services in your local environment. This increase the complexity of your architecture and, you also have some difficulties with the, in interdependencies of your service. At the end, you just doesn't understand what is going on in your solution and also you don't master and you can manage properly the flows inside your application. To summarize this, it's difficult to migrate from a monolithic block to a microservices architecture. And today the languages and the framework that you use are not natively oriented for microservices at the end, about hosting model. It's not so much true today, but application tied to a specific infrastructure. Platform with limited portability to cloud or Edge. And that's why Dapper comes to the landscape. Dapper is the acronym for distributed Application Runtime, and it's it's portable, even driven runtime for building distributed application. And you can run it in the cloud or in the edge. Dapper comes with very specific objectives for you and for developer teams. It comes with best practices and some building blocks. So for example if you install dapper on the local machines, it'll on the shelf comes with some blocks that you can already use for your applications. We will go through it just a little bit later. You can use any language or framework that you want with dapper. And it's C Driven, it's a non-commercial initiative and it's into the CNCF ecosystem today. It'll allow us. To adapt some standards into our architecture. I will come to it just later also. And it's built on a consistent portable and open APIs. That means that you can very easily interact with the run time if you want to. It's platform agnostic from cloud to edge. That's because it's built on containers technology and it's really sensible with pluggable components. Today they are more than a hundred components that you can use on the shell with de but of course you can create your own components with the extensible aspect of dapper. About the basis of dapper. First you have to understand that dapper implements the sidecar pattern. That means that when you launch your service automatically, dapper sidecar will come in live just aside of your service and. With this side care partner, that means that every interaction that you do outside of your service will be handled by dapper. That means that your code only knows about dapper as an external dependencies, and that's. That's only that your call will know. For example, when you want to invoke another service or you want to store some data in the database, you will go through Dapper to perform this action and your call will. Your code will be agnostic from the the technical implementation of the component and the end. For example, we have here two example. You can interact with Daer through H TT P or GRPC, and the first example will tell Daer to store some data into the state that you mentioned into the URL. So you tell the pro. To store the data and dapper will take care of the implementation details of the database at the end. It depend, in fact it's everything about configuration into dapper about the component you have at the end. The second example is service to service invocation. So here the example it said that I want to invoke the service, my app and the method new order in that. In that service, that's mean that dapper will automatically perform a service discovery process and it'll automatically also call that method in the right declared service into dapper. Like I said, you can use any languages or framework you want with Dapper because it built on ER technology. And then you will call some H-T-T-P-A-P-I or G-R-P-C-A-P-I to perform some external interaction that you could needs to perform for you business logic. So you can do. Service to service, invocation, state management, pop sub resource binding and triggers and actors pattern if you want to distributed tracing and the secrets and so on. So what you need to keep in mind is that dapper his a set cap pattern. And when you want to perform some external operation, you will go through dapper to perform that action. So you code, your code will only focus on the business aspects of your solutions. And everything else will be handled by by dapper all the external Interac. So here is an example of the sidecar model I just mentioned. So when you have one service, one sidecar will appear just aside of your application, and then you will call some API to perform some some action on the, so you can invoke another method in another application you can store. Or retrieve some states stored in a database that you configure into daper. You can publish a message, so you can publish and receive messages with Daper, and you can retrieve some secrets that are stored and handled by by dapper. For example here is a local example of a very simple architecture with daper. So I have a service A and a service B, and each of those services ha has a side car, a dapper sidecar just aside of tool service. And then after that, I will configure dapper. About the state store I want to use, or the event broker I want to use, and so on. For example, for the state store, you could use a DBE or Cosmo DB or Redis for the purpose. You could use Arabic MQ service Boost what you want. So the implementation details is only into the dapper configuration, but your service doesn't know about this detail. It only knows about how to interact with dapper. And I can just show an example of of that. So we'll just switch to my vs. Code editor and then. Here I opened one of the repository GitHub repository of Daper, which is the QuickStarter repository. And inside of it you have a lot of example that you can reproduce for you solution. Here, what I will show you is a very simple example so that you can understand how it works. For example, here I have an not GS application. That not GS application expose a very simple a i to get an order and to create here a new order. In for the application to get the data, it'll store a new order and get a new order from a particular database. But here the application doesn't know about the database. It only knows about Daper. So here with the URL, we will use to store and retrieve. Do data. We are working locally, so we will use local host. The DA Power is by default 3000 and, oh no. 3000, sorry, is for the no GS application port. It'll use 3,500 ports for the for the port for Daper, in fact. And then I will use here the statue RL and I give to Daper a name of the state. That was configured for Daper so that he will know that this particular database is tied to a particular name, and that's what I will use in my code to store the data. In order to launch the. The application with dapper, I will use the dapper CLI. So first you have to install the dapper CLI in your local machine. Everything is explained on the documentation. I will not. Deep dive into it because it, it's really simple and everything is explained on the website. And then you have to launch the dapper in it common line in order to install everything you need on your local machine for dapper. So I've already done it in the past. So then when everything is set up, you can use the Dapper Run. Command with the app ID option. This tells dapper what is your ID of this particular service into your microservices ecosystem. And this ID should be unique per service, of course. So here I will use the option with the Node app value. The app is like I said 3000. And I will, just to be sure, I will use this option to tell us which poor Daper will use. So Daper, HTT, PPOR. And at the end, I will just tell Daer which command he need to use in order to launch my no just application. So to launch a no J application, I will just use node. App es So this is the command I need to use. I'm just not in the right in the right folder. So let me just jump into the right folder. Hello world, and no. So I will just copy past. The common line, so dapper run up Id upper and not ab Bs. When you launch that command you have a lot of logs. In fact I will not go into everything, but just to show you what the portal tells when you launch the runtime. So first you have in blue the logs of your application. So for example, here I can see that my. Applications is correctly running on the, on this port. And then about the dapper logs, you can see that it's loading a lot of components. So the state store components here, we have a Redis component, which will be used by the example to store my orders. What you need to know actually is when you launch dapper the first time, it'll, when you launch an install dapper the first time, it'll install some container images on your local machine, and it'll in fact install a Redis container. In in your machine. And when you launch the dapper or runtime, it'll automatically launch a new container, a new Redis container, and that's what is configured by default. When you launch dapper and by default, this will use the Redis State Store. So here is the component for the state store, and by default, there is also another configuration into Daper for. Pop sub component. And this is also release. So if I check the log, I can see that everything works correctly. Application discovered on this pro not app, everything sh sounds okay. Daper initialized that you running. Okay. So apparently everything is good. I will just show you. Something else. Yeah, I will create a new terminal here. And what does that sample do is? So we have one microservices in in in no gs, and we have another one in Python here. This Python is only a simple client for the node node application. And it'll only create new order in a loop infinitely. Indefinitely. And this will use Daper as a sidecar for the patent application in order to call the nudges application. So the patent application doesn't know or doesn't call directly the no G application. It'll. Only called dapper and dapper will forward the request to the right service. I will launch that, that that application too. So tutorial hello word, Python, and also for Python. I will also use the Dapper Run app id Python app, and then I will just tell Dapper which command will he should use to launch the application. So Python app from pi. Like I said this is just an infinite loop that call the API in no Gs. And then I can see that in my log from the NO GS application, the Python application correctly reach the no GS application to create new order in the loop. So that's really easy. So let, as you can see, my code is really clean in term of external dependencies. I only use Daper with standard API. So here it's HTTP and when I want to perform some external action service to service invocation State store for the Knowledges application, I only use Daper and I don't know implementation detail of my infrastructure dependencies. Okay, so I will just stop this and then we can go again to the slide. This is just a recap of the the demo I just showed. So we have a frontend application and a backend application. Both has their own side card app and when I want to invoke one service from. From the first microservice. So for example, the front end I call dapper through a standard a PA, and then dapper will automatically forward the request to the right microservice behind. That's how the service invocation works. Of course. At the end, the ultimate goal is to deploy in production DAPER. And then the recommended way is to use Kubernetes. So when you initialize DAPER on Kubernetes, it'll install four system pods into Kubernetes. So I won't go. In deep details into each pod because it's well explained into the documentation and it's not the the goal of this session, but you have the actor placement pod. The sidecar injector po the century. This is for security and operator. For example, the sidecar injector will handle all the injection of the sidecar pattern into each po. Of of your microservices architecture. So each each container that he's deployed. Into Kubernetes. It'll be added to a pod, and that pod will have a new sidecar instantiated into the pod with your container. And then when you have this setup you just have to configure Daper like you will do in the local mode. You configure Daper to tell. Which infrastructure component you want to use for the resource binding state store and so on, and you code into your microservice. We only talk to dapper into your cluster. In order to perform some external external operation. And then with that architecture, you can deploy Daper and your service everywhere you want. It could be Azure, double ES, or on the Edge OnPrem as you want. So about dapper components. So we have plenty of component for each category that dapper supports. The configuration is done through ML file files, and you will put here every details, in fact, every implementation, details that dapper needs to needs to to get to connect to those components. So you have a dedicated DML file for state store, for purpose broker, binding SE store, and so on. And for example, for State store, if you choose A SDW db you have one YML file that will handle or will get all the connection details to in order in order for Daer to connect to that db. It's the exact same principle for everything about daper components. Here is an example of a pop pattern with Daper. So here I have three microservices. That needs to exchange messages between those microservices. So first on the left, your application will post a new message or publish a new message here to Daper. Daper will forward. The message to the correct broker that is configured with the YAML file. So here is, it's already c and then all the service that listen to that particular. Topic will get the message. How it works is in that way your service a b will expose an a p that Daper will call when he when he when it receive a new message that, how it works. So it'll push a message to a particular API declared in in taper. For the telemetry, it's mostly the same the same principle. So dapper implements the open telemetry standard. So all the tools that that implement that standard a site, Datadog premises and so on. You can use any component you want. Link it, linked it to to Daper. And you can just, in your application log what you want in your call, in your code, and DAPER will gather the log and send it automatically to your tool. So it's and then with that principle, you can change the tool whenever you want, because you have that standard open telemetry in the middle. Just to finish this session, just a reminder about the projects in the CNCF context. DAPER was accepted as a graduated CNCF project in November, 2024. And as you can see, the community is very big and a lot of big company already added this. Technology in their stacks and already using it in production. So it's a very big project today and very solid and reliable in term of cloud deployment today. If you have any question or feedbacks, don't hesitate to reach me. On Blue Sky or on LinkedIn. I'm very open to, to question about dapper and I really encourage you to check the GitHub repository and the community around dapper. And why not make some contribution or use it in production for your microservices architecture. Thank you for watching and have a nice day. Thank you.