 The final speaker of the day, Macro Services Architecture. It can provide a number of benefits like modularity and scalability, but implementing a microservice architecture is very difficult. So what to do? Well, our next speaker says that we can overcome these challenges using DAPA, a portable runtime. Let's meet Carlos Mendible, Cloud Solution Architect at Microsoft. Carlos, great to see you. Thank you so much for coming. It's so nice to have somebody here in person in the studio as well. So when you're ready, the floor is yours, all set. Thank you. Thank you for having me here. It's a pleasure. So I don't have a slice here. Oh, no, no, OK, so now I have it. OK, so now thank you for having me here. I'm going to talk to you about how to overcome these challenges with Evan Driven Microservices today. As you know, the world today is really distributed, but we started and still today we have applications or solutions that are created or deployed as monoliths. And when we have these kind of services or solutions, we have solutions that are probably easy to test, even easy to deploy, they can scale vertically, but we have issues with that or challenges. What happens when you have this solution for, let's say, many time and you want to, sorry, and you need to fix some issues. Then the slightest fix that you deploy can break all the solution. You may have issues trying to use new technologies, and that starts to be cumbersome. So today we have these kind of distributed solutions or applications. We break down these monoliths and different solutions or programs, and with that kind of solutions, there are new challenges. So these new challenges are how do these new services that we decoupled or how we decoupled those new services, how it does these services speak with each other, how do they discover each other, how can we observe these solutions end to end so we are sure of what's happening and we discover any kind of error or issues that it may have. So there's a bunch of challenges there that we have to address. And basically today I'm going to talk to you about Dapper, which is a runtime that's going to help you with those tasks. So it's not just about shielding your applications from these challenges and help you overcome them. It's about also helping you developers to not have to spend that much time learning all these services and solutions that I'm showing you in the CNCF diagram that you're watching on the screen right now. It's about making your developers spend their time on your business logic and your solution and not learning all these services and not tiding your applications or coupling your applications to the SDK of the infrastructure that of your choice or your platform of choice. So Dapper helps you with all these challenges. As you can see, you have in the top row of the diagram I'm showing right now or the slide, you have some languages just as go, no.net, you have C++, you have Java. And Dapper is going to support all those languages through SDKs, but basically you can use any language that you want to talk with Dapper. If your language is capable of using HTTPA APIs or GRPC APIs, it's going to be perfect. And then Dapper is that middle blue ribbon that you have there in my diagram on the screen. And those are the components that Dapper is going to help you to use. And with those components, you're going to be able to abstract yourself or your applications or your solutions from the layer that's in the bottom that basically is the platform of choice where you're going to run your application. You can use Dapper on Azure, AWS, Kubernetes, on-prem, wherever you want. And it's not just about abstracting you from that platform. It's abstracting you from the underlying services that you're going to use. So let's say if you want to use a database like MongoDB, you can do that perfectly. But if you need to switch your code and not use Redis, perhaps, you can do that with changing any line on your code, just telling Dapper that you're using a different component to communicate with that kind of store. OK, so let's talk a little bit about Dapper and its built-in blocks. But before, oh no, sorry, I'm OK here, these blocks are service invocation. It's going to help you discover services. And let's say if you're deploying this inside Kubernetes, it's going to be pretty straightforward to find the services. It's going to let you communicate between services in a secure way via MTLS. You're going to have state management that's basically going to help you with all state management. Let's say you have like microservices that is charged of a cart, a shopping cart, then you want to save that information in state. Well, you're going to do that pretty easy with Dapper. And you have PubSub component that's going to help you overcome asynchronous messaging challenges. You're going to have bindings that's going to help you react to external services or resources events. And you have observability. Of course, you're going to be able to track everything that's going on through your solution. You have the secret components that's going to help you get your connection strings or whatever secret you need to run your application. And finally, you have the actor model that's going to help you with solutions that have to deal with concurrency. So before going in detail in each of those components, let me tell you a little bit of how Dapper works. Dapper is always going to work with a sidecar architecture. You're going to have always Dapper running in another process. So it's isolated from your solution. And what that means is that you're going to be able, as stated before, to use any runtime for your application. Let's say .NET, let's say Java or whatever. Meanwhile, Dapper is going to be running through a go process because the language is programmed on. Then you can have many hosted environments. You can use this in your local host, your PC, your Mac, your Raspberry Pi, if you may, IoT devices. You can do run this in a virtual machine. You can run this inside Kubernetes. And when you run this inside Kubernetes, be aware that Dapper is going to install at least four components there. You're going to have the operator that's in charge of tracking all these components and making sure that they are bi-level to your application. You're going to have a sentry that's the certificate authority that you have for your cluster and use it with Dapper. You're going to have a placement controller that's going to help you with the actor model. And of course, you're going to have the sidecar injector that's basically going to be aware that when you are going to enable Dapper for a pod in the case of Kubernetes, then it's going to inject inside that pod the Dapper sidecar so you are able to use it. Let's dive deeper inside each of these components. We have state management. The diagram I'm showing there, it's pretty straightforward. Basically, you have a basket server, like your shopping cart. Now that you know you're talking with a sidecar, the way you save this information inside Redis, in this case, is talking through Dapper. So you make a simple HTTP post call. You're using the state API. And you are just saying, I want to save in this state store, which that's the name, but it could be MyDB or whatever. I want to save these JSONs inside that Redis. But you don't say anything about Redis. You just tell the name of the state store. Dapper is abstracting you and shielding your applications from the fact that you're talking with Redis. So there are many database and other services that can help you with a state store. You can use MongoDB. You can use SQL server. And Redis, in this case, Postgre. And you can go to the web page and check which are all the other components that are available for you in state management. Just to finish with this component, this component is all going to help you with transient errors when trying to connect to those storage. It's going to help you manage concurrency. And basically, it's going to help you when you have these kinds of solutions that not all your services are going to talk with the same database. So your developers are not spending time learning Redis or Mongo or whichever solution you want to use as database. They are just talking HTTP with a Dapper sidecar or using the corresponding SDK for your language of choice. And you're going to be able to save all this information. Service invocation. So that's other of the challenge I mentioned when I started, right? How do we call from service A to service B? It's not a direct connection. We're going to go always through the Dapper sidecars. And as you see there, all calls are local. So if I want to go from service A to service B, I'm just going to call my sidecar local host. I'm going to call the invoke API. And I'm going to say I want to invoke which service. That's the name which you use to register this service inside Dapper. And then what's the method you want to call it? This case is the catalog items. And Dapper, it's able to find the other sidecar. In this case, the service B sidecar. And it's going to talk securely between them. And it's going to do it with MTLS up there. And so it's secure, of course. And then the second sidecar is the one that's actually going to make the call to your service inside your pod. And if you're running in Kubernetes or side by side, it's in another environment. So what about asynchronous messaging, right? You want to decouple your applications, your microservices. You want to decouple them. You want to use perhaps rabid MQ. You want to use Azure Service Bus. You want to use Kafka. But if you do that, as we are used to, you're going to tie your application to that solution. If you don't want to tie that, you can use Dapper, of course. And it's going to help you with this. So basically, you're going to have your services that subscribe or your services that publish messages talking directly to Dapper or receiving those messages from Dapper. And that's going to shield you from all the issues that you may have with PubSub. And it's going to at least deliver each message once. So in the diagram, you can see that you can use either rabid MQ or Azure Service Bus. And that's just a choice of the component that you deployed with your application. And when I say you deploy a component, you're going to see that in my demo later. But it's basically a YAML file where you're saying I'm using this PubSub or Redis or whatever. What about bindings? Bindings is a way to react to external events or send events to external resources. So in the diagram I'm showing here, you can see that Dapper is reading message from a Twitter feed and basically sending those messages inside your service. So you can read those messages, save those messages. I'm going to show you in the demo that you're going to be able to analyze those messages with cognitive services. And once you do that, perhaps you want to send an SMS or you want to send an email through SendGrid, perhaps, then Dapper Bindings is going to help you with that. So you don't have to deal with how Twilio works or how Twitter works or HTTP triggers work or Cron even. Those are components that are there. You have Apple Push Notifications supported. So Dapper is shielding your application and your developers from all that cumbersome stuff. And you're able to react in a serverless kind of way to those events or send events to the outside world. And it's pretty neat. Of course, any of this wouldn't make sense if you couldn't be or if you couldn't monitor or observe what's going on with all your solutions. So Dapper is going to expose the metrics and the logs and the telemetry necessary for you to be able to track everything that's going with your solution as long as you're using Dapper, of course. And the way it does is it's that's pulling this information through open telemetry or open standards. And by default, it's going to send that to SIPKIN server if I may. So once again, you can plug any logging solution once you're using Dapper because Dapper is exposing all this information through open standards. So again, it's pretty easy and straightforward. And you're going to see that in my demo in a couple of minutes. What about secrets? I want to handle connection strings. I want to handle certificates in my applications. I want to handle certificates. And I want to do that all in a secure way. So the way this works is you can use Dapper to talk with, let's say, an Azure Key Vault as the platform or infrastructure you're using, but you can use Secret Manager from GCP or AWS or even you could use HashiCorp Vault without any issues. Just making a simple, as you can see, a simple get call to your Dapper, which is going to abstract your application from the way each of those services work. So a simple call to the Secrets API that Dapper exposed for you. You give it the name of the Secret Store you're using. In this case, it's Secret Store, but it could be My Key Vault, by instance. And then you give it the name of the Secret or key you want to read. And basically, it's going to return that payload as JSON. And again, this is like the raw HTTP call, but you can do it with Dapper SDK of your language of choice. And to finish with the components, we have the Actor Model Company. And if you have to deal with concurrency in your solutions and you're working, sorry, and you need to find a solution that can help you work with Secret Units of Compute, the Actor Model that comes with Dapper is going to be really helpful for that. And it's going to shield you and your devs from the difficulties that you may encounter trying to deploy or create these kinds of solutions by yourself. So you can explore that if you're interested. And I'm not going to dive deeper inside this component. So now I'm going to go and show you my demo. And I hope you enjoy it. OK, so let me show you what this demo is about. We have a Twitter producer microservice that receives tweets via Dapper and basically saves those tweets in database and state and then publish that to an asynchronous message solution. Redis in this case, I'll show you that later. A Minecraft bot that subscribes to those messages receives those tweets and sends a post to a Twitter sentiment service that basically calls Azure Cognitive Service to analyze the sentiment of the text. And once the Minecraft bot receives those scores, the Minecraft bot posts that to a Minecraft server that we have here. And it's not shown on the diagram. So let me show you how that looks inside Kubernetes first. I'm going to show you this in K9s. So we have here the Dapper system namespace. That's what I'm showing you. So you can see that we have the operator here, the placement, the sentry, and the sidekiller injector, those services that I talked to you about before. That's what Dapper deploys inside your cluster in this case. Let me show you the default namespace where I deploy my solution. So you can see here the Twitter producer service. I'm going to show you the logs. And as you can see, right now we're receiving some tweets live. And again, let's see, where's the hashtag? You can see it here. It's La Palma. So we're receiving it down here. We're receiving that information live. And logging it to the console. Then we have, of course, the Twitter sentiment. It's just logging the scores. So nothing more to show here. And we have the bot I was talking to you about. And as you can see, it writes down the message. And it's also writing down the score. So basically, this is working. And last but not least, let me show you the Minecraft server. So you can look at it here. And you can see that the bot, which is named after my daughter Vicky, it's basically sending to this Minecraft server the tweet with the score. So that's basically everything from inside the cluster that I can show you. So let's see what this looks like in code and YAML, right? So this is what the famous components I've been talking to you about look like, OK? This is the Twitter binding component that I'm using. We have a bunch of information related to how we connect to Twitter. That's what Dapper is using to connect to Twitter. And look at this down here. Well, first, we're querying the palm as I told you. And look at this. We're using a secret store named secret. So all this information that we have up here, all this information, that information is coming from a secret store. So let me visit that secret store just a second. We have it here. And again, this is a Dapper component. It's named the name is secret. And we're using in this demo an Azure keyboard. But as stated before, you can change this with a local JSON file, environment files. You can use Secret Manager for any other cloud provider or even something that you have on-prem. And this is the information related to how we connect to that keyboard in this case. So going back to the Twitter component, you can see here the secret drafts, right? So this is extracting the information from the keyboard or any other secret store that you're using in your case and injecting that on the component itself at runtime. So the last thing I want to show you here is look at the tweet's name for the component. That's the name I added to it. And I'm going to show you on the right side the code. This is a ASP.NET Core application. So I'm using the SDK that's created for.NET and Dapper. I'm injecting the Dapper client here. And this section down here, it's where we're saying subscribe to any bindings that are needed. And look at this. The route that I'm exposing in this application is named tweets. And it's no coincidence that this is the exact name I'm using in the component, right? So it's mapping all the tweets it receives. It's posting, Dapper is posting that information to the tweets route on the right side. So once we receive those tweets, and we receive the text of those tweets here, what we do is we save that information in state. And it's really simple. Look at that. We're using a state DB. We're using ID and the body of the tweet. That's all we need to save state in our microservices. And down here, after we do some crunching, I'm just polishing that event to an asynchronous messaging solution named message bus in a topic called tweets with a crunch message here. So that's it. That's easy. We don't have, let me show you up here, we don't have any SDK dependency on Redis or on a specific database or even on RabbitMQ or whatever. We're just using Dapper, right? So let me show you what this state DB and the message bus looks like in terms of Dapper components. I'm going to switch out to the left side here. This is the state component. It's named state DB, and that's why we're using this name on the right side here. We're using Redis. Again, this is all the information related to how we connect to that red instance. And we're using the secret store to retrieve those passwords. And again, this is the Redis state component that we could be using any database that we will like, and as long as it's supported by Dapper right now. And the message bus component, you can see it here. It's named message bus, and we're referencing that on our service on the right side. Again, this is all we're using to connect to the component, secret reference, and we're using Redis, but we could be using EvanHubs, RabbitMQ, or whatever. And we would have to change a line on our program on the right side, and that's pretty interesting. For convenience, I use Redis on my Docker and on my PC to test this solution. And for convenience, I also deploy the same Redis component inside the AKS cluster, the Kubernetes cluster I'm using. But of course, you could change that to whatever your real needs on production are. So you can work with some components on your developer machines or even on-prem. And then when moving this to the cloud, you can change the components depending of what the real needs are without having to change the code of your services. So how do we put your microservice with the components together? Well, basically, you deploy the components inside the Kubernetes cluster. And then when you deploy your application, you have to tell Dapper to inject the sidecars by enabling Dapper through an adaptation here. And given that service a name just for service discovery, telling Dapper what port your application is listening on, so it's capable of posting, in this case, the twist to your Twitch route. And telling about the tracing configuration that basically enables what I saw you first, the tracing, and in this case, all the metrics that we can see in SIPC. That's like the Twitter producer service. Then we have the node microservice here, which is basically the bot. And look at this up here. We're creating a route, this Dapper subscribe. This is where we're telling Dapper that we want to subscribe to PubSubname message bus, that we want to hear anything that's received on the topics named Twitch. And to please ready take all that information to a local route that's called Twitch. So we're going without SDKs in this microservices. Microservice, sorry. And down here, you can see this is the Twitch route. We receive the raw data. And we're using Actions to post that to the sentiment microservice. And you can see up here that the URL we're using is, we're calling local host on the Dapper ports or we're calling our sidecar and invoking the Twitter sentiment service and the sentiment method. So once we receive the score, we get it here, down here. The last thing the bot does is chat or post that information to the microserver. That's it with this service. And let me show you the sentiment service, sorry. So again, this is an ASP.net core application. We're using Dapper here. And this line here is really interesting because I'm using the SDK here. And what this line does is it's telling Dapper to inject all the secrets that it finds on the secret store named secrets inside my configuration in this solution. So what this is doing is loading all those secrets that I had in the keyhole I mentioned before as configuration inside this application. You can see we're exposing a sentiment route. And down here, we're reading that configuration in the cognitive services key. This is what we're going to use to call the Azure Community Service and do the sentiment analysis down here. And once we receive the score, we basically write it to the logs that was what I showed you and return that down here to the bot microservice. So basically, you just saw the defining some components on the left side and deploying that to your cluster. And then using the Dapper SDK, which lets me go to the producer again, which lets you save state or publish down here very easily. The information, you can do it with the SDK, right? And you have a direct dependency on your code with Dapper. Or you can use a manual approach, like I did on the Node application, where we're basically doing raw calls or subscribing to events, just telling Dapper via some explicit route that we want to subscribe to Message Bus with this topic and where to send that information, right? It's really, really, really that simple. So going back to the diagram here, let us refresh a little bit. Let me start again here. So we can run the query. Since all the calls that you saw that we're making are being done through Dapper, we could see all the telemetry related to those calls, right? And of course, the dependency tree that we were looking at when we started. And here you see, again, the Twitter producer, the Minecraft bot receiving that information and a Twitter sentiment doing something. And you can see here clearly that I have some issues there that I should repair in the future. But I think you've got the sense of what we can do with Twitter, with little code, almost no dependencies on the features that we're using in this case in the cloud. You didn't see any line of referencing the keyboard, for instance, directing our code, but through Dapper, we're abstracted from that. So that's basically what I wanted to show you today. I had one, but it's not showing up here. I don't know why. So, well, that's basically it. I hope you had a glimpse of what Dapper can do for you. If you wanna learn more, you can go to the webpage is dapper.io and you will learn a bunch of that. We have a Discord server. You can join anytime, talk to me or any other of the contributors of the project. And there's also a free ebook you can find online too. It's called named Dapper for .NET developers. I know many of you are not done at developers, but it's a pretty straightforward book to read. It's really simple and it's gonna help you understand how Dapper or how can you adapt Dapper in your solutions. So, that's it. Oh, now my slide is in here. Feel free to scan that QR code for more information. And thanks a lot. That's great. Carlos, thank you so much. What a great way to end our talks here in track two. So we do have a little bit of time for a few questions. So if you're ready, I'll fire away. Oh, it's okay, fire. Emilio asks, if we need to connect real time, is the bus shared? And I think he's concerned about performance issues. Okay, so, well, first let me address the performance part. Dapper is reading, sorry, reading in Golang. It's really performant. Usually, the impact on your applications is gonna be under the millisecond, right? If you're worried about how live this information is gonna enter your application, it depends on the service, what you're gonna consume and the bindings you're gonna use. What I show you in the demo basically is getting all the information live from Twitter. It was kind of slow because I didn't use like a popular hashtag, but I'm sure if you put like COVID-19 in that sample, it's gonna burst all that information inside your solution and you're gonna have to process it as fast as you can. I don't know, I hope I answered your question. I hope so too. So, a final question for you, Carlos. How does Dapper compare with service mesh solutions? Okay, that's a question that appears when we talk about Dapper because we talk about observability and we talk about securing calls between services. So, yes, we have that MTLS there. So it's a gray zone, right? But there's a difference. Dapper abstracts you from things that you have to be aware in your application and the services you have to use. Service mesh are worried or address an issue with networking. So let me try to explain it this way. You probably are not gonna see Dapper ever dealing with AB traffic splitting. That's something service messes do for you. And you're not gonna probably see any service mess abstracting you from a database or Azure Key Vault or a secret management solution. So I hope to answer your question when that went too. Carlos, that's great. We are now rounding against the clock. So all that remains for me is to thank you once more. Thanks very much for this amazing talk, for your time and for the demo. Thank you very much, Carlos. Thanks a lot. Thanks for having me.