 Yeah, as Vic said, my name's Mike. I work on the mesh team at Kong, and we work on Kuma, the CNCF service mesh. And today I want to talk a little bit about what I call domain-oriented Kuma. And I'll jump right into some motivation for talking about microservice architecture. If we take this like generic store as an example, and we want to do it using microservices, the most naive way is just to implement our functionality as microservices and have a flat network of microservices. And every service exposes some functionality in its API, and this API is public. That means any other service in the mesh can use it. And as we scale up to more and more microservices, there are some disadvantages to this architecture. And the first is that if you put yourself in the place of a service owner, like I said, every API is essentially completely public. Any functionality that your service offers is being used directly by any other service. So say you want to make a change to your API for performance reasons, whatever. You need to go and make sure that when you change your API, you're not going to break all of those other services because there's nothing between them and you, right? And yeah, so what that means is you have to start coordinating with other teams. So you're the owner of your service, but you've got to talk to the owners of the other services and you've got to coordinate deployments. You've got to make sure that what they're running doesn't break when you change yours. And maybe one of the teams doesn't have the bandwidth to do this at the moment, but you want to get your release out. So maybe you just implement it yourself in their service just to get it done, right? And this doesn't scale very well. What you've basically created is what's known as a distributed monolith, where the services appear to be independent, but really they're very tightly coupled. And if we're using a service mesh, there's another aspect to this. And that is in a service mesh, every node is able to communicate with every other node, right? That's kind of the idea of a mesh. And what this means is that the control plane is calculating configuration for all of the sidecars for these services. And if we imagine a new service coming up, the control plane, in order to handle this new service, the control plane needs to calculate configuration for sidecars of all other services. This uses CPU. It needs to send that configuration over the wire, depending on the protocol. You'll be wasting bytes. And finally, the sidecar itself is holding this config in memory. And this is the case even if this new service is only used by, say, one or two services of the many microservices you have. So there are some issues with this sort of naive way to do a microservice architecture. And I'm going to talk about DOMA, which is domain oriented microservice architecture. But first I want to jump back to domain oriented design, which sort of applies to a single deployable application or a library. And it's also an answer to the question of how do you design your software with ideas like maintainability and ownership in mind. And what it says is basically, use the business domain that your application lives in. Create modules for your application. These modules have public interfaces that they provide. Other modules use that functionality directly via the public interface. But otherwise, what you have is private, and that allows you to iterate and refactor and reimplement inside a module as long as you don't break the public interface, something we all have seen before. And your language hopefully is sort of holding your hand here and making sure you don't break these rules, right? And DOMA comes in here and it builds on the ideas of domain oriented design. And it kind of lifts it into the world of microservices. It was extensively described by Uber on their tech blog and definitely check out this post because it goes into a lot more detail than what I'm going to talk about here. And there's more to it. But there's two basic building blocks for DOMA. The first is you take your services and you group them together according to the business domain that they live in. And then we say inside a domain, and these are examples here, inside a domain, services communicate with each other directly, but services in different domains can't communicate at all. So you've essentially privatized the interfaces of those microservices. And then you introduce the idea of a domain gateway, which exposes the functionality of those domains in a public interface. And this public interface can be consumed by the services in other domains. So now you've got private and public interfaces for your microservices. And domains and gateways are really just rules about how services communicate with each other. And that's kind of what a service mesh does, right? It's what a service mesh is there for. And maybe we can use a service mesh to help us enforce and implement this architecture. And I think we can with Kuma. The first way we're going to do that is the mesh resource that Kuma offers. Now, the word mesh can refer to the entire control plane, the whole data plane, but Kuma also offers a resource, which is basically called mesh, which is basically a way to partition your data plane into separate meshes. And it does this by virtue of the fact that in a mesh, every mesh defines its own CA. So for every service that ends up in a mesh, MTLS guarantees that it can only communicate with other services in that mesh via MTLS and the fact that they have their individual CA's. This allows us to make an optimization in the control plane. If a new service in, say, mesh A comes up, the control plane knows that it doesn't need to recalculate any configuration for mesh B because it's impossible for a mesh B service to reach a service in mesh A anyway. And so our resource usage becomes independent between meshes. We can also create a, like we don't have to create any additional permission policies here. We can rely on the CA to enforce this separation between meshes and otherwise say, okay, every service inside a mesh can just communicate freely. And we still only have one actual control plane deployment to worry about. So one control plane deployment is handling these multiple meshes. The second aspect of this is ownership. So every policy in Kuma applies to a specific mesh. So we can have sort of the role of a mesh owner who is able to define how all the network policies that Kuma provides, but only for their mesh and they won't affect any other services. These two things together give us a pretty great way to model the domain from domain-oriented design. So in domain-oriented Kuma, we model domains using meshes. The second part for gateways, we recently introduced the built-in gateway in Kuma, which is an envoy-based gateway for north-south traffic. And when we were looking at how to handle communication between meshes, we decided to reuse the gateway a little differently. We don't just use it to trust, I mean, we don't just use it to accept any traffic from say the internet, but instead we keep MTLS on and we accept traffic only from some CA for any mesh that the control plane knows about. So it's a little different than the services in a mesh. We accept traffic from any CA at a gateway. And so this allows us to take the functionality that the microservices in a mesh implement and then expose it by the cross-mesh gateway for the other meshes to use for those services, which makes it a perfect way to model the domain gateway of Kuma. So yeah, so we've got meshes modeling domains and we have cross-mesh gateways modeling the domain gateway. And as an example, if you were here earlier, you saw the talk about gateway API and you'll recognize this. This is a gateway API gateway. And so Kuma supports gateway API. Here we've created a gateway. We've labeled it with the mesh we want it to belong to. And we've pointed to a gateway class that Kuma provides for making cross-mesh gateways. The host name that we set is the name that the cross-mesh gateway will be accessible at for all other services in our mesh. And then we can create HTTP routes like normal to expose that functionality from our services inside the mesh to services in other meshes. Just to drive home the point about what MTLS is doing for us here. If we imagine a client here making a request to the domain gateway, like I said, it's at orders.mesh. The Envoy config is made up of, well, we modeled this in Envoy on the client side creating a cluster, which is basically a set of Envoy endpoints. That point to an endpoint. In the gateway we have a listener that corresponds to the listener we created earlier. And the client is opening a TLS connection upstream and it's providing an identity that's given to it by the payments, which is the mesh it's a part of, CA. It sends this when it's making a request to the domain gateway listener. The domain gateway identifies itself with the orders with a certificate from the order CA. And then we have on the client side, we trust the order CA because that's what the cluster is configured to do because it's configured for a domain gateway. And on the gateway side, we are trusting the payment CA amongst the other CA's in our mesh. So we see that these two things in combination mean that the request will be successful and we've maintained our MTLS guarantee, but we're moving between meshes here. Yeah, so that's domain oriented, Kuma in short. The takeaways here, I think our DOMA is a good way to avoid some of the complexity of microservices and avoid some of the pitfalls. And Kuma is a great service mesh that is a great way to add an infrastructure layer for that implements the DOMA architecture. Thank you.