1 00:00:00,000 --> 00:00:01,840 Hello. It's been a while, gang. 2 00:00:02,080 --> 00:00:06,580 We're going to be talking about API management today with our guest. Introduce yourself. 3 00:00:06,840 --> 00:00:10,980 So I'm Chris Sterling. I'm Senior Product Line Manager on API Management inside of VMware. 4 00:00:11,240 --> 00:00:15,700 Just focused on how can we make developers' lives better with the API gateways. 5 00:00:15,840 --> 00:00:20,760 You've been busy this year, this first half of the year. You've launched a couple of new things. 6 00:00:20,940 --> 00:00:22,880 Tell us a little bit about that. We'll get that out of the way. 7 00:00:23,020 --> 00:00:26,340 Talking about the API management space. We might talk about a little service mesh. 8 00:00:26,400 --> 00:00:28,920 Tell us what's new in your world. 9 00:00:28,920 --> 00:00:32,100 So we launched in February the Spring Cloud Gateway for Kubernetes. 10 00:00:32,400 --> 00:00:38,120 We had already had a Spring Cloud Gateway commercial service on Tanzu application service for VMware. 11 00:00:38,440 --> 00:00:41,100 But now we have one on Kubernetes. It'll run on any Kubernetes. 12 00:00:41,480 --> 00:00:46,340 Nice thing is what we're trying to provide is developer-friendly experience with API gateways. 13 00:00:46,480 --> 00:00:49,720 Because we heard that was a common issue for a lot of application developers. 14 00:00:49,980 --> 00:00:55,720 Using API gateways was not easy. It caused much delay. It tended to be through a centralized organization. 15 00:00:55,720 --> 00:01:00,560 So we try to make it much closer to the developer and be able to do local development all the way to production. 16 00:01:00,560 --> 00:01:05,040 And then on top of that, we had in April, the API portal for VMware Tanzu. 17 00:01:05,300 --> 00:01:11,960 So this product is a way to see open API documentation across a number of open API sources. 18 00:01:12,400 --> 00:01:17,860 And it just so happens our Spring Cloud Gateway now auto-generates open API documentation for you. 19 00:01:18,040 --> 00:01:30,020 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. 20 00:01:30,020 --> 00:01:31,920 And that could be exposed through the API portal. 21 00:01:31,920 --> 00:01:36,380 And now all of your APIs across your organization could be shown in a portal. 22 00:01:36,380 --> 00:01:38,460 What do people use API gateways for? 23 00:01:38,600 --> 00:01:40,200 Let's start with the super basic thing. 24 00:01:40,340 --> 00:01:49,760 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. 25 00:01:49,900 --> 00:01:53,120 Usually some JSON or some XML going on in there. 26 00:01:53,340 --> 00:01:57,640 And then the consumers come and they make calls through the gateway to there. 27 00:01:57,640 --> 00:02:08,540 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. 28 00:02:09,060 --> 00:02:11,340 Maybe you're doing commercial off the shelf and behind it. 29 00:02:11,380 --> 00:02:16,200 So you need to do some manipulation of the request and response as it's going through. 30 00:02:16,400 --> 00:02:21,220 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. 31 00:02:21,220 --> 00:02:27,280 So those are all kinds of things that you might put onto a gateway and it makes a consistent flow for the API consumer. 32 00:02:27,560 --> 00:02:33,260 So you might have a scenario where you're searching inventory in stores or something. 33 00:02:33,540 --> 00:02:41,420 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. 34 00:02:41,820 --> 00:02:43,640 And so they need to find a store that it's located. 35 00:02:43,800 --> 00:02:46,060 So in your app somewhere, it's find out where this is located. 36 00:02:46,060 --> 00:02:51,380 And that might go through a gateway for all the various reasons that you went over. 37 00:02:51,380 --> 00:02:54,460 Yeah, all of those might go through a gateway because they might want you authenticated. 38 00:02:54,760 --> 00:03:00,460 So now you have single sign on and now you're authenticated, but you authenticated while you were going through the front portal. 39 00:03:00,460 --> 00:03:05,200 And then the portal sent you over to see the inventory service showed you a bunch of stuff that you wanted to see. 40 00:03:05,480 --> 00:03:08,540 And then you went to the search service because you wanted to go to appliances. 41 00:03:09,000 --> 00:03:11,380 And then once you went in there, you also want to do store locator. 42 00:03:11,480 --> 00:03:13,060 So you went to the store location service. 43 00:03:13,360 --> 00:03:19,220 So all those are sitting behind the gateway, all you sharing the same session in terms of the user experience. 44 00:03:19,320 --> 00:03:26,100 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. 45 00:03:26,100 --> 00:03:28,700 And they might have a totally different continuous delivery cycle. 46 00:03:28,860 --> 00:03:32,100 They might have a totally different API evolution over time. 47 00:03:32,100 --> 00:03:35,600 So they need to be able to keep agile, keep going in a separate motion. 48 00:03:35,600 --> 00:03:36,960 So Chris, why now? 49 00:03:37,100 --> 00:03:42,280 Why did you and the gang decide this is the time to introduce this offering? 50 00:03:42,500 --> 00:03:49,440 Well, first off, we went to 80 plus customers before we even implemented the first solution, which was on tangible application service. 51 00:03:49,440 --> 00:03:56,940 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. 52 00:03:57,240 --> 00:03:59,840 And they were actually thinking about purchasing an API gateway. 53 00:04:00,120 --> 00:04:03,040 And one of the major ones was application developers. 54 00:04:03,240 --> 00:04:06,980 Many of them hated API gateways because of their experiences with them. 55 00:04:07,180 --> 00:04:12,420 We found out from surveys, it took them days and weeks to get APIs updated because they tended to go through. 56 00:04:12,500 --> 00:04:18,780 And so we found that, well, okay, that seems like a big problem that we could solve. 57 00:04:18,780 --> 00:04:28,500 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. 58 00:04:28,740 --> 00:04:30,580 They were actually using it for that purpose, too. 59 00:04:30,660 --> 00:04:32,400 They were creating multiple Spring Cloud gateways. 60 00:04:32,640 --> 00:04:38,040 So it was almost like a natural, okay, we've got a solution already that's working for customers in the open source. 61 00:04:38,380 --> 00:04:42,080 And they want some additional features that they're not going to get in open source. 62 00:04:42,280 --> 00:04:48,620 So maybe we should make a distributed API gateway and also solve some of those feature requests that they have. 63 00:04:48,620 --> 00:04:54,060 On top of that, one of the other things, the operations group even would say things like, it becomes very complex. 64 00:04:54,180 --> 00:04:57,500 They started out, I need an API gateway for this small set of teams. 65 00:04:57,680 --> 00:05:00,580 And they knew exactly what the scope of that work was. 66 00:05:00,640 --> 00:05:03,120 But then all of a sudden, everybody heard, hey, we got an API gateway. 67 00:05:03,360 --> 00:05:05,060 And then more and more teams start coming. 68 00:05:05,460 --> 00:05:08,900 And of course, they don't grow that team that does the operations around it. 69 00:05:09,040 --> 00:05:10,700 Not only that, it's centrally managed anyway. 70 00:05:10,860 --> 00:05:16,220 So even if they did, you're still going to have a lot of back and forth that is needed in that central config. 71 00:05:16,420 --> 00:05:18,000 And it just became overly complex. 72 00:05:18,200 --> 00:05:20,200 And so then they create ticketing systems. 73 00:05:20,200 --> 00:05:21,720 And that's what caused the delay. 74 00:05:21,920 --> 00:05:23,640 So we had both of those happening. 75 00:05:23,780 --> 00:05:28,500 And on top of that, we saw the adoption of our open source just skyrocketing. 76 00:05:28,500 --> 00:05:30,920 So there was quite a few things that we were finding. 77 00:05:31,180 --> 00:05:36,960 We found that the big thing that developers liked about Spring Cloud Gateways was the developer experience. 78 00:05:37,300 --> 00:05:42,260 They felt like they could attain that API gateway approach, which is really a design pattern. 79 00:05:42,380 --> 00:05:44,120 Even in networks, you have gateways. 80 00:05:44,280 --> 00:05:45,960 So you have it all, it's turtles all the way down. 81 00:05:46,060 --> 00:05:52,540 But the API gateway has a special focus, which is business value and displaying an API that provides business value. 82 00:05:52,540 --> 00:05:55,960 And it's quite different from just routability and things like that. 83 00:05:56,200 --> 00:05:58,080 In this context, what is business value? 84 00:05:58,380 --> 00:06:02,160 Like for an API, how do you define and wangle that? 85 00:06:02,340 --> 00:06:07,380 So I think that one of the things like store location, being able to expose that to others is a very powerful tool. 86 00:06:07,380 --> 00:06:09,440 And it provides value to someone. 87 00:06:09,580 --> 00:06:14,460 That's a huge value to a company that wants people to come to their stores and smell and feel their appliances. 88 00:06:14,780 --> 00:06:18,240 Value to the customer who's actually looking for the store. 89 00:06:18,240 --> 00:06:22,680 It provides value to the store because now you're potentially getting more feet through your store. 90 00:06:22,900 --> 00:06:24,360 Therefore, hopefully more sales. 91 00:06:24,580 --> 00:06:26,720 And so those are the kind of things you're trying to attain. 92 00:06:27,020 --> 00:06:36,020 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. 93 00:06:36,020 --> 00:06:42,140 What we found was that there was a lot of teams with APIs within an organization, like thousands of them. 94 00:06:42,140 --> 00:06:48,140 And sometimes the operations group had no idea that they even existed because they're not exposing their APIs outwardly. 95 00:06:48,140 --> 00:06:50,140 They're just exposing their APIs to each other. 96 00:06:50,140 --> 00:06:54,140 And they were trying to do it through point-to-point solutions, the situation we've had in the past. 97 00:06:54,140 --> 00:07:03,140 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. 98 00:07:03,140 --> 00:07:12,140 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. 99 00:07:12,140 --> 00:07:17,140 There's this internal API economy that needs to be served as well. 100 00:07:17,140 --> 00:07:23,140 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. 101 00:07:23,140 --> 00:07:27,140 Exciting back office and supply chain stuff probably goes on here too. 102 00:07:27,140 --> 00:07:28,140 I'm sure. 103 00:07:28,140 --> 00:07:35,140 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. 104 00:07:35,140 --> 00:07:37,140 And I'm always like, I don't understand what that means. 105 00:07:37,140 --> 00:07:51,140 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. 106 00:07:51,140 --> 00:07:59,140 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. 107 00:07:59,140 --> 00:08:06,140 At that level, you're obsessed with what are the capabilities this thing has that a developer or an operations person would interact with. 108 00:08:06,140 --> 00:08:14,140 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. 109 00:08:14,140 --> 00:08:18,140 But then you add in this other consideration of, but it should also do something useful. 110 00:08:18,140 --> 00:08:22,140 The first part to usefulness is that someone uses it as you are going over. 111 00:08:22,140 --> 00:08:34,140 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. 112 00:08:34,140 --> 00:08:38,140 But then if people don't use it, we get no value from it. 113 00:08:38,140 --> 00:08:40,140 Yeah, it's a product mantra, right? Convenience trumps function. 114 00:08:40,140 --> 00:08:52,140 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. 115 00:08:52,140 --> 00:08:57,140 Or becomes a distraction in my life, even worse. Every time I need to use it now, it becomes a distraction. 116 00:08:57,140 --> 00:09:04,140 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. 117 00:09:04,140 --> 00:09:12,140 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. 118 00:09:12,140 --> 00:09:16,140 It's actually the things they already have written and already provide and that they're maintaining. 119 00:09:16,140 --> 00:09:23,140 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. 120 00:09:23,140 --> 00:09:27,140 Sometimes that's making it available to mobile. There's a lot of different ways that you do that. 121 00:09:27,140 --> 00:09:36,140 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. 122 00:09:36,140 --> 00:09:39,140 Can you talk a little bit more about that? 123 00:09:39,140 --> 00:09:46,140 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. 124 00:09:46,140 --> 00:09:55,140 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? 125 00:09:55,140 --> 00:10:05,140 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. 126 00:10:05,140 --> 00:10:17,140 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. 127 00:10:17,140 --> 00:10:24,140 So does that mean in the little sidecar is the policy information for that particular bit of code that you're moving around? 128 00:10:24,140 --> 00:10:25,140 Yeah, exactly. 129 00:10:25,140 --> 00:10:28,140 So how do I, there's a few different things that can go in there. 130 00:10:28,140 --> 00:10:36,140 For instance, you might say, okay, I take traffic for this type of information or this, this route on the inside of the cluster. 131 00:10:36,140 --> 00:10:39,140 And on top of that, I might say, okay, here's some security policies. 132 00:10:39,140 --> 00:10:45,140 Like I have a certificate that identifies my container in my route to the rest of the world. 133 00:10:45,140 --> 00:10:56,140 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. 134 00:10:56,140 --> 00:10:58,140 And we call that mutual TLS, right? 135 00:10:58,140 --> 00:11:01,140 And you, there's this way for us to say, okay, yes, we can all talk to each other. 136 00:11:01,140 --> 00:11:04,140 And that could be a policy that you put into a cluster. 137 00:11:04,140 --> 00:11:06,140 Like these things can talk to these things, but not others. 138 00:11:06,140 --> 00:11:13,140 And if you recognize that conversation is more about a layer across things, it isn't about the business value. 139 00:11:13,140 --> 00:11:22,140 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. 140 00:11:22,140 --> 00:11:29,140 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. 141 00:11:29,140 --> 00:11:32,140 You might do some weighted routing, maybe do some canary deployment stuff. 142 00:11:32,140 --> 00:11:37,140 But at the same time, even through that, you're only touching a little bit of what API gateways do. 143 00:11:37,140 --> 00:11:40,140 And you could further extend it even beyond that. 144 00:11:40,140 --> 00:11:50,140 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. 145 00:11:50,140 --> 00:11:52,140 They want something that sits in front of that. 146 00:11:52,140 --> 00:12:01,140 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. 147 00:12:01,140 --> 00:12:10,140 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. 148 00:12:10,140 --> 00:12:12,140 And it's not their expertise either. 149 00:12:12,140 --> 00:12:14,140 There's other people who that's their focus. 150 00:12:14,140 --> 00:12:18,140 So what I think is the thing here is that that's not easily attainable. 151 00:12:18,140 --> 00:12:19,140 We talked about it early, right? 152 00:12:19,140 --> 00:12:22,140 It's not convenient for me to go down and write that much YAML. 153 00:12:22,140 --> 00:12:30,140 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. 154 00:12:30,140 --> 00:12:34,140 Then there's API Gateway, which is focused on the HTTP content. 155 00:12:34,140 --> 00:12:37,140 It's saying, what are the headers that I need to have here? 156 00:12:37,140 --> 00:12:40,140 What are, what's the circuit breaker pattern I want? 157 00:12:40,140 --> 00:12:42,140 Where do I want to forward requests if things are down? 158 00:12:42,140 --> 00:12:46,140 But how do I want to manipulate the path for this old service I have running on a VM back here? 159 00:12:46,140 --> 00:12:57,140 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. 160 00:12:57,140 --> 00:13:02,140 They're really about how do I want to interact and provide this function to my API consumers. 161 00:13:02,140 --> 00:13:03,140 Yeah. 162 00:13:03,140 --> 00:13:04,140 It seems we're going to need more layers. 163 00:13:04,140 --> 00:13:08,140 First of all, we're, I mean, we're already up to seven and we've run out of layers. 164 00:13:08,140 --> 00:13:10,140 Actually people talk about that as well, right? 165 00:13:10,140 --> 00:13:13,140 Maybe does anyone really know what layer one and two is or care? 166 00:13:13,140 --> 00:13:15,140 Maybe we should just take those over. 167 00:13:15,140 --> 00:13:18,140 Distributed computing could just add a whole like plethora of particular layers. 168 00:13:18,140 --> 00:13:26,140 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. 169 00:13:26,140 --> 00:13:28,140 Your internet modem on and off. 170 00:13:28,140 --> 00:13:31,140 Like you just, I don't know, man, I'll just reboot it and see what happens. 171 00:13:31,140 --> 00:13:36,140 I'm interested in talking more about this distinction between gateway stuff and service meshes. 172 00:13:36,140 --> 00:13:44,140 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? 173 00:13:44,140 --> 00:13:53,140 Where essentially at its core, what a service mesh is doing is intercepting communication between containers in a Kubernetes cluster. 174 00:13:53,140 --> 00:13:58,140 And it may intercept them and do nothing, in which case it just passes through and that's it. 175 00:13:58,140 --> 00:14:04,140 But as you're going over the other, and importantly, it's not only HTTP or S traffic. 176 00:14:04,140 --> 00:14:06,140 It's any type of network traffic. 177 00:14:06,140 --> 00:14:22,140 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. 178 00:14:22,140 --> 00:14:27,140 So like it's, you can mediate what container to container communication is, not other stuff. 179 00:14:27,140 --> 00:14:34,140 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. 180 00:14:34,140 --> 00:14:41,140 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. 181 00:14:41,140 --> 00:14:50,140 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. 182 00:14:50,140 --> 00:14:59,140 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. 183 00:14:59,140 --> 00:15:01,140 You're more like, as it would say, an endpoint. 184 00:15:01,140 --> 00:15:08,140 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. 185 00:15:08,140 --> 00:15:16,140 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. 186 00:15:16,140 --> 00:15:18,140 Like I don't care about network policy. 187 00:15:18,140 --> 00:15:24,140 Instead, what I'm mapping out is you might even call it like application policy or architecture policy. 188 00:15:24,140 --> 00:15:30,140 Like you're defining how you want the architecture to function, not how you want your network and your cluster to function. 189 00:15:30,140 --> 00:15:31,140 Exactly. 190 00:15:31,140 --> 00:15:31,140 Yeah. 191 00:15:31,140 --> 00:15:34,140 And those are almost perpendicular to each other in terms of the goals. 192 00:15:34,140 --> 00:15:37,140 The goals are different consumers entirely. 193 00:15:37,140 --> 00:15:40,140 And so I think of service mesh is really complimentary. 194 00:15:40,140 --> 00:15:43,140 And you talked about API security, you alluded to Rita. 195 00:15:43,140 --> 00:15:48,140 So now if you think about it, now I have policy at this layer, which is cross cutting, right? 196 00:15:48,140 --> 00:15:50,140 It cross cuts all of my APIs. 197 00:15:50,140 --> 00:15:54,140 And if you use something like Tansu service mesh, it even goes beyond Kubernetes, right? 198 00:15:54,140 --> 00:15:55,140 It could go to your VMs. 199 00:15:55,140 --> 00:16:05,140 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. 200 00:16:05,140 --> 00:16:07,140 There's some cool things you could do there. 201 00:16:07,140 --> 00:16:11,140 And now from an API security standpoint, obviously we acquired Mesh 7 not too long ago. 202 00:16:11,140 --> 00:16:12,140 We're pretty excited about that. 203 00:16:12,140 --> 00:16:16,140 You could see them sitting in the path, being a policy and be able to say, you know what? 204 00:16:16,140 --> 00:16:20,140 There's some weird traffic going on over here on a store locator. 205 00:16:20,140 --> 00:16:22,140 I wonder why everyone keeps asking about Belarus. 206 00:16:22,140 --> 00:16:27,140 And you could say, we don't have a store in Belarus, but it comes, it comes 100 times every millisecond. 207 00:16:27,140 --> 00:16:30,140 Those are kind of things that I can identify in the network. 208 00:16:30,140 --> 00:16:34,140 And all of a sudden maybe have an automatic policy that's generated out of it. 209 00:16:34,140 --> 00:16:36,140 And we stop a denial of service attack. 210 00:16:36,140 --> 00:16:39,140 Those kinds of things can happen now in your network. 211 00:16:39,140 --> 00:16:43,140 And that could, it could be very targeted at where the new request is coming from. 212 00:16:43,140 --> 00:16:49,140 And that can all happen at this layer of policy where you can auto generate and dynamically create policy. 213 00:16:49,140 --> 00:16:51,140 That is not a business function. 214 00:16:51,140 --> 00:16:53,140 That's something I needed to figure out at runtime. 215 00:16:53,140 --> 00:16:54,140 It's an operational need. 216 00:16:54,140 --> 00:16:59,140 And I think this gets to the point of, okay, who's involved here in, in exposing APIs. 217 00:16:59,140 --> 00:17:07,140 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. 218 00:17:07,140 --> 00:17:12,140 And it's participating maybe in the service mesh and the API security, all that stuff is working nicely. 219 00:17:12,140 --> 00:17:16,140 Then you got your application developer way on the other side that the perpendicular to them. 220 00:17:16,140 --> 00:17:20,140 And they're focused on, hey, are my mobile applications working and consuming APIs? 221 00:17:20,140 --> 00:17:23,140 Or is the other team in the other line of business able to use my APIs? 222 00:17:23,140 --> 00:17:29,140 They care about the function that's being provided and whether or not it's working for those customers, those consumers. 223 00:17:29,140 --> 00:17:32,140 And then you have the middle, which is this DevOps layer. 224 00:17:32,140 --> 00:17:39,140 And that is where I want to provide additional services to these application developers based upon the platform that we're running. 225 00:17:39,140 --> 00:17:42,140 And so what are some ways that I can expose that? 226 00:17:42,140 --> 00:17:51,140 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. 227 00:17:51,140 --> 00:17:56,140 Maybe the continuous delivery pipeline, target environments that we deploy to dev test prod. 228 00:17:56,140 --> 00:18:06,140 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. 229 00:18:06,140 --> 00:18:11,140 So there's a lot of things that I can do in the middle, too, to help serve everyone. 230 00:18:11,140 --> 00:18:20,140 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. 231 00:18:20,140 --> 00:18:31,140 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. 232 00:18:31,140 --> 00:18:37,140 So basically, the service mesh is, to restate it, is like your operational and security things. 233 00:18:37,140 --> 00:18:45,140 And like you're saying, sometimes in operational security stuff, you actually get pretty deep into the application, like your bella loose thing. 234 00:18:45,140 --> 00:18:48,140 But that's not necessarily the business that you're running. 235 00:18:48,140 --> 00:18:50,140 That's just like something weird happening, right? 236 00:18:50,140 --> 00:18:53,140 Like that you want to wrap some policy around. 237 00:18:53,140 --> 00:19:03,140 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. 238 00:19:03,140 --> 00:19:10,140 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? 239 00:19:10,140 --> 00:19:11,140 It's not a platform thing. 240 00:19:11,140 --> 00:19:13,140 It's really like a specific targeted effort. 241 00:19:13,140 --> 00:19:16,140 And it's within the architecture of your application. 242 00:19:16,140 --> 00:19:21,140 It's not really outside of the architecture of your application to make that distinction. 243 00:19:21,140 --> 00:19:22,140 That's a big distinction, though. 244 00:19:22,140 --> 00:19:29,140 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. 245 00:19:29,140 --> 00:19:31,140 The API management solutions haven't made that distinction. 246 00:19:31,140 --> 00:19:34,140 They say API management is these functions and you do these things. 247 00:19:34,140 --> 00:19:47,140 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. 248 00:19:47,140 --> 00:19:53,140 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. 249 00:19:53,140 --> 00:19:57,140 Now everyone can have the convenience of running on their own cycles. 250 00:19:57,140 --> 00:20:03,140 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. 251 00:20:03,140 --> 00:20:04,140 So there's at least two other things. 252 00:20:04,140 --> 00:20:08,140 One of them you just mentioned, which is like dependency management. 253 00:20:08,140 --> 00:20:12,140 And then let's call it attainability, understandability. 254 00:20:12,140 --> 00:20:14,140 That is documentation about things. 255 00:20:14,140 --> 00:20:21,140 And like the first one, I think I was reading that there's some recent book about how Amazon operates or whatever. 256 00:20:21,140 --> 00:20:24,140 And there was a, there's a fun phrase in there that I'm going to get it wrong. 257 00:20:24,140 --> 00:20:33,140 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. 258 00:20:33,140 --> 00:20:36,140 But what that trite phrase means is it's like about dependencies. 259 00:20:36,140 --> 00:20:46,140 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. 260 00:20:46,140 --> 00:20:51,140 They now all have to share the same schedule because you have to work in, in, in serial. 261 00:20:51,140 --> 00:20:52,140 You can't just change everything around. 262 00:20:52,140 --> 00:20:58,140 So now when people bring up the specter of dependencies, that's what they mean is basically you have to work with other people. 263 00:20:58,140 --> 00:21:06,140 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. 264 00:21:06,140 --> 00:21:23,140 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. 265 00:21:23,140 --> 00:21:29,140 Yeah, I totally agree. So one of the things is not having the wrong dependencies, right, or being entangled. 266 00:21:29,140 --> 00:21:34,140 So you just don't want to be entangled a big ball of mud or the spaghetti all mashed together. 267 00:21:34,140 --> 00:21:44,140 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. 268 00:21:44,140 --> 00:21:50,140 An example of this in API world would be I'm changing from API version one to API version two. 269 00:21:50,140 --> 00:21:52,140 So all my consumers, how are we going to handle that? 270 00:21:52,140 --> 00:21:54,140 Am I going to just kick them all off? 271 00:21:54,140 --> 00:21:57,140 Or am I going to keep V1 up for a while and move over to V2? 272 00:21:57,140 --> 00:21:59,140 Or am I going to do backward compatibility tests? 273 00:21:59,140 --> 00:22:01,140 Am I going to deprecate an API? 274 00:22:01,140 --> 00:22:10,140 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. 275 00:22:10,140 --> 00:22:11,140 That's a good example. 276 00:22:11,140 --> 00:22:14,140 How does the API gateway help address that? 277 00:22:14,140 --> 00:22:16,140 Because I think that's almost like the example. 278 00:22:16,140 --> 00:22:21,140 The ultimate problem it seems like organizations have is they can't do anything new. 279 00:22:21,140 --> 00:22:24,140 Like their whole infrastructure has concreted, if that's a verb. 280 00:22:24,140 --> 00:22:35,140 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. 281 00:22:35,140 --> 00:22:38,140 And we would really like to do something better with it. 282 00:22:38,140 --> 00:22:39,140 We want to make it better. 283 00:22:39,140 --> 00:22:41,140 But because we have, I'll choose something in the middle. 284 00:22:41,140 --> 00:22:51,140 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. 285 00:22:51,140 --> 00:22:54,140 And then so we'll support the old version and the new one. 286 00:22:54,140 --> 00:22:56,140 And then we're going to support a third one. 287 00:22:56,140 --> 00:22:59,140 And then next thing you know, you don't have time to add any new features. 288 00:22:59,140 --> 00:23:12,140 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. 289 00:23:12,140 --> 00:23:24,140 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. 290 00:23:24,140 --> 00:23:28,140 Now, what's cool about a distributed model is I can have my own gateway. 291 00:23:28,140 --> 00:23:33,140 And not only that, we even go further down than that, we have what's called an API route configuration file. 292 00:23:33,140 --> 00:23:42,140 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. 293 00:23:42,140 --> 00:23:53,140 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. 294 00:23:53,140 --> 00:23:56,140 So you could have service v1, service v2. 295 00:23:56,140 --> 00:23:57,140 Just an example. 296 00:23:57,140 --> 00:23:58,140 It's not the only way you could do it. 297 00:23:58,140 --> 00:24:04,140 But then the idea there is that you now control that world and you can decide based upon the traffic. 298 00:24:04,140 --> 00:24:09,140 You can even watch traffic as it comes off of v1 onto v2 because they're changing their code over. 299 00:24:09,140 --> 00:24:13,140 You can have some kind of deprecation process as well. 300 00:24:13,140 --> 00:24:22,140 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. 301 00:24:22,140 --> 00:24:23,140 Here's how you do it. 302 00:24:23,140 --> 00:24:28,140 You know, these are kind of things that you can start documenting and help people to that are using your API start to move. 303 00:24:28,140 --> 00:24:33,140 And as long as you have an opinionated way that this happens in your organization, right? 304 00:24:33,140 --> 00:24:37,140 And so Spring Cloud Gateway and API portal are like the spring world. 305 00:24:37,140 --> 00:24:38,140 So I come from the spring team. 306 00:24:38,140 --> 00:24:45,140 We think of the fact that you should always have a very convenient approach and use that dependency injection approach. 307 00:24:45,140 --> 00:24:48,140 We want to be able to say, okay, inversion and control here. 308 00:24:48,140 --> 00:24:53,140 We want you to have the ability to do it in an opinionated way and then configure if you need to. 309 00:24:53,140 --> 00:25:00,140 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. 310 00:25:00,140 --> 00:25:04,140 So that validation step can happen through those route configuration files. 311 00:25:04,140 --> 00:25:11,140 I can identify earlier when I'm not backward compatible or I can identify when a policy has changed on an API. 312 00:25:11,140 --> 00:25:22,140 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. 313 00:25:22,140 --> 00:25:31,140 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. 314 00:25:31,140 --> 00:25:33,140 I talk a lot with industry analyst firms. 315 00:25:33,140 --> 00:25:47,140 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. 316 00:25:47,140 --> 00:25:54,140 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. 317 00:25:54,140 --> 00:26:09,140 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. 318 00:26:09,140 --> 00:26:13,140 And on top of that, right, like those things aren't cheap. 319 00:26:13,140 --> 00:26:18,140 Yeah. And not only that, you start to think about organizational models don't have central configuration. 320 00:26:18,140 --> 00:26:19,140 Michael just talked about that, right? 321 00:26:19,140 --> 00:26:28,140 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. 322 00:26:28,140 --> 00:26:30,140 This has been known for ever. 323 00:26:30,140 --> 00:26:35,140 We always talk about this in all the books around technology and architecture. 324 00:26:35,140 --> 00:26:38,140 So I guess organizations don't run like that. 325 00:26:38,140 --> 00:26:48,140 And 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. 326 00:26:48,140 --> 00:26:56,140 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. 327 00:26:56,140 --> 00:27:04,140 And I can have this specific API gateway with the security model that's entirely different for my fraud APIs and my fraud organization. 328 00:27:04,140 --> 00:27:07,140 And they have totally different needs and they have different consumers. 329 00:27:07,140 --> 00:27:11,140 They might, the agents might use the fraud, but that doesn't mean they have the same consumers. 330 00:27:11,140 --> 00:27:17,140 So I think that now all of a sudden that across your whole organization is that they have very targeted, focused efforts. 331 00:27:17,140 --> 00:27:20,140 And you think about in domain driven design, you now have bounded context. 332 00:27:20,140 --> 00:27:24,140 So the idea there is now all of a sudden these boundaries are very clear who's doing what. 333 00:27:24,140 --> 00:27:28,140 Now, obviously in these organizations, you'll start to identify situations. 334 00:27:28,140 --> 00:27:38,140 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. 335 00:27:38,140 --> 00:27:40,140 And of course, then you have to reassess. 336 00:27:40,140 --> 00:27:43,140 But I think that the gateway actually can help you with that. 337 00:27:43,140 --> 00:27:51,140 And it can actually identify even organizational issues that you have by showing those relationships are not working quite right. 338 00:27:51,140 --> 00:28:00,140 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. 339 00:28:00,140 --> 00:28:03,140 There are many layers to APIs and services and everything. 340 00:28:03,140 --> 00:28:07,140 And so it's always good to check in and figure out what, what the thinking is currently. 341 00:28:07,140 --> 00:28:08,140 So thanks for being on. 342 00:28:08,140 --> 00:28:11,140 I knew you first as the person who wrote the book, Managing Tech Debt. 343 00:28:11,140 --> 00:28:12,140 How's that? 344 00:28:12,140 --> 00:28:13,140 How's that book? 345 00:28:13,140 --> 00:28:14,140 You go look back at that every year. 346 00:28:14,140 --> 00:28:15,140 So it's funny. 347 00:28:15,140 --> 00:28:16,140 I actually went back. 348 00:28:16,140 --> 00:28:19,140 I went and read a little bit of it because a question came up in the team the other day. 349 00:28:19,140 --> 00:28:21,140 And I was like, this is actually still relevant. 350 00:28:21,140 --> 00:28:22,140 I was surprised. 351 00:28:22,140 --> 00:28:25,140 I'm managing software debt, building for inevitable change. 352 00:28:25,140 --> 00:28:29,140 And one of the major things I had there was that a technical debt wasn't the only debt. 353 00:28:29,140 --> 00:28:33,140 I found that I was going around and like they were having problems with continuous integration. 354 00:28:33,140 --> 00:28:36,140 They're having problems with design and also testing. 355 00:28:36,140 --> 00:28:43,140 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. 356 00:28:43,140 --> 00:28:49,140 So yeah, the book is trying to siphon those out into its own parts and different ways of attacking them. 357 00:28:49,140 --> 00:28:50,140 I'll have to go back and look over it. 358 00:28:50,140 --> 00:28:55,140 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. 359 00:28:55,140 --> 00:29:02,140 That again, to make the distinction that it seems like an API gateway at that, let's call it layer seven and a half. 360 00:29:02,140 --> 00:29:19,140 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. 361 00:29:19,140 --> 00:29:31,140 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. 362 00:29:31,140 --> 00:29:32,140 And they could just muck around. 363 00:29:32,140 --> 00:29:34,140 I don't know what this part would be called long ago. 364 00:29:34,140 --> 00:29:38,140 What would we call it an adapter or whatever's behind the facade? 365 00:29:38,140 --> 00:29:41,140 Like they could muck around with the mapping to the official API. 366 00:29:41,140 --> 00:29:45,140 And then therefore the people who made the store locator could just do whatever they wanted. 367 00:29:45,140 --> 00:29:46,140 Like they could change things around. 368 00:29:46,140 --> 00:29:57,140 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. 369 00:29:57,140 --> 00:30:03,140 You can, I would imagine, as they like to say, write a little script to go find the things that would be affected. 370 00:30:03,140 --> 00:30:07,140 And you could call up those teams and be like, you need to change this because it's changing. 371 00:30:07,140 --> 00:30:12,140 And if you don't want to change what your application does, you just can change this one or two files or whatever. 372 00:30:12,140 --> 00:30:14,140 I'll bring back service mesh for a minute. 373 00:30:14,140 --> 00:30:22,140 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. 374 00:30:22,140 --> 00:30:24,140 And yeah, and it's all about that. 375 00:30:24,140 --> 00:30:26,140 It's watching all the network all the time. 376 00:30:26,140 --> 00:30:27,140 So that's very cool. 377 00:30:27,140 --> 00:30:30,140 And so with that, it's choose your own dependency adventure, right? 378 00:30:30,140 --> 00:30:36,140 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. 379 00:30:36,140 --> 00:30:38,140 And you're better informed for it, for sure. 380 00:30:38,140 --> 00:30:47,140 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. 381 00:30:47,140 --> 00:30:54,140 So 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. 382 00:30:54,140 --> 00:30:56,140 Be on the search for who's using stuff. 383 00:30:56,140 --> 00:31:03,140 So you don't completely solve the problem, but you at least put your safety measures in place to make it easier to solve. 384 00:31:03,140 --> 00:31:04,140 Yeah, observation. 385 00:31:04,140 --> 00:31:05,140 Yeah, it's always nice to have. 386 00:31:05,140 --> 00:31:08,140 Which hopefully helps address the debt legacy problem. 387 00:31:08,140 --> 00:31:15,140 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. 388 00:31:15,140 --> 00:31:24,140 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? 389 00:31:24,140 --> 00:31:25,140 Yeah, definitely. 390 00:31:25,140 --> 00:31:34,140 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. 391 00:31:34,140 --> 00:31:38,140 I'm sure if you do some searches, I think Rita, you have some things that we can, they can look at as well. 392 00:31:38,140 --> 00:31:44,140 We have a few what is how to videos from where you were interviewed with Redmonk that kind of really distill it into. 393 00:31:44,140 --> 00:31:47,140 So what is a distributed API gateway and how do you get started? 394 00:31:47,140 --> 00:31:48,140 So those are good ones. 395 00:31:48,140 --> 00:31:51,140 And then I also want to promote the GitOps for APIs. 396 00:31:51,140 --> 00:31:52,140 Just look for GitOps for APIs. 397 00:31:52,140 --> 00:31:56,140 I've done some talks on InfoQ and also with, with others. 398 00:31:56,140 --> 00:32:01,140 I think that's more detailed in terms of roles and how they interact with each other through these products. 399 00:32:01,140 --> 00:32:05,140 And why I think that GitOps approach is really important going forward. 400 00:32:05,140 --> 00:32:06,140 All right, great. 401 00:32:06,140 --> 00:32:08,140 This has been another TanzuTalk episode here. 402 00:32:08,140 --> 00:32:13,140 If you're listening to this, you can go to TanzuTalk.com and there's also a video that we'll post. 403 00:32:13,140 --> 00:32:19,140 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. 404 00:32:19,140 --> 00:32:21,140 And with that, we'll see everyone next time. 405 00:32:21,140 --> 00:32:22,140 Bye-bye.