 Yeah, y'all are pretty tired, right? I'm pretty tired because I will tell you all I went to sleep at like 1.30 last night, woke up at 5.45, had to be here at 7.30 for the booth setup, and I realized I was at the wrong booth. So good morning, everyone. I'm here to talk to you about move over API Gateway into your service mesh. And what this talk is really about is working to consolidate your API Gateway, your service mesh into one system. So you're not having to manage separate resources when you're running a Kubernetes cluster, and you have to worry about North-South traffic or East-West traffic. So my name is Marina Wiget. I am a developer advocate at solo.io. I'm from Canada, so I'm glad to be all the way out here in Valencia. I've been at solo for about, I don't know, two, no, seven months now, I think. And prior to that, I used to work at VMware Tanzu. So a little plug for my VMware Tanzu folks over there. So let's get right into it, and let's talk a little bit about service meshes and API gateways, and specifically an API gateway that might be envoy-based and the Istio Ingress Gateway. So when we look at these two systems, what does an API gateway do for us? It's effectively providing us controls to do things like rate limiting to be able to detect and discern what our upstream services are, provide TLS termination for those services, provide authorization and authentication to those services. And even to a level or degree, provide some ingress capabilities. And so when you think about that, that's all cool and well, but then you also have to think about the scale of your cluster and where it tends to go. On the other hand, when you look at the Istio Ingress Gateway or Egress Gateway, whatever you want to call it, it serves its own purpose in that it's also providing ingress capabilities for services inside the mesh. It's also doing some TLS termination and a variety of other services as well. Commonly between the two, you're going to see that there is observability that is present. But the thing to consider here is, OK, I have an API gateway sitting on one part of my cluster. I have Istio running in another part of my cluster. I have an ingress gateway that can do pretty much almost the same, and I'm missing a few bits and pieces. So what can we do to actually merge these two and consolidate them? What we want is all of these same capabilities, but in just one abstraction. And I would like to call this the service mesh gateway abstraction. I'll get into more details about it. But what I want to just help you all visualize with is, let's assume we have a single Kubernetes cluster where we might have an API gateway that is authorizing requests that are coming in from an external source. And we also have services that are exposed so that other external entities can communicate with them. But the critical part here is that this is our front door. Once we're past the front door, anything can go on. Anything can go wrong for that matter. And so let's also look at the other lens here where we have a service mesh running inside of our Kubernetes cluster where we're not so concerned about that front door, but we have entities to process the traffic that's leaving our cluster and the traffic that's coming into our cluster. And why this becomes important is because we have two systems that are effectively doing the same thing. So why not merge the two together? The other thing to consider is that as you start to scale your clusters, as you start to scale your services that you have available to you, the challenges that come up are, how do I manage all of these different objects that I have to create? How do I manage all the services, all the upstreams, all the routing rules that I need to have in place? How do I manage different versions of, let's say, API gateways or, let's say, our service meshes if I'm trying to do, let's say, an upgrade from one environment to another? There are a lot of considerations here, and this design creates so much contention in how we manage our service mesh environment or even our API gateway environment. Now, let's take a phased approach quickly. We can start off by having an API gateway, something that's envoy-based at the front door that is able to understand the requests that are coming in and route them appropriately to the back end, and then on the inside, we'll have service mesh or an Istio service mesh that's providing that east-west security using service-to-service MTLS and even providing us a level of observability. And off to the side, you're seeing virtual machines that also need to participate in this entire fabric. Now, this is phase one. Phase two is like, okay, let's remove the need for the API gateway to service those virtual machines and let's move some of this capability into the mesh. So we've kind of migrated who's handling those requests that are coming in. And what happens is specifically Istio is able to tie itself to virtual machines. And so now we have a sidecar that sits with the virtual machine that allows it to participate in the mesh, and I'm not gonna talk about how that all works, but the idea is now we have this fluid system, a fabric, which allows us to have microservices and VMs securely communicating with each other. Then we scale with clusters. Now we have more clusters, we have more services, we have cross-cluster communications, we're having to deploy east-west gateways using Istio, and we still have an API gateway front door, which means we have two sets of custom resource definitions that we have to worry about, which in actuality, when you think about it, it's just more overhead for all of you. So how do we address it? We address it by using a service mesh management plane and then a gateway abstraction on top of that. What this allows us to do is provide all those same capabilities of an API gateway while still using something like the Istio ingress gateway, which is still based off of the Envoy proxy anyways. We've written the listeners and filters and the filter configurations and whatnot, but the idea behind this is now I don't need to rely on a single entity. I don't need to rely on a separate CR or set of CRs. I now have one common set of resources that I manage to provide the abstractions on top of Istio, to provide the necessary things like rate limiting, external authorization, maybe using things like JWT token claims for routing, anything you can think of that you would do with an API gateway, you can now bring that into your mesh. And this is made possible by GlueMesh and GlueMesh gateway by Solo. So GlueMesh and GlueMesh gateway are the abstractions that Solo has built on top of Istio and the Istio ingress gateway, which means that now you're managing fewer resources for a larger set of actual environments that you're running, whether it be like five Kubernetes clusters or 20 Kubernetes clusters, comprised of various services that all need to work together to produce your application. So that being said, GlueMesh gateway is the abstraction I was talking about earlier on that provides you the ability to consolidate API gateways in your service meshes into one and be able to run it all pretty cleanly. This is all because of GlueMesh gateway and what we've built in our environment. So that being said, if you are looking to be able to layer into a service mesh and you want to be able to take advantage of external authorization rate limiting, you want to be able to tie in to OIDC systems as well, maybe even use some open policy agent to allow certain objects to communicate with other objects or conduct actions. Well, GlueMesh and GlueMesh gateway are your answer. Thank you all. I want to just say, if any of you are available tomorrow night, we're running a little happy hour from 8.30 to 12 midnight. I know that's usually around dinnertime or whatever, but you're all are welcome to come, hit that QR code, go register, and we'll see you all there. Thank you.