 Awesome. So we're just going to go in here since it's 12.05 and this is a guide to dapper open source APIs and SDKs for developers. And my name is Alice Gibbons. I'm a customer success engineer at Diagrid where our mission is to boost developer productivity by providing tools and APIs for building cloud native applications. And I'm Samantha Coyle. I am a software engineer here at Diagrid. So I get to work on some of our product side of things as well as help contribute to the dapper community. Awesome. And so today I'm just going to walk you through what we're going to go through. I'm going to start with a dapper introduction. For those of you who haven't heard of dapper before, I'm going to pass it over to Sam to do the demo application overview and talk a little bit about the scenario that we're trying to enable with dapper. And then she's going to dive into the service invocation API and some of the details around that. And then I'm going to talk about the pubs of API and give a demo and then we will conclude. Okay. So let's kick it off with a dapper introduction. So it's nothing new to say that there are a ton of developer challenges that devs have to face every day when writing distributed apps. There's a number on this slide here but things like encrypting your calls between services for distributed systems as well as ensuring you are sending messages from two multiple applications and locking down which apps can receive those messages. Securing access to the data layer. The list really goes on. And dapper provides APIs to help developers solve some of these issues. So actually just a quick show of hands. Who here has heard of dapper? We got one. Awesome. So dapper can be described as a portable event driven runtime that helps codify microservices best practices and building distributed apps on the cloud and on the edge. And it was started in 2019 by the co-founders of our company when they're at Microsoft and then it was donated to the cloud native computing foundation. It has been open source since the very beginning. Yeah. So what are the dapper APIs? There's a number. There's around 10 different building blocks that you can take advantage of today. You can write them in really any language that you want to. There's a list of languages on here but you name it.net, JavaScript, Java, C-charp. There are tons of SDKs as well as you can use the HTTP and GRPC APIs via native clients for each of these languages. Here's a list of the building blocks that we have. And they can be deployed. These applications can be deployed on any cloud or edge infrastructure. Typically in production dapper is deployed on Kubernetes. However, you can compile dapper without a container dependency to deploy it on virtual machines. So how does it work? Dapper runs as a sidecar pattern typically. Although there are projects out there to run it not as a sidecar. It typically runs as a sidecar. And again, it can be used over GRPC or HTTP. And as mentioned, you can use the native GRPC or HTTP clients within the language that you're writing in. Or you can take advantage of the dapper SDKs which provide a few niceties on top of the language. So here are some of the APIs that you could call out to once your application has the dapper sidecar available. And you can see they're all running over localhost due to the sidecar nature. And this is really great for when moving from, you know, development to production and through staging environments because essentially the URLs you're calling out to don't actually change, right? So you can, you know, promote your app all the way through from DAV to prod and essentially call out to the same URL across the board, which is great. So some of the URLs on here, there's a ton of different ones. We have like the invocation URL. So for invoking other services through service discovery, as well as like the publish and subscribe to the publish URL on here where you're publishing messages to a topic or even kicking off a long running workflow, like a staple workflow as well. So how do these enable or how does dapper work with infrastructure? This uses what's called dapper components. And these are essentially swappable declarative infrastructure files or infrastructure configuration files that have the infrastructure connection data embedded into them. And these are written in YAML and there are a number of them that were contributed by the community. So there's over a hundred components available. They're all open source online written in Golang. And you can check them out at the components contrib repo. And you can see a number of them on here, you know, they are typically like all the cloud providers are supported as well as components that you might use on premises. If there is components that are not available for the system that you're trying to write, you can easily contribute back a component either to your community or to the community for everyone to use. Or, you know, we have lots of people that actually write custom components for proprietary systems. And they are all pluggable. So dapper has a really nice feature about it, where these components are pluggable and you can swap them out really easily. So on here is like kind of a typical, let's say, distributed system. So you have maybe you have a service and it uses some sensitive information. Maybe it publishes a message on some sort of pub sub broker. And then you also have, you know, a subscribing service that is storing some of this within a database or a key value store, you know, nothing, nothing crazy here, just three services. But, you know, you've enabled them all with dapper. And, you know, maybe you are running this on premises or you're running it on your local development machine. And you've decided to use some of these infrastructure pieces. You're using hashy gov vault for your secret store. You're using rabid mq as your pub sub broker. And you're storing your state within like a reddest cache, let's say. So what dapper actually enables you to do is swap out these infrastructure pieces without changing any lines of code. So, you know, maybe your business requirements change or, you know, maybe you are trying to enable AWS like cloud infrastructure for whatever reason. You can use AWS cloud native services such as KMS, SNS or like a DynamoDB with zero lines of code change from your application. And the same would be for like Microsoft Azure, right? So you could swap out for Key Vault. You could swap out for an Azure service bus. And you could use Cosmos DB again without having to change any of your application code because you are using that dapper abstraction. And this is huge, right? In like the era of multi-cloud and like microservices applications, there are a ton of people out there who have these requirements to either rerunning multi-cloud or to be running on multiple platforms that, you know, use dapper every day. And so there's no surprise that there's a ton of momentum around the project. There are over 22,000 GitHub stars on the project. And you can see this nice little contributor graph on the bottom right here of the contributions month over month. It is the 10th largest project within the cloud native computing foundation. And it is an incubating project. I think I mentioned that. And, you know, there's a ton of steering committee members from different organizations. As mentioned, it was developed at Microsoft. But since then, there's a ton of uptake from orgs like Alibaba or Intel. And yeah, there are over 300,000 docs views a month, which we're pretty happy about. So a ton of different dapper users from, you know, giant hyper-skill companies like IBM and Microsoft down to really security-conscious organizations like Zscaler and Bosch. And we always like to say that dapper is actually running on the International Space Station. So, you know, the true definition of edge computing, right? And with that, I'm actually going to hand it over to Sam to talk through our demo application and what we're going to show today. Thanks, Alice. So for the open source summit, we actually made a special demo application just for y'all. So, container excitement. And in the dapper community, they have a repo dedicated to all these quick starts, tutorials, and so forth that you can use. But again, we wanted to make a special demo application. And there will be a link at the end in case you want to go back and check it out. And we made it to where you can run it locally, as well as in a Kubernetes native environment. So with dapper, there are 10 major building blocks that you can see here. And for the demo, we will be talking about two of them in particular. One is service to service invocation. So that's the first part that I will touch on and provide a demo on. So within dapper, service to service invocation is really nice. And you get a lot with it in dapperizing your applications. So it gives you direct and secure communication between your different services. And you get a lot right out of the gates, such as observability, telemetry, tracing, and even resiliency. So those are all the things that you would have to think about if you weren't using something like dapper. And after talking about service to service invocation, Alice will cover the pub sub components that are going on in our demo application. And with that, it's the secure scalable messaging, right, using message brokers. So again, Alice will cover cover that part. And actually the workflows component, the workflows is the number 10 building block that dapper has. And some of our colleagues will be covering that here tomorrow. So definitely keep an eye out for that talk as well. Alright, so to share the secret, this is the motivation for our dapper application demo that we created special for y'all. So what you see here is actually the Seguin Volleyball Association. And it's based out of Texas, which I'm a Southern GAL. And this is a community that I like to participate in. And so you can see here, it's a really vibrant community and a lot of activity. And the image on the left is actually from Facebook. So that's how the community organizers will communicate with all of the players. And you have to turn your head to look at what court you're assigned, what your team standing is, and it's just a hot mess. And having a technical background, it kind of makes me sad to see, right? Because we know it can be that much better. So that's kind of the basis and some of the motivations. So we kind of took this idea and applied it to make a v one effort to take the dapper open source project to help this volleyball community. And just to provide some historical context, I'm not just making this up. This is this is me playing. This is my team. So yeah, it's a really fun community. I really like to take part in it. And it makes me really happy to see an open source project. Looking at, you know, how can we make this better? So that's kind of the motivation and storyline here with our demo today. So that brings us to what are the different pieces that are going on for our demo application. We'll start on the left with a volleyball game simulator. So I needed some way of showing to y'all how volleyball works, right? Does it has anyone ever played volleyball before? Well, okay, I'm actually impressed. Okay, so you all know, you play up to 25 points, one by two. In our simulation, there's no cap. So you could play forever. And so we have this volleyball game simulator. And actually, all of our go micros or all of our microservices are written and go using the dapper go SDK. And so yeah, our volleyball game simulator runs for 100 games. And we have, we have the games going pretty fast right now, publishing game score updates onto a Kafka message broker. And so then we have a scoreboard service there. And it's subscribing to our game topic. So it's receiving all these events. And again, it's using that go SDK from dapper. And as we're getting game score, if we have game pointer higher, so if it's 25 or higher, then we're saving that game state. And from there, we also have the scoreboard service retrieved state if we have the volleyball game service, invoke it. And so you can see top right, we have a web UI. And so I made it and I'm a back end engineer. So y'all know the drill, when a back end makes a front end, I added a little bit of color and a welcome message for y'all. That's about it. And so yeah, it'll take a game ID that you're interested in. And then it'll hit the volleyball game service. And what that service is doing is it's using the dapper go SDK to do service and vacation say, Hey, hit my scoreboard service and get me that game score information. That's pretty much it. That's the gist. That's the secret. So now we will go ahead and hone in on the dapper building block for service and vocation. So you can see here, these are the two main services that I will be talking about for the service and vacation, which I kind of touched on already. It's that volleyball game service where you specify a game ID, and it takes it and it makes a post request to our scoreboard service, saying give me game information for game ID one. That's the gist. And it's using the dapper go SDK. And you know, we've kind of kept a high level so far, but there's actually quite a bit that's going on here under the hood. That's totally abstracted away from you. Thanks to dapper. And one of the key components of dapper and service and vacation in particular are app identities or app IDs for short. And so for the volleyball game service, it's app ID is I think it's game service. And then for scoreboard service, it's just scoreboard. And so in a dapper world, that's just how it knows if you want to do service and vacation, which to route that to. So our volleyball game service, we have a game ID in mind. And we say, Hey, from our UI, let's go ahead and enter a game ID. And what that does is it's going to send the game ID to its dapper sidecar. And from there, you can see we're making a post request. And we're sending it to our invoke scoreboard service method scoreboard. So what that's doing is it sending the request to our scoreboard service here, right that app ID to method scoreboard. So the scoreboard handler. And I'm sending over that game ID that I'm interested in. And from there, dapper is looking at its service discovery component and it's saying, Hey, which app ID, which service am I sending this to? And it knows the scoreboard service. And so it sends that invoke method to the other dapper sidecar, which as I mentioned with dapper and service and vacation, you get a lot with it. You get observability, tracing logs, resiliency, all because you're using dapper. So it's, it's really seamless and easy for application developers. Then we finally hit the actual app we're trying to communicate with. So the scoreboard service, we're hitting the scoreboard endpoint with that ID. And now we have our game information, we send it back to the dapper sidecar. The dapper sidecar communicates to the other dapper sidecar through mtls encryption using a spiffy. And from there, we're able to get our game information. So that's kind of a bit more into the weeds on what's going on here. Something else I touched on right is resiliency. So with service and vacation, you do get resiliency right out of the gates. So if for some reason, my scoreboard service was down, right? It could be a transient issue. It could be a network issue. And my game service was unable to communicate with it. Well, dappers got my back. And there's embedded resiliency with service and vacation. So it will try three times with some backups. So I get that retry logic right out of the gates. And I don't have to think about implementing custom logic of how many times do I want to invoke my service and at what cadence, right? Dappers got my back. Alright, so I mentioned there's a demo and we're going to all hope and pray demo gods are with us here today. Alright, let's see here. So let me provide some context. You can see here I have, let me get to the right service. Okay, so I have that game service. So we're coming at it from the perspective of I'm going to be interacting with my web UI. And I'm going to be specifying a game ID that I want information on. And so we can see here we have a scoreboard handler. It's taking that game ID. And it's a really basic go microservice. So I have my go my score handler. And it's doing a really, really basic invocation call here. So this is using the go SDK provided by dapper. And you can see how clean that looks. So I'm just saying, Hey, use invoke method with content. I'm going to be invoking app ID scoreboard at its scoreboard endpoint. It's a post call. And here's my game ID. Here's my content, right? So it's literally that easy to invoke that other service with that built in resiliency, telemetry, observability, and so forth all built in on the scoreboard side of things. What this looks like is I have a dapper service. And then I have a service dot add service invocation handler. So I have that handler for my scoreboard endpoint. And this is doing a really, really basic call to get my state, right? I've given it my game ID, and it's just going to get me my game state, get me that score information. Now that we're all on the same page, we're going to look at my glorious web UI that I've created here today. So you can see it. And now you can see it's colorful. We have a nice welcome message for you all. If you're interested in finding out more about dapper, I have a tab here for you. And if you're interested in the distributed tracing through zipkin, I have that here as well, which I'll show you all. So, okay, maybe, okay, one to 100. What game do we want information on? What number are you thinking of? 50. Wow. Okay, final game score for game 50. We had team 50 versus team 51. And it was actually quite a tight game. Team 50 lost by two because volables went by two. So that's, that's our volleyball UI. And in terms of what that looks like from a logs perspective, you can see here, this is my game service. And I got that response back. That's saying like, Hey, here's game 50, here's who won, here's who lost in the score information. And you can see here, from the scoreboard service perspective, it retrieved state for game ID 50. And one last thing, actually, let me go ahead and show you all because I forgot to show you all this. Okay, pods. Just so y'all know, it's all running. It's all right here. So we looked at the game service logs as well as the scoreboard service logs. And going back one last thing, and let me zoom this in as well. You can see here, this is what's going on. We have our game sim providing all of that load, we have our games going really, really, really fast for y'all. And the scoreboard service is taking that in passing it to the state store on the chance that it's game point or higher. And then we have my game service, which is taking that ID from my web UI and sending that to our scoreboard API. That is the gist. And that is service invocation using dapper. So now I will go ahead and pass it back to Alice for pubs up. I think this is back on. Okay, awesome. Thank you, Sam. And thanks for providing the amazing volleyball context, you know. Okay, so I'm going to talk a little bit about the dapper publish and subscribe API that also, you know, we use in this architecture. So as Sam mentioned, the volleyball game simulator is, you know, simulating people playing volleyball, maybe it's a tournament, let's say it's a tournament, and they have published a bunch of games, and they are publishing on to the game topic. In this case, it's a Kafka broker, but I'll talk about all the different brokers that dapper enables. And then we have the scoreboard service that is subscribed to the game topic and then saving this within a database. And these are both enabled with dapper and they both use a sidecar. Okay, so publish and subscribe. Let's get how this works from a bit more of a granular level. So similarly, just as so as I'm making my post, I have my volleyball game service or my volleyball game simulator. And this is making a post also to local host. You can see the endpoint that I'm using here is the publish endpoint within dapper. And then I'm providing two arguments. I'm providing the game pub sub, which is the name of my message broker. And then I'm providing the topic in this case, which is game. You can also see the data that I'm providing here, which is maybe the game whoever one or the updated score of one of my volleyball games. And what's actually happening here is dapper is making so you're making a network call from your application to this local host app or local host endpoint. And then dapper is making a call on to the encapsulated message broker, which again, in this case is Kafka, but could be many other things. We are using the cloud events 1.0 specification as well to adhere to like another open source standard. But this can also be disabled. If you are integrating with like legacy subscribers, one of the goals of the dapper project is to like meet developers where they are and ensure that we can support brownfield applications. So cloud events is kind of optional. So from a subscribing perspective, dapper subscribes on behalf of your application. So in this case, I have the scoreboard service and my it's dapper sidecar is going to subscribe on behalf of it to that Kafka broker again, all encapsulated via the dapper API. And you can see that it is going to route the request to the save game endpoint on to scoreboard service. And I get the same data comes through to that app and then I can run my business logic. I should also mention here that dapper does have at least once delivery semantics on top of the publish endpoint. So every single subscriber that is subscribed to this topic is guaranteed to receive this at least once. And this is across all of the dapper component implementations, even if that underlying component does not have that, right? And you know, this is adding sub milliseconds of latency just because we are making those calls over local host as well. So, you know, as I mentioned, there are a number of different publishing subscribe brokers or message brokers that can be used within dapper. There's over 18 of them. Actually, there's a number of them that I put here. But essentially, you know, you can you do not have to integrate the message broker into your code for the whatever you're, you know, publishing on. So in this case, there is no like Kafka SDK within my code, right? I'm just going to be publishing on to the dapper API, and then using what is called dapper component, which I talked about earlier. So here's the sample dapper component. And I'll show this again. But essentially, this is, you know, the name here is game pub sub, which is that value that I need to keep consistent across both publisher and subscriber. And then I have the connection details within the metadata section, which essentially is the underlying infrastructure details or connection details of the component that I want to connect to. But again, swapping these out is really easy. So what I'll show in a second here is just changing from a Kafka component to a Redis one. And you can see this is a Redis component looks very similar. It is of type pub sub dot Redis. The one before was pub sub dot Kafka. Those were like the main differences, as well as there's a few different metadata properties for that component implementation. So yeah, and this one also is running in Kubernetes. All this is running on the GKE cluster. But this could be running anywhere, right? You could have Redis running locally on your machine. You could have a managed Redis, etc. That that host that fully qualified domain name can be changed, of course. So let's get into a demo of what that looks like. So popping over back to the code. I have, so similarly, as Sam showed, some of the services, the game simulator service here is the one doing the publish. And you can see in my code, I really am only keeping track of these two properties. I'm keeping track of the pub sub component name, which is game pub sub, and I'm keeping track of the pub sub topic, which is game. From that perspective, then what I'm doing is I'm again using the go SDK, and I'm publishing via the go SDK here, just again, and I'm publishing to that local host endpoint, the one I showed in the previous slide to game pub sub on to that, that topic, and I'm providing whatever message you know, I want to send in this case, it's the game data. But again, no, like there is no Kafka SDK in here. There's no Redis SDK. It is like only using dapper from a subscribing perspective. This is also subscribing within the scoreboard service. Let's go to the top here. And you can see a very similar, similar variables that I have to keep track of, right? But it really is only that pub sub name, the topic, and then in this case, the route that I want to route, I want the messages for the business logic to be routed to. So in this case, all the messages are going to go to that save game endpoint, and then the business logic is actually going to, yeah, it's going to be routed to another method within my go code. And this is all using, I should mention, using two, it's using this case, this is the component broker, and you'll see, you know, this is also named game pub sub, as I mentioned before. But this topic will actually be auto created by dapper as well, if, if it hasn't already been created within, within Kafka. So it does it dynamically. So let's kick off the game sim service and see this running. So yeah, so as I mentioned, we are running all this in Kubernetes, we're running it in GKE. But it can be run, you know, fully locally, we have the instructions to run locally as well as in Kubernetes on our README. So I'm just going to restart the game sim deployment. And you'll see the bottom here, lots of games coming in, right? Okay. And then if I look at the game sim on the top here, and that was the mount, we're good. Okay. And you can see all of my games. So I had 100 games that were played via the volleyball in the volleyball tournament, and they've all been updated. So essentially, this is the publisher on the top here, and this is publishing this data. And you can see that this subscriber is also receiving this data. And it's on, you know, round 99. If I scroll up here, it's round 98, round 97. It's done all of the rounds. So that's great. But what about using a different component? So now what I'm going to do is pop this open. So in this case, right, I'm using Kafka. I have a Kafka broker deployed on my Kubernetes cluster. And you can see that it's pointing out to that one via the metadata properties. I'm going to apply, I also have a Redis one that is also deployed. So I'm going to deploy this Redis one. And I'm going to show you that without any code changes, the applications will still run. So I've deployed my new component. Essentially, if I get my component now, you'll see that I've swapped this out from a Redis or Kafka, sorry, to a Redis component. And then if I roll out restart the, I'm going to roll out restart the game on my deployments. I have to make sure those Dapper sidecars get the new component. And then if I pop over now to the logs again and do, okay, get pods. So things are just cycling over. And then if I go this, okay, so there you go. This is the the publisher is now back up and running. And then if I do the scoreboard service, which is the subscriber in this case, I should see that I also have saved the game score again, rerunning every single time. So again, this is round 99, but round 98, round 97, all of these have been like publishing and subscribing. Again, I made zero code changes, right? All I did was update the Dapper component. And essentially, I was able to swap out from a Kafka broker to Redis. Again, in this case, both running in my cluster, but this allows me to keep my code really clean and ensure that I can make modular, you know, portable applications. The other thing I'll just show really quickly is the fact that the So this is just Redis insight. So this is connected to that Redis database on my cluster. And essentially, Dapper uses Redis streams. And you can see in this here, I have this game stream, which in this case was my game topic that I was publishing on. So this was actually automatically created by Dapper. And I can see in here, I have all of this data that was being sent through the game simulator service to that scoreboard service. And this was, yeah, dynamically created at runtime. So didn't have to create that topic. And then with that, I'm going to hand it back over to Sam to close. Thanks, Alice. So I know we've definitely covered a lot of ground here today, and we had a really exciting demo and the demo gods were with us. So you can see here just to kind of recap and remind you all of what we kind of looked at. We looked at how we can take the Dapper open source project and apply it to help a volleyball community and create this demo application to help them see what you can do with Dapper, right? So we can make some improvements on how they communicate with everyone and let everyone know where to be, what time for our games. So in terms of our scoreboard system that we just looked at, we just had a volleyball game simulator simulating some load for us and putting it onto a message broker where Alice swapped out components for us and showed us some of the awesomeness of Dapper. We had our scoreboard service interacting with a state store in order to save game state as well as retrieve it. And we also had our volleyball game service which was doing service and vacation providing us a lot of really great things like resiliency, tracing metrics. And then we had a really pretty web UI that I made. So if you are interested in learning more, Dapper has a lot of really great resources. So you can see the docs, the Dapper.io, you can find out a lot more information there. There is the Dapper Quick Start repo that I mentioned with a lot of tutorials showing you how to work with Dapper on your local machine as well as in a Kubernetes native environment. And today's code can be found at that bit.ly link and this bit.ly QR code. And yeah, again, there's a readme, there's a make file, so it should be pretty nice and easy to work with our sample today. Just running locally on your system as well as in a Kubernetes native environment. Dapper also has a really, really vibrant community. There are over 3,000 Discord members. So if you have lots of questions, they are there for you and don't be shy. There's also a Fortnite community call on the Dapper YouTube channel and you can catch the latest and greatest. So the upcoming V11 release will be coming out soon and so you can catch lots of the updates on our YouTube channel or on Twitter because I know the tech community is all about Twitter. And also if you're interested in managing Dapper in production, then check out diagrid.io. So again, my partner in crime here today was Alice and I'm Sam and thank y'all. I hope you enjoy the rest of the conference. Questions, I guess? Yeah. It requires the control plane to be deployed on Kubernetes. So there's like four control plane services that you deploy within their own namespace. And once you deploy those, there's nothing else required. You can use like unless you're using like whatever state store that you wanted for like a state API or something. But no. Good question. Yeah. So as something like ECS since it is running on a cluster, yeah. So primarily people run it on Kubernetes with a control plane. Actually, one of the things we're working on in our company is ways to provide sidecars through really to something like ECS. Yeah. Good question. Any other questions? They also have Dapper stickers. Oh yeah, so many stickers. I know. Yeah. Is there only a sidecar pattern? Is that what the question is? Yeah. Yeah. So today Dapper is primarily deployed as a sidecar pattern. There is a few projects that we're working on in open source in the sandbox called one of them is called Dapper Ambient. And essentially that allows Dapper to be deployed as a deployment. And so it's not necessarily like one-to-one from a sidecar perspective, but would be across the deployment or damage it? Damage it? Yeah. Okay. And yes, so essentially like less of a one-to-one but more of a, yeah, one-for-node or, you know, allows you to keep track of the replicas there. So, yeah. Anything else? Yeah, that's a Dapper specific row. Yeah. Mm-hmm. Yeah. That's like the that property in that case, like you see the one on the bottom is like the C1 alpha. So like one of the new APIs that is developed in Dapper is a more closed API and that one is still an alpha. So it's sort of a way for us to keep track of the API version so much better use. Okay. And we have tons of stickers too. So I'll pull some out if y'all are interested. Little Dapper stickers and then some little spidery things. Cool. Well, thank y'all.