 Okay, let's get started. Hello, everyone. My name is Yaron Schneider. I am a steering committee member of the Dapper project, also a core maintainer for the runtime. I work at Diagrid, which is a company I started back in January of 2022, and today we're working with lots of major enterprises on their open source Dapper adoption and here with me today. Hi, everyone. I'm Josh. I'm also a core maintainer of the Dapper project. I'm also a software engineer at Diagrid. All right. It's great to have you all here. Just so you know, you're really helping out the project simply by attending this talk because the questions you will be asking us afterwards and, you know, getting to know all of the latest things that are happening in the project really helps us because then you will open up GitHub issues, right? You'll go on Discord and you'll tell us what you like and what you don't like. And this is what helps the project really the most. So let's start talking about what Dapper is and we'll really cover this for people who don't know Dapper. So all the stuff in the middle that you're seeing, all of these different building blocks, those APIs, that's the stuff you don't have to deal with. Service discovery, invocation, PubSub, creating event-driven systems, connecting to databases, PubSub, message brokers, configuration stores, coding for resiliency, fault tolerance, observability, monitoring, monitoring the whole thing, right? Creating resiliency policies, circuit breakers, timeouts, retries, all of that stuff just adds up so much. And so Dapper gives you these building blocks, these developer primitives, these APIs for you to be able to focus on what matters to you the most, which is your business, your IP, your core business. And Dapper really takes care of all of the rest. Dapper runs really well on top of Kubernetes or just as a binary, a single binary that can run in your machine. And it'll run pretty much on top of any Kubernetes cluster also if you're running on Kubernetes and OpenShift. And Dapper integrates with your existing stack. So Dapper is not a replacement to your infrastructure. It actually makes it better. It makes it more secure. It makes it more reliable by providing sometimes features that you don't find if you're talking to the underlying database or PubSub or Secret Store directly. Dapper has a vibrant community. We'll talk about that in a second, but we have over 120 of these specific component-level integrations. A lot of them are contributed to Dapper by companies like Microsoft, AWS, HashiCorp, Confluent, and others who want to make the Dapper ecosystem better for developers everywhere. So for each one of these APIs, we'll find a set of components that you can use to connect your infrastructure, and Dapper will provide additional security and reliability guarantees on top of what you'd normally find. Dapper has a set of goals. I'm not going to cover all of them, but the most important thing I think, you know, the first is to give developers tools that solve their problems of the day, meaning Dapper is a tool that changes with the time. If there is a new problem that developers, application developers face, Dapper will be set to meet that problem tomorrow, which is why Dapper is continuing to add more and more APIs. And it's vendor-neutral. Of course, it's part of CNCF for an incubating project. Zero trust security is something that's very important, which is why we're listening about as part of the APIs. We think with Dapper, zero trust security goes beyond just service-to-service communications. It's all the way through from your application to infrastructure. There is a lot more to just point-to-point communication when it comes to zero trust. You need to think about your whole stack, and this is something that you will find in Dapper in almost every API and feature that we have. And it's also really important for us to become platform-agnostic, meaning Dapper can run on Kubernetes, but it's important that it can really run anywhere, because people are not just running stuff on Kubernetes. It's a complex world out there. Forward, we have a very vibrant community. The things that matter most to us, the maintainers of the project, is, of course, the number of contributors. Those are the people who give their time and effort to the project, the one who are opening PRs, issues, commenting on Discord. This is really important. We have over 3,300 contributors today, and growing, we are the 12th largest project in CNCF, because Dapper is uniquely positioned to be a very application-developer-centric product out there. Let's talk about Dapper in 2024 and what we're planning. So, Dapper, as you know it today, runs on Kubernetes really, really well, and there's lots of boxes in here, but I promise you it's not as complex as it looks like. There's a bunch of control plane pods that basically manage the data plane, so Dapper runs as a sidecar container to your application so that developers can use those APIs. You basically call on local host, which is where the Dapper sidecar will run, and then we basically have a control plane that manages things like security and security communications between the Dapper data plane and the control plane, and it also lets the data plane know whenever you connect a new database or a PubSub or what we call in Dapper a component. So these are control plane pods, and they run on Kubernetes and the data plane runs as a sidecar, right? So if you have one deployment and that deployment has 10 instances, those 10 instances will have 10 Dapper sidecars. This is great in terms of high availability, because if one of those pods crash, the others are unaffected, they each have their own sidecar, but in some situations that might lead into too many resources being used. You might want to cut down on that, and so I'm happy to say that now instead of having a Dapper sidecar per application, you can actually run Dapper in a mode that's called Dapper shared, and Dapper shared is essentially Dapper pods that can be auto-scaled, can be auto-scaled by KIDA, for example. You can just do an HPA, you can auto-scale it with CPU and memory, and you can have multiple instances of an application talking to a single Dapper sidecar or two Dapper sidecars if you auto-scale them, and so you can save on a lot of resources. Of course, Dapper can also run as a demon set, meaning as a single pod inside of a node. I recommend to do that very thoughtfully, because if that specific node set goes down, all of the applications on that node will just become unavailable, because Dapper is in your hotpad. So using Dapper as a pod that can be auto-scaled, I think it's kind of like the sweet spot. This is currently part of the Dapper Sandbox organization. We're going to move it to the regular Dapper organization soon. Please check this out if you want to try run Dapper, not as a sidecar. We've actually had a use case come up recently from Zeiss, who have tried to run Dapper that way. Zeiss, people, if you're in the audience, thank you for your contributions. You've done great to improve this, and we will be improving this a lot more. So please try it out, give us feedback, tell us what works, what doesn't work, tell us if there is any edge cases we didn't think about. When we designed Dapper not to run as a sidecar, that would be awesome. So thank you. Dapper workflows. Dapper workflows is a great way to basically run stateful orchestrations of business processes. How many of you are aware of temporal, for example? Raise your hand. All right. I would have expected more, but now I need to explain temporal to you. Do you see what you've done? So basically, you have two ways to run workflows, right? You have declarative workflows like Argo, CD, who's aware of Argo. Many more. Okay. Yeah. This is the same CF audience. I'm forgetting where I am. So Argo workflows will allow you to orchestrate processes between containers, but there is also another way to run workflows, and that is workflows as code. So think about your code doing something like this. You might have a, it's kind of annoying. I can't see the thing here, but I'll stand right here. Think about you have an activity, and that is a piece of code that gets a message from a message bus. And then that thing needs to now create an activity where it gets a secret. And after the secret, you need to wait for some external event, which might be a human pressing a button on some console somewhere. And after that, you want to kick off in parallel to other activities to do different kinds of things. One of them needs to reach out to an external API. Well, the other needs to store that event data in a database, and you need to wait on that. You need to change those tasks together. And once that's done, you basically need to aggregate all of that data and publish it so that someone can consume the raw result. And then you arrive at the end. So any one of these steps can fail, right? And then what you do, do you know where you failed during the process? How do you recover that state? So dapper and other workflows as code execution engines will actually make sure that this entire workflow process is orchestrated, meaning it will replay, it will know where it failed, it will keep the workflow state, and it will kick everything off. This is incredibly hard to write. If you need to write a workflow engine that's generic and that can support all of these different types of integrations and activities, you're going to be managing your own infrastructure for a very long time. That's going to become very costly. With dapper, you can really do this in 50 lines of code, maybe even less if you have less activities. We do support and I will just go back here. We do support go C sharp Java Python and JavaScript. We're adding more and more languages. This is going to become stable this year. So for those of you who are looking at dapper workflows now and other many, it's going to become stable in 115. No promises, but this is the intention. And yeah, this is a really, really great API. This API specifically, you don't have to bring any external dependency for except for where to store your state. And it's built on dapper actors. How many of you are aware of the actors program model? Okay. Awesome. So for those of you who are not aware of what it is, actors are a way to encapsulate compute and stay together. Think about how Kubernetes has, you know, hundreds of thousands of containers running inside of it. An actor represents a domain business logic that you have. Let's say that you want to count cats and dogs. You might have a cat actor and a dog actor and these have IDs or names. So you could be creating millions of those instances throughout your cluster and the access to a given actor will be single threaded. So developers don't have to think about threading or multi threading at all. And so if any of these actors fail, they will be restarted someplace else in the cluster with our state. And you can arrive at really large scale architectures we know of really large companies that run four million actors in a single cluster actually dapper can host 10,000 different actors in a single pod. So you can get to very high scale, but you also need to know what you're doing because you can shoot yourself in the leg. It's a very low level program model and it's used by actors. So today for coming into dapper, I would encourage you to look at workflows before you look into actors. If you have like a very advanced use case, you can look at actors. Actors scale really, really well, but they have an issue with reminders, at least with dapper. We support, I think, up to 60, 70% requests per second when firing something called an actor reminder that is meant to basically, you know, tell an application, Hey, I want to be reminded to do something at some point in time. And that has several limitations. And we really need to make that thing a lot more scalable before we can make workflows stable. So we've basically re architected the entire thing. And this is what's coming up. We've rewritten the actor reminder service to basically add a new scheduler service. So the dapper control plane, as I've shown it earlier, it has four system pods we're going to add a new one. So you're gonna have a fifth one called scheduler that you see, you know, in your Kubernetes cluster. And those different modules or containers have at CD embedded inside of them. And we're basically using at CD as the means and as a way to list reminders, save reminders and scale them. So when we looked at a mechanism to save the actor reminders, we were pretty baffled about, you know, what's the storage of choice and storage that we can make. And a lot of you know, at CD because it's used as the backing system for Kubernetes resources, of course, but at CD is much more than that. And we've looked at CD and we're like, Okay, it allows us to select queries and do range queries. And it has full tolerance and we can trim logs. And so we've run it in a few performance tests. And we've found that the API surface it gives us with the performance characteristics really allow us to pick and to pick it as the backing system for the scheduled reminders. And this is going to come up. But you as a user are not going to have to do anything with that CD. Okay, you're not even going to know that it's installed in your cluster, you're not going to need to bring in that CD, you're not going to need to manage it with helm, nothing like that. This is because that CD is written in Go. The app was written in Go. And so it's very easy for us to just put it in the binary and use it directly. From a user perspective, it's an implementation detail. It's nothing more than a way for us to orchestrate reminders at very high scale, which means that you're not even even get reduced ops, you're going to get no ops with it. It's just going to be a control plane pod that's going to manage at CD for you on your behalf. So this is really easy because it introduces no overhead for the user and it's very scalable. And this is going to probably improve Dapper Actory Minders by 100x at a minimum. So we are very excited about this because this is going to be the basis for many things that are going to be coming into Dapper. Each Dapper Sidecar, the Chrome API, which you see here and you don't know what it is because it flipped the orders of slides. We're going to talk about that in a second. You're basically going to call into an API. That Dapper Sidecar creates a persistent connection to these scheduler instances and the scheduled instances will basically partition the reminders. They will know exactly which Dapper Sidecar called it to know to which application instance it needs to call back. And this is how it works. It's a very simple but yet highly efficient architecture that we're testing out. And this is going to make workflow stable and also really improve Actory Minders. If you're using Actory Minders today and you're suffering the limitations that come with the performing characteristics of it, this is all probably going to go away. Okay, so yes, we are also introducing with this new scheduler service in 114, a distributed Chrome API because workflows are great. Actors are very low level. They enable you to do incredible things. But sometimes you just need a very high throughput Chrome API. And you don't want to have to write your code to do workflows. You don't have to deal with activities. You just want to tell something, hey, I have this piece of data and I want to get reminded at some point that I need to do something. And if my application crashes, I still want it to arrive at my endpoint when it comes back up. And if Dapper crashes, I want to be stateful. And so we're coming out with this Chrome API. And you will be able to just issue a very simple HTTP or JRPC call. We will schedule the call. We will save your state. And it's going to improve, as I said, the performance for workflows and actors pretty significantly. And this is coming in Dapper 114, which is going to be released around June, June-ish. Yes. Again, no promises. It's difficult. Help us release Dapper. Yes. So one other really interesting thing that we've heard from the community was wanting the ability to publish a message through Dapper Pub Sub. It's one of our highly used APIs in Dapper. It's probably that service location in state. And so you will be able to talk to Kafka, AWS, SQS, any of the Dapper supported message brokers. And you will be able to tell Dapper, hey, publish a message to this topic in five days and three hours for now or in a year. And Dapper will basically schedule the message. And this is going to be built on the same actor reminder service that I talked about earlier. This is going to be really important for people who need to schedule jobs for the future and who want to publish it, but don't want to have to go through the CRON API to get the reminder and then schedule a separate PubSub call. So we're going to use this new actor reminder or reminder system that we're planning for many other things, for many other scheduling purposes. It's going to be used for PubSub, for actor reminders, for workflows. And if you have an idea about other scheduling features that you might want or need, then please let us know. Open up an issue on GitHub. This is the meta argument for the day. If you have any feature you want from Dapper, please open it on GitHub or let us know. Okay. So, yes, now we're going to talk about application level security. I'm going to hand it over to Josh. We're also doing a lot of work in Dapper 114 for Zero Trust. As we said, it's really important for us to make sure that everything is secure. Josh, as a maintainer of SIRT manager, will now walk you through what we're going to do. Yeah, cool. Thank you, Jury. Hi, everyone. Again, I'm a core maintainer of Dapper and work with Diogrid. Yes, so to kind of talk about a bit about what we're going to do for 2024, some things we're going to do around the kind of security space. First, we want to talk about a little bit how Dapper secures its network and the cluster. So Dapper fundamentally uses MTLS everywhere and certainly by default. And the way that we do that is through Spiffy to represent identity. So Spiffy is another CNCF project, and that's a framework for representing identities. It's very flexible, and it allows you to represent workload entity machine identities in kind of hopefully human readable formats. And we'll talk a bit about that in a second. The important thing to know here is that, yes, we have all these side cars running everywhere. We have a control plane service called Century, which is responsible for signing these workflow certificates and keeping them renewed so that side cars can communicate with the schedule service or other side cars in the cluster. And it does that through cryptographic attestation, which is a very fancy way of saying that it's going to grab a token from the Kubernetes API server representing its pod identity. It's going to send that to Century. Century is going to find out what application identity it has by looking up through the Kubernetes API server and then sign a workload identity based on that app identity. And the end result of this is, is that all of the DAPA services inside the cluster have their application identity assigned to them, a human readable, you know, sock shop or, you know, airline XYZ as part of their cryptographic attestation identity document. So some things that we want to do for 2024. So we have this XY9 certificate. XY9 certificates are great. Why? Because they use asymmetric cryptography. That's again another fancy way of saying that we don't send any secrets over the wire. You can compare XY9, for example, to something like JWT or, you know, A-O-I-D-C, whatever you want to call it. The problem with these things is that they are fundamentally they are passwords and you're sending passwords over the network. If a malicious actor or, you know, these things get leaked or what have you, they are prone to and they can, you know, be attacked through these replay attacks. They are fundamentally passwords. So the nice thing about XY9 happens at the TLS layer and yeah, it's asymmetric cryptography. You can't steal a private key unless you really do the kit, but they don't get sent over the wire. So we have all these identity documents, XY9, and they represent, again, the application identity. A neat thing you can do with this is just like we do M-T-L-S between the services in our DAPR cluster. We can also, in coming this year, implement them to actually talk to our external components as well. So A-O-S is a really good example for this. They have great support for accepting XY9 certificates in their kind of roles anywhere feature. So you can describe IAM roles in terms of incoming TLS connections based on that spiffy ID. So work in progress, not done yet, but the kind of component manifest that it will look like is something like on the left. And you notice there that typically if you're going to, or always, hopefully if you're going to write a component manifest in DAPR today, you're going to have some kind of connection string, hopefully a secret reference that's stored somewhere. But instead, with this feature, you'd be able to say, actually, I just want to use spiffy off. Literally no secrets involved. You're using the identity of the pod itself. And I'm going to then connect to AWS using that identity. And so on the AWS side, I can then highlight. If you go to the, yes, look here on the AWS side, I can just say, actually, my blue namespace, my DAPR application has access to this S3 bucket. And that's super powerful. Because what that means is you're describing your authorization roles, not in terms of some abstract, you know, infrastructure with, you know, crazy URIs or anything like this, we're actually describing the authorization to, you know, infrastructure resources in terms of applications. Why this is so good is that it gives, it empowers application developers to have the freedom to describe their applications in human ways, like they want to describe it in things that they do, but it allows the security teams to still be able to control what they have access to. But they're both happy because the security teams can actually read the roles that they're writing and understand, you know, what is connected to what in a human and readable way. Here's another example on the side, a bit more complicated. I'm not an I am or AWS wizard, but you can start to hopefully appreciate that you can start to design these very descriptive roles in a human readable way, you know, wildcards and things like this, namespacing. And again, this is really powerful to give developer look, here's your namespace, you know, go ahead, use DAPR, use the APIs you need to, and as a security team or a platform team or what have you, are able to actually, you know, still keep the kind of keys to the castle and make sure they're kind of reading and writing to the right things. You know, a lot of security instance, especially when it comes to authorization, typically come from misconfiguration, copy and paste errors and things like this. When you start talking in human readable language, you eliminate a lot of these problems. Moving on, the next thing I wanted to touch on, so briefly, roots of trust, probably do a whole talk on roots of trust, but very briefly, roots of trust, this is the certificate authority. So again, in the x y by nine space, you have a certificate authority, which is some kind of self science certificate, which is the root certificate that is used to sign intermediates and then and or leaf certificates. And they're the things that actually have the identity. But when you make a TLS connection to a server, you have to pre trust the root of trust in order to verify the certificate, like the equivalent would be when you buy a laptop, it comes pre installed with a bunch of CAs. So when you go to Google.com, you know that Google.com is signed by a root of trust that you already trust. Yeah. So in JAPA, we, yeah, we distribute this route of trust across the cluster. This is, you know, public data. That's fine. But the where the problem comes in, is where DAPA today will self sign a root certificate and store it in a Kubernetes secret over here. So essential come up, we'll check whether it exists or not. And if it doesn't, it's going to generate that root certificate. That's fine. However, it can be problematic for two reasons. So number one, Kubernetes secrets in general terms are quite problematic. So ideally should never be using Kubernetes secrets will stop. They're discoverable from the API. They're stored in net CD. If you get an net CD dump, then you go keys to the castle. Again, they could be encrypted at rest or what have you. But yeah, they discoverable through the API. And so they're not always great. The other thing is that actually you might want to integrate your root PKI with your existing systems, especially for large organizations who have a dedicated PKI team. They want to have this observability and they want to incorporate all of the workflows that have been across their infrastructure under the same PKI system. So to alleviate this, we're going to add support for external CAs. So all the major cloud providers all have certificate services. So GCP AWS Azure, but also to have support for vaults. That's another kind of certificate issuer and set manager costs bias, but I'm happy to have that one included as well. And the idea here is that the century service will instead of self generating a root CA and again, storing a Kubernetes secret. That's bad. We're going to be requesting an intermediate secret intermediate certificate for one of these services. And what does that give us? We're no longer storing private keys at rest. And particularly that issuer certificate issuing certificate, which is the really painful one to be storing, storing at rest and making available through the API. We're keeping everything from memory, which is super important, keeps everything much more secure. Yeah. What else does this also give us? So again, I was mentioning there about, you know, PKI teams and security teams already having their stuff set up in their infrastructure. They've now, you know, heard of Kubernetes are being thrust upon them. And, you know, they're now having to like learn all this stuff. And, you know, the business going towards this kind of distributed Kubernetes as well. But they still want to have control of their PKI system. And, yeah, so that will enable them to have total visibility across all the clusters. And having a shared route of trust is also going to allow us to do some really cool stuff with cross cluster communication. And again, this cross cluster communication will be MTLS, strictly MTLS, between DAPA identities, DAPA services, as well as having that human readable application identity. Again, which is super important. You can start writing your policy and authorization rules based on human readable words, not some kind of crazy you IDs that the infrastructure gives you by default with service accounts and what have you. So yeah, back to you. Yeah. Okay. So if we have some time and we do, I need your help. I want to know what we should be focusing on. So I'm going to ask all of you a few questions about things that might be important to you, not DAPA related just in general. Okay. So I'm going to bring up a topic. And if it's important to you, please raise your hand. Okay. This is going to be really, really important for us because we want to know where to invest our efforts in. Okay. How many of you are interested in multi cloud architectures? Okay. Thank you. How many of you are interested in workflows as code like the ones I've shown earlier? Thank you so much. How many of you are interested in wasm? Okay. How many of you are interested in cross cluster communications where wait, wait, wait, where, where you have applications that are basically the same applications that need to operate in we're already raising your hands. They didn't finish. That's that's great. Yeah, you're taking the assignment on really well. Wait, where you have the same applications running on separate clusters in active, passive, and yes, you. Okay. Awesome. Yeah. Okay. How many of you are interested in mold in cross cluster communications where you have different businesses running in different clusters and they need to communicate because you can't have all services running in same cluster. All right. Thank you. This is great stuff. Do you have any questions, Josh? Okay. This is this is all great stuff. We're going to open it up for questions, but we will be here for 30 minutes after the session ends to talk to you face to face. So please come and say hi. And yes, if you want to step up to the mic, please go ahead. Yeah, thanks, Aaron. Thank you.