Hello. It's been a while, gang. We're going to be talking about API management today with our guest. Introduce yourself. So I'm Chris Sterling. I'm Senior Product Line Manager on API Management inside of VMware. Just focused on how can we make developers' lives better with the API gateways. You've been busy this year, this first half of the year. You've launched a couple of new things. Tell us a little bit about that. We'll get that out of the way. Talking about the API management space. We might talk about a little service mesh. Tell us what's new in your world. So we launched in February the Spring Cloud Gateway for Kubernetes. We had already had a Spring Cloud Gateway commercial service on Tanzu application service for VMware. But now we have one on Kubernetes. It'll run on any Kubernetes. Nice thing is what we're trying to provide is developer-friendly experience with API gateways. Because we heard that was a common issue for a lot of application developers. Using API gateways was not easy. It caused much delay. It tended to be through a centralized organization. So we try to make it much closer to the developer and be able to do local development all the way to production. And then on top of that, we had in April, the API portal for VMware Tanzu. So this product is a way to see open API documentation across a number of open API sources. And it just so happens our Spring Cloud Gateway now auto-generates open API documentation for you. So if you've been creating what are called API route configuration files for deploying your service and exposing it through a Spring Cloud Gateway instance, those will just automatically generate into open API docs. And that could be exposed through the API portal. And now all of your APIs across your organization could be shown in a portal. What do people use API gateways for? Let's start with the super basic thing. So mostly what they're used for is that I have like a service and it has some web endpoints that I want to expose to others and they want to be able to use those endpoints. Usually some JSON or some XML going on in there. And then the consumers come and they make calls through the gateway to there. And the reason why you want the gateway is it handles cross-cutting concerns, such as like single sign-on, maybe client certificates, modifying headers if you need to for old brownfield applications.
2:09Maybe you're doing commercial off the shelf and behind it. So you need to do some manipulation of the request and response as it's going through. Maybe you need to do some rate limiting because you got a mainframe back there and it doesn't want to have a million requests per second. So those are all kinds of things that you might put onto a gateway and it makes a consistent flow for the API consumer. So you might have a scenario where you're searching inventory in stores or something. Like you got a mobile app or some other app and you want to buy a dishwasher and the actual customer wants to go touch and feel and smell the dishwasher. And so they need to find a store that it's located. So in your app somewhere, it's find out where this is located. And that might go through a gateway for all the various reasons that you went over. Yeah, all of those might go through a gateway because they might want you authenticated. So now you have single sign on and now you're authenticated, but you authenticated while you were going through the front portal. And then the portal sent you over to see the inventory service showed you a bunch of stuff that you wanted to see. And then you went to the search service because you wanted to go to appliances. And then once you went in there, you also want to do store locator. So you went to the store location service. So all those are sitting behind the gateway, all you sharing the same session in terms of the user experience. So I'm logged in touching each one of those points, but each one of those services in behind it can be run by entirely different teams. And they might have a totally different continuous delivery cycle. They might have a totally different API evolution over time. So they need to be able to keep agile, keep going in a separate motion. So Chris, why now? Why did you and the gang decide this is the time to introduce this offering? Well, first off, we went to 80 plus customers before we even implemented the first solution, which was on tangible application service. And what we found from them was a few problems that they had with their current API gateway solutions or the things that they were trying to attain. And they were actually thinking about purchasing an API gateway. And one of the major ones was application developers. Many of them hated API gateways because of their experiences with them. We found out from surveys, it took them days and weeks to get APIs updated because they tended to go through.
4:12And so we found that, well, okay, that seems like a big problem that we could solve. And not only that, we actually saw in our open source that some of the organizations using the open source Spring Cloud gateway project, which is just a library you create your own API gateway out of. They were actually using it for that purpose, too. They were creating multiple Spring Cloud gateways. So it was almost like a natural, okay, we've got a solution already that's working for customers in the open source. And they want some additional features that they're not going to get in open source. So maybe we should make a distributed API gateway and also solve some of those feature requests that they have. On top of that, one of the other things, the operations group even would say things like, it becomes very complex. They started out, I need an API gateway for this small set of teams. And they knew exactly what the scope of that work was. But then all of a sudden, everybody heard, hey, we got an API gateway. And then more and more teams start coming. And of course, they don't grow that team that does the operations around it. Not only that, it's centrally managed anyway. So even if they did, you're still going to have a lot of back and forth that is needed in that central config. And it just became overly complex. And so then they create ticketing systems. And that's what caused the delay. So we had both of those happening. And on top of that, we saw the adoption of our open source just skyrocketing. So there was quite a few things that we were finding. We found that the big thing that developers liked about Spring Cloud Gateways was the developer experience. They felt like they could attain that API gateway approach, which is really a design pattern. Even in networks, you have gateways. So you have it all, it's turtles all the way down. But the API gateway has a special focus, which is business value and displaying an API that provides business value. And it's quite different from just routability and things like that. In this context, what is business value? Like for an API, how do you define and wangle that? So I think that one of the things like store location, being able to expose that to others is a very powerful tool. And it provides value to someone. That's a huge value to a company that wants people to come to their stores and smell and feel their appliances.
6:14Value to the customer who's actually looking for the store. It provides value to the store because now you're potentially getting more feet through your store. Therefore, hopefully more sales. And so those are the kind of things you're trying to attain. But not only that, one of the interesting things was within an organization, we found that there was another market that I hadn't talked about yet, which is internal API economy. What we found was that there was a lot of teams with APIs within an organization, like thousands of them. And sometimes the operations group had no idea that they even existed because they're not exposing their APIs outwardly. They're just exposing their APIs to each other. And they were trying to do it through point-to-point solutions, the situation we've had in the past. But then they started adopting Spring Cloud Gateway and they found that, hey, we can actually have a line of business with our APIs that may be useful to this other line of business. Maybe I'm the fraud line of business and the agent line of business over here who has an agent portal wants to send us requests to see if there's fraud in this loan application. There's this internal API economy that needs to be served as well. What we found with customers that has more APIs than the external API access that you might have on a mobile app or something like that. Exciting back office and supply chain stuff probably goes on here too. I'm sure. I'm always curious about the distinction of business value and outcomes and because we all live in a corporate world and that's how we're supposed to live our life. And I'm always like, I don't understand what that means. What I'm thinking of when you're putting all that up on the non-existent chalkboard, so to speak, is so we were just to think about API gateways and API management from a purely, let's say, operational developer, like nerd level. There's that first tier of stuff you are going over that sort of performance and scalability and ease of use and ability to change it. At that level, you're obsessed with what are the capabilities this thing has that a developer or an operations person would interact with. But then the consideration, and if this seems right, I'm curious to hear how this guides the development of the product, so to speak.
8:14But then you add in this other consideration of, but it should also do something useful. The first part to usefulness is that someone uses it as you are going over. So even if we have the best operational thing and it looks really cool and there's fancy diagrams that update and we have perfect governance done through a ticketing desk, so it's fantastically governed. But then if people don't use it, we get no value from it. Yeah, it's a product mantra, right? Convenience trumps function. And that's the one thing where you want to make things, you want to make solutions that are easily attainable rather than something where I have to reconfigure my whole life in order to use it. Or becomes a distraction in my life, even worse. Every time I need to use it now, it becomes a distraction. So the idea here is how do we meet them where they are, right? The application developers are already here, they've already got a lot of brownfield applications. In fact, most of the value that they have generated is in the brownfield, not in this brand new thing they're going to throw on this cool new platform. It's actually the things they already have written and already provide and that they're maintaining. And so how do you expose that in a new way? How do you extend its value? How do you, sometimes that's across the lines of business. Sometimes that's making it available to mobile. There's a lot of different ways that you do that. At the beginning, before we started recording, we started, I asked you about overlap between some of the things we're doing with gateway and service mesh offerings or technologies. Can you talk a little bit more about that? Because the service mesh area, I know there's a lot of interest and curiosity, but we've been talking about it as an industry for a couple of years now, and I'm not sure I've seen huge adoption. Can you just explain this to me, explain to me the role of a service mesh or service mesh type features and gateway and how these overlap or complement each other? A service mesh is this nice thing from a routability and network layer point of view that allows you at layer seven to move traffic in a very specific way. So a lot of times what you hear about is sidecars being able to apply policy at those sidecars for every single service that's running or every single pod potentially that's running on a Kubernetes cluster.
10:17So does that mean in the little sidecar is the policy information for that particular bit of code that you're moving around? Yeah, exactly. So how do I, there's a few different things that can go in there. For instance, you might say, okay, I take traffic for this type of information or this, this route on the inside of the cluster. And on top of that, I might say, okay, here's some security policies. Like I have a certificate that identifies my container in my route to the rest of the world. And in order to talk to me, you have to have a valid request that is that I can validate coming to me that it has a certificate on that is valid for me to talk to some things like that. And we call that mutual TLS, right? And you, there's this way for us to say, okay, yes, we can all talk to each other. And that could be a policy that you put into a cluster. Like these things can talk to these things, but not others. And if you recognize that conversation is more about a layer across things, it isn't about the business value. It's about how do I apply general policies that manage the routing to these different services in a way that, that, that I see fit. Now you can extend that obviously to do some things that maybe an API gateway could do, which is you might do some rate limiting. You might do some weighted routing, maybe do some canary deployment stuff. But at the same time, even through that, you're only touching a little bit of what API gateways do. And you could further extend it even beyond that. But what we found is that a lot of application developers are not as interested in writing the amount of YAML that's involved in doing that with a Envoy or Istio. They want something that sits in front of that. They want something that they, that's more approachable for them because most application developers have a lot of work to do to generate the business value parts of their implement user story. And they don't have as much time to go down into the weeds of what are all the security policies I might ever want or network policies I might ever want. And it's not their expertise either. There's other people who that's their focus. So what I think is the thing here is that that's not easily attainable.
12:18We talked about it early, right? It's not convenient for me to go down and write that much YAML. And not only that, I'm probably not the best one to do it because I probably won't do the job that's needed to be compliant or whatever it might be in an enterprise. Then there's API Gateway, which is focused on the HTTP content. It's saying, what are the headers that I need to have here? What are, what's the circuit breaker pattern I want? Where do I want to forward requests if things are down? But how do I want to manipulate the path for this old service I have running on a VM back here? These are all kinds of things that I want to focus on as an API developer, an application developer that are, that don't really have to do with that generalized policy of network and security. They're really about how do I want to interact and provide this function to my API consumers. Yeah. It seems we're going to need more layers. First of all, we're, I mean, we're already up to seven and we've run out of layers. Actually people talk about that as well, right? Maybe does anyone really know what layer one and two is or care? Maybe we should just take those over. Distributed computing could just add a whole like plethora of particular layers. There's plenty of value and things that people who care about layers one to three, but I think when you're up the stack layers, I don't even know what layers one to three are, but it's the equivalent of turning. Your internet modem on and off. Like you just, I don't know, man, I'll just reboot it and see what happens. I'm interested in talking more about this distinction between gateway stuff and service meshes. And I think like the way you've laid it out, it's almost like a service mesh can be thought of as lower than an API gateway, right? Where essentially at its core, what a service mesh is doing is intercepting communication between containers in a Kubernetes cluster. And it may intercept them and do nothing, in which case it just passes through and that's it. But as you're going over the other, and importantly, it's not only HTTP or S traffic. It's any type of network traffic. And so what that means is everything you were just saying is suddenly you can just not suddenly, I'm sure it takes some time, but you are given the ability to do all of the sort of network enforcement that you would want to do at, as you were saying at layer seven.
14:22So like it's, you can mediate what container to container communication is, not other stuff. And then that also means this seems like you shouldn't do this, but you could also start to put like business logic in there. And that seems like it would go very poorly long-term because basically if you can intercept the traffic, you can act as an application on your own. And maybe there's a little bit of mucking around with the data to add like application tracing in there that you might want to do, but maybe not. Like maybe that's a bad idea versus an API gateway is more, you're not really like in the network traffic and inside the communication. You're more like, as it would say, an endpoint. So an API gateway is more like I have, I have this thing that I'm going to talk to, and it's more of a service, as we used to say, like a store locator. And I have no idea how that's implemented, whether that's in Kubernetes or a container, or it's just myself that I'm talking to, because I like to do that instead. Like I don't care about network policy. Instead, what I'm mapping out is you might even call it like application policy or architecture policy. Like you're defining how you want the architecture to function, not how you want your network and your cluster to function. Exactly. Yeah. And those are almost perpendicular to each other in terms of the goals. The goals are different consumers entirely. And so I think of service mesh is really complimentary. And you talked about API security, you alluded to Rita. So now if you think about it, now I have policy at this layer, which is cross cutting, right? It cross cuts all of my APIs. And if you use something like Tansu service mesh, it even goes beyond Kubernetes, right? It could go to your VMs. And all of a sudden you could potentially participate in a service mesh that goes public cloud on premise and to your VMs that are on premise, not only Kubernetes clusters. There's some cool things you could do there. And now from an API security standpoint, obviously we acquired Mesh 7 not too long ago. We're pretty excited about that. You could see them sitting in the path, being a policy and be able to say, you know what? There's some weird traffic going on over here on a store locator. I wonder why everyone keeps asking about Belarus.
16:22And you could say, we don't have a store in Belarus, but it comes, it comes 100 times every millisecond. Those are kind of things that I can identify in the network. And all of a sudden maybe have an automatic policy that's generated out of it. And we stop a denial of service attack. Those kinds of things can happen now in your network. And that could, it could be very targeted at where the new request is coming from. And that can all happen at this layer of policy where you can auto generate and dynamically create policy. That is not a business function. That's something I needed to figure out at runtime. It's an operational need. And I think this gets to the point of, okay, who's involved here in, in exposing APIs. There's application operators and they're caring about the API gateway and how it functions and whether or not at runtime it's doing the right things. And it's participating maybe in the service mesh and the API security, all that stuff is working nicely. Then you got your application developer way on the other side that the perpendicular to them. And they're focused on, hey, are my mobile applications working and consuming APIs? Or is the other team in the other line of business able to use my APIs? They care about the function that's being provided and whether or not it's working for those customers, those consumers. And then you have the middle, which is this DevOps layer. And that is where I want to provide additional services to these application developers based upon the platform that we're running. And so what are some ways that I can expose that? So maybe I extend the API gateway to do more things, or maybe I extend the service mesh to do more things and have it do things in a convenient way for everyone. Maybe the continuous delivery pipeline, target environments that we deploy to dev test prod. I might have API portals that are experimental in the dev environment, but then when they go to production, they have to be blessed and become an amazing API documentation experience. So there's a lot of things that I can do in the middle, too, to help serve everyone. You think about these different actors that are involved in APIs, and I think you always want to target the solutions at each one of those rather than target a function. It's one thing to route traffic, but it's one thing to also say, I want to do it for a specific consumer of APIs versus someone who's interested in routing traffic generally across my topology.
18:31So basically, the service mesh is, to restate it, is like your operational and security things. And like you're saying, sometimes in operational security stuff, you actually get pretty deep into the application, like your bella loose thing. But that's not necessarily the business that you're running. That's just like something weird happening, right? Like that you want to wrap some policy around. Whereas at the API management or gateway level, more of what you're doing is you're saying like, so this is the application layer of how components are going to talk with each other. And we might, obviously, there's some security involved in there, but it's not really, for lack of a better phrase, very hardcore, right? It's not a platform thing. It's really like a specific targeted effort. And it's within the architecture of your application. It's not really outside of the architecture of your application to make that distinction. That's a big distinction, though. What you just said is why I think what we're doing is interesting and why a lot of customers are coming to us is because we have made that distinction. The API management solutions haven't made that distinction. They say API management is these functions and you do these things. And what we're finding is if you can vent to the developers and to the operators and help them do their own roles, like a GitOps approach where I manage gateways and you manage the route configuration for your APIs. And you might have 50 teams doing that, but I still have my one gateway that I manage and you can expose through my gateway. Now everyone can have the convenience of running on their own cycles. And yeah, so then just to sum up, or I don't know if that's the right phrase, but to repeat back so I make sure I understand. So there's at least two other things. One of them you just mentioned, which is like dependency management. And then let's call it attainability, understandability. That is documentation about things. And like the first one, I think I was reading that there's some recent book about how Amazon operates or whatever. And there was a, there's a fun phrase in there that I'm going to get it wrong. But at some point in the early two thousands, they were like, we're spending way too much time collaborating and not enough time shipping, which sounds like a very like macho way of thinking about stuff.
20:33But what that trite phrase means is it's like about dependencies. If three different parts of the business need to access this one part and each of those three people on their own, a different schedule wants to make modifications to it. They now all have to share the same schedule because you have to work in, in, in serial. You can't just change everything around. So now when people bring up the specter of dependencies, that's what they mean is basically you have to work with other people. You have to achieve consensus and compromise so that what you want doesn't necessarily not even break other people, but just conflict with them. And it seems like a lot of what you can achieve with at the API gateway layer is you can never remove complete need for dependency because like you're still using common stuff, but you can somehow address it and have it be less of a problem than, than if it was just one centralized thing. Yeah, I totally agree. So one of the things is not having the wrong dependencies, right, or being entangled. So you just don't want to be entangled a big ball of mud or the spaghetti all mashed together. So you want to be able to figure out what are these isolated pieces that can run on their own flow, but also find out when they, when their interactions are causing problems for the other side. An example of this in API world would be I'm changing from API version one to API version two. So all my consumers, how are we going to handle that? Am I going to just kick them all off? Or am I going to keep V1 up for a while and move over to V2? Or am I going to do backward compatibility tests? Am I going to deprecate an API? These are things that you want to be able to acknowledge as a way to manage the organizational strife that you could cause with a change in version for your API. That's a good example. How does the API gateway help address that? Because I think that's almost like the example. The ultimate problem it seems like organizations have is they can't do anything new. Like their whole infrastructure has concreted, if that's a verb. And like, I think a large part of why that happens is what you're saying is we have 50 or 2,000 applications using this one API or this one backend thing.
22:35And we would really like to do something better with it. We want to make it better. But because we have, I'll choose something in the middle. Because we have 300 applications using it, for whatever reason, we can't go to all 300 of them and say, hey, for the next two months, you should switch everything over to the new way of doing stuff. And then so we'll support the old version and the new one. And then we're going to support a third one. And then next thing you know, you don't have time to add any new features. And then it's almost like this vicious flywheel, a buzzsaw maybe, where basically everyone's complaining that you can't do anything new and you can't change into the applications because none of them wanted to put the time in to make sure they could use new stuff and then you're stuck. To me, how you manage that with more of an API economy is that you figure out, okay, I have version one, I have version two, and you probably have some kind of policy in terms of how teams leverage your API. Now, what's cool about a distributed model is I can have my own gateway. And not only that, we even go further down than that, we have what's called an API route configuration file. So each service could have its own one or more API route configuration files that define its APIs it wants to expose on any gateway. And so what happens there, what you could have is a version one of your YAML file and a version two of your YAML file, deploy them both, and they may actually both be pointed at a different version of the service. So you could have service v1, service v2. Just an example. It's not the only way you could do it. But then the idea there is that you now control that world and you can decide based upon the traffic. You can even watch traffic as it comes off of v1 onto v2 because they're changing their code over. You can have some kind of deprecation process as well. You can put notes into the that are generated in the open API documentation that then show an API portal that say, hey, you want to move to v2, please. Here's how you do it. You know, these are kind of things that you can start documenting and help people to that are using your API start to move. And as long as you have an opinionated way that this happens in your organization, right? And so Spring Cloud Gateway and API portal are like the spring world.
24:37So I come from the spring team. We think of the fact that you should always have a very convenient approach and use that dependency injection approach. We want to be able to say, okay, inversion and control here. We want you to have the ability to do it in an opinionated way and then configure if you need to. So if you have that opinionated way, nice thing is now you can validate whether or not you're meeting that kind of opinion or not. So that validation step can happen through those route configuration files. I can identify earlier when I'm not backward compatible or I can identify when a policy has changed on an API. And so this is something that I think that you can start putting in place in your organization that can help enable these teams to interact better together and find those potential issues that may come up as they're evolving. I feel like you've said a bunch of things during this, these last few minutes that make the validate this notion that I'm hearing as you may or may not know audience. I talk a lot with industry analyst firms. And so what I've been hearing from them for the past several months or even past year is that they're seeing a shift in demand from big all in API management platforms that are trying to be everything to everybody to more. I want to call them purpose built because I'm not sure that's the right term, but like to an API gateway type of or distributed API gateway model. So I feel like what you were talking about just now and then the point of having them for specific roles or a function, not as in function as in the small app, but as in people's actual jobs validates that this is the approach that we're hoping to see more and there's more demand. And on top of that, right, like those things aren't cheap. Yeah. And not only that, you start to think about organizational models don't have central configuration. Michael just talked about that, right? You got this thing where if you have one big platform that's serving everybody's needs and then you may try to make changes to that platform, that is not an easy thing to do. This has been known for ever. We always talk about this in all the books around technology and architecture. So I guess organizations don't run like that.
26:38And not only that, one of the things that you find is that is that by distributing things out, you can start to have a more domain driven design approach to your architecture. Right. So I can have APIs in this API gateway there specifically for my agent portal and my agents that are out in the field. And I can have this specific API gateway with the security model that's entirely different for my fraud APIs and my fraud organization. And they have totally different needs and they have different consumers. They might, the agents might use the fraud, but that doesn't mean they have the same consumers. So I think that now all of a sudden that across your whole organization is that they have very targeted, focused efforts. And you think about in domain driven design, you now have bounded context. So the idea there is now all of a sudden these boundaries are very clear who's doing what. Now, obviously in these organizations, you'll start to identify situations. Every company goes to this where you go, our bounded context is not quite right because we're having these weird situations where the teams aren't able to move the right way or they can't make decisions without talking to each other. And of course, then you have to reassess. But I think that the gateway actually can help you with that. And it can actually identify even organizational issues that you have by showing those relationships are not working quite right. So you think about domain driven design, that was one of its cool parts is that it's not only about the technical architecture, but it was actually helping you think about where your business boundaries and why. There are many layers to APIs and services and everything. And so it's always good to check in and figure out what, what the thinking is currently. So thanks for being on. I knew you first as the person who wrote the book, Managing Tech Debt. How's that? How's that book? You go look back at that every year. So it's funny. I actually went back. I went and read a little bit of it because a question came up in the team the other day. And I was like, this is actually still relevant. I was surprised. I'm managing software debt, building for inevitable change. And one of the major things I had there was that a technical debt wasn't the only debt. I found that I was going around and like they were having problems with continuous integration. They're having problems with design and also testing. We found that all these had different debt approaches that you could start to put in place and even platform experience, which was more of organizational debt.
28:43So yeah, the book is trying to siphon those out into its own parts and different ways of attacking them. I'll have to go back and look over it. But I was thinking of that because maybe to summarize a lot of the, a lot of the things we talked about that I'm interested in. That again, to make the distinction that it seems like an API gateway at that, let's call it layer seven and a half. Versus like networking management that you have service mesh level is again, a very like application architecture kind of thing where you're, you're anticipating right from the beginning, having to manage dependencies and like that debt basically. And you're trying to maximize the flexibility, like to some extent, I don't know if this would be a good long-term practice, but by being able each team who's using an API could write whatever API they wanted. And they could just muck around. I don't know what this part would be called long ago. What would we call it an adapter or whatever's behind the facade? Like they could muck around with the mapping to the official API. And then therefore the people who made the store locator could just do whatever they wanted. Like they could change things around. And like you were saying, because you've got this extra layer of that mapping between what an application is going to use when they, to the actual API for the store locator. You can, I would imagine, as they like to say, write a little script to go find the things that would be affected. And you could call up those teams and be like, you need to change this because it's changing. And if you don't want to change what your application does, you just can change this one or two files or whatever. I'll bring back service mesh for a minute. One of the cool things that you could do then is go to your service mesh and go, how many calls are being made to these different endpoints and with these type of information. And yeah, and it's all about that. It's watching all the network all the time. So that's very cool. And so with that, it's choose your own dependency adventure, right? Like each of those little apps using the store locator can make things, can make their life as hard as they want to or not. And you're better informed for it, for sure. And then also on the other hand, like we were just saying, you are putting in, you know, that there will be issues you need to deal with when it comes to dependencies and changing APIs.
30:47So you're making sure that when it comes to those exceptions or things on the margin that you've already put those tools in there to deal with that. Be on the search for who's using stuff. So you don't completely solve the problem, but you at least put your safety measures in place to make it easier to solve. Yeah, observation. Yeah, it's always nice to have. Which hopefully helps address the debt legacy problem. Which again, I think ultimately for a lot of the large organizations I talk with, that's one of their chief problems is just they can't do anything. Because they have their architecture is just gone all calcified, which is a verb, as I recall, if people wanted to look into this stuff more, where, where would you point them? Yeah, definitely. You can check out the Tanzu advanced product that's within VMware and check out more, but also just check out Spring Cloud Gateway for Kubernetes and API portal for VMware Tanzu. I'm sure if you do some searches, I think Rita, you have some things that we can, they can look at as well. We have a few what is how to videos from where you were interviewed with Redmonk that kind of really distill it into. So what is a distributed API gateway and how do you get started? So those are good ones. And then I also want to promote the GitOps for APIs. Just look for GitOps for APIs. I've done some talks on InfoQ and also with, with others. I think that's more detailed in terms of roles and how they interact with each other through these products. And why I think that GitOps approach is really important going forward. All right, great. This has been another TanzuTalk episode here. If you're listening to this, you can go to TanzuTalk.com and there's also a video that we'll post. And also, if you just want to get the show notes, links to all those things, you can go to TanzuTalk.com and look up this episode. And with that, we'll see everyone next time. Bye-bye.