WEBVTT 1 00:00:05.160 --> 00:00:09.039 And here we go another episode of Adventures in Dead Ops. 2 00:00:09.080 --> 00:00:11.599 Just in case you had this cup and you listening 3 00:00:11.640 --> 00:00:14.359 to your podcast player and a new episode popped up. 4 00:00:14.480 --> 00:00:17.839 This is Adventures and Dead Oops. I'm the host, Will 5 00:00:17.879 --> 00:00:23.719 Button joining me as always, Warren Parade, CTO of offers 6 00:00:24.000 --> 00:00:24.519 what's going on? 7 00:00:24.600 --> 00:00:27.199 Warren, Hey, thanks for having me back. 8 00:00:27.239 --> 00:00:31.280 Well like usual, I've really been struggling with a number 9 00:00:31.280 --> 00:00:33.320 of MDMs solutions out there. 10 00:00:33.200 --> 00:00:35.920 That are now just choosing this moment to have a problem. 11 00:00:35.920 --> 00:00:36.520 I mean, we have. 12 00:00:36.439 --> 00:00:42.240 Crowded before, and I think with Singapore Mobile Guardian just 13 00:00:42.799 --> 00:00:45.799 felt the need to make themselves known to the whole 14 00:00:45.799 --> 00:00:51.000 world as well by blocking out all their customer systems. So, 15 00:00:51.560 --> 00:00:53.799 you know, I think it really says something about mdm's 16 00:00:53.840 --> 00:00:57.359 maybe not the best solution for companies to be figuring 17 00:00:57.399 --> 00:01:02.119 out how to avoidicular security problems. 18 00:01:02.439 --> 00:01:07.040 I think it's Hollywood marketing theory. There's no publicity or 19 00:01:07.200 --> 00:01:10.560 no what's what's the phrase, I'm gonna butcher it now. 20 00:01:10.480 --> 00:01:12.599 It's no bad pr Yeah, that's the. 21 00:01:12.560 --> 00:01:16.920 One I was looking for. Thank you, because now everyone 22 00:01:16.959 --> 00:01:20.079 knows who those companies are, and so marketing is just 23 00:01:20.480 --> 00:01:26.120 having a blast with it. But today we are going 24 00:01:26.200 --> 00:01:31.920 to be talking about APIs because well, I'll save it. 25 00:01:31.959 --> 00:01:33.920 There's a lot to talk about there. But joining us 26 00:01:33.920 --> 00:01:37.760 in that conversation we have the co founder of Lunar 27 00:01:37.799 --> 00:01:41.000 dot Dev, which has been in the press a lot lately. 28 00:01:41.040 --> 00:01:44.519 I've been hearing y'all's name pop up a lot, and 29 00:01:44.599 --> 00:01:47.599 so I'm excited to have you on here joining us. 30 00:01:48.000 --> 00:01:49.439 Al Solomon, how are you. 31 00:01:49.400 --> 00:01:52.599 Man, I'm good, Thank you. Great to be here. Guys. 32 00:01:53.159 --> 00:02:00.159 I'm excited because APIs, you know, working from the infrastructure side, 33 00:02:00.480 --> 00:02:07.319 I'm never I'm never in anything other than awe at 34 00:02:07.319 --> 00:02:12.159 the number of external APIs. Our engineering teams managed to 35 00:02:13.439 --> 00:02:18.080 find somewhere on the internet creating account, get it in production, 36 00:02:18.479 --> 00:02:21.759 and then we never know about it until like we 37 00:02:22.400 --> 00:02:25.879 hit the free tier limit and then they're like, well, yeah, 38 00:02:25.960 --> 00:02:28.719 we need a paid account. It's like, wow, is that 39 00:02:28.840 --> 00:02:31.840 not something that we could have chatted about before production 40 00:02:32.039 --> 00:02:32.719 was down. 41 00:02:36.639 --> 00:02:41.159 Completely. I think that that's about like summarizing what the 42 00:02:41.240 --> 00:02:45.000 API economy is. I mean, sons of APIs, you get 43 00:02:45.039 --> 00:02:47.520 to go just connect, don't worry about it. I mean 44 00:02:47.919 --> 00:02:49.879 we'll meet later on in production and we'll see how 45 00:02:49.919 --> 00:02:51.879 things are doing. But this is like the essence of 46 00:02:51.960 --> 00:02:53.280 the API economy out there. 47 00:02:54.120 --> 00:02:56.879 That's an interesting perspective really, Like I'm not sure how 48 00:02:56.960 --> 00:03:00.919 much I've seen that, uh, but it really makes me 49 00:03:00.919 --> 00:03:04.280 think of that meme of a Chappelle with the math, 50 00:03:04.479 --> 00:03:07.400 whereas like I think it was cold, it was like, 51 00:03:07.439 --> 00:03:08.800 you know, you got any more of the you know 52 00:03:08.879 --> 00:03:12.680 free tr you know, really messing out there. 53 00:03:13.800 --> 00:03:16.560 For sure. Well we're going to dig into that a 54 00:03:16.599 --> 00:03:20.000 lot more. But first, give us a little bit about 55 00:03:20.039 --> 00:03:24.879 your background and what led you to co founding Lunar 56 00:03:24.879 --> 00:03:27.800 dot dev. Like what what decisions did you make in 57 00:03:27.840 --> 00:03:29.520 life it made you think that this is where you 58 00:03:29.560 --> 00:03:30.039 needed to be. 59 00:03:31.800 --> 00:03:34.479 Wow, that's that's a big question. This is me procrastinating 60 00:03:34.520 --> 00:03:37.120 and on all of my big, biggest decisions so far. 61 00:03:38.400 --> 00:03:41.319 That's a heavy one. But no, sol, I'm the co 62 00:03:41.360 --> 00:03:45.439 founder of Lunar Dev. I've founded Lunar with my close 63 00:03:45.479 --> 00:03:47.919 friends for the past thirty years, which is roy is 64 00:03:47.919 --> 00:03:51.039 the city of the company. We've been around since first rate. 65 00:03:51.840 --> 00:03:56.400 Actually the both of us are engineers and cybersecurity engineers 66 00:03:56.479 --> 00:03:59.960 in particular. This is like our background, low level understanding things, 67 00:04:01.719 --> 00:04:07.000 which is not exactly what Lunar does. But taking that 68 00:04:07.560 --> 00:04:12.800 mindset of cybersecurity, and you know, understanding the tool set 69 00:04:12.840 --> 00:04:16.439 that we got, we thought that there's like a lot 70 00:04:16.439 --> 00:04:21.480 of problems to solve when it comes to optimizing. At 71 00:04:21.480 --> 00:04:24.639 the beginning, you're thinking that, I mean, naturally, you're shifting 72 00:04:24.680 --> 00:04:29.040 towards optimize an infrastructure like the infrastructure that you run 73 00:04:29.120 --> 00:04:34.480 upon the cloud infrastructure. There's some cool startups in that direction. 74 00:04:35.360 --> 00:04:37.800 But I think that the signals that we picked up 75 00:04:37.839 --> 00:04:43.000 along the way is that listen, infrastructure, cloud infrastructure. That's cool, 76 00:04:43.120 --> 00:04:47.720 but me, as like a heavy consumer or third party APIs, 77 00:04:47.800 --> 00:04:49.639 this is what bugs me at the end of the day. 78 00:04:49.720 --> 00:04:54.000 This is what I'm trying to optimize on a monthly basis. Uh, 79 00:04:54.399 --> 00:04:57.600 this is like where my building sky rockets, and like 80 00:04:57.920 --> 00:05:00.759 hearing that sound and talking with other companies. I think 81 00:05:00.759 --> 00:05:03.279 that along the way we've connected the dots the dots 82 00:05:03.319 --> 00:05:07.360 and understand that, like the natural progression is that if 83 00:05:07.399 --> 00:05:09.959 companies move from on prem to the cloud and then 84 00:05:10.560 --> 00:05:13.240 they consume it in the in abundance, all that resource 85 00:05:13.279 --> 00:05:15.639 and that that resource needs to be managed and optimized. 86 00:05:15.959 --> 00:05:18.519 This is stage one, but as companies progress to be 87 00:05:18.639 --> 00:05:24.959 much more consumers of of APIs, like the subs perspective, 88 00:05:25.000 --> 00:05:28.639 of things that calls for another management and optimization here 89 00:05:28.720 --> 00:05:30.560 on top of it. So it kind of like led 90 00:05:30.639 --> 00:05:34.680 us like over month to the understanding. It wasn't like 91 00:05:34.720 --> 00:05:38.720 a one a ham moment that that like foreg our minds, 92 00:05:38.720 --> 00:05:42.959 but it was talking with different companies understanding that even 93 00:05:42.959 --> 00:05:45.439 though they're thinking that it's a different problem for each 94 00:05:45.439 --> 00:05:47.480 and one of them, it all boils down to the 95 00:05:47.480 --> 00:05:50.720 same problems, to the same type of middleware solutions. And 96 00:05:50.759 --> 00:05:54.040 then like the I think the inception of Lunar came 97 00:05:54.079 --> 00:05:56.959 to be that Okay, we can be that platform that 98 00:05:57.079 --> 00:06:00.560 can build that management and active control on top of 99 00:06:00.600 --> 00:06:03.720 your eCos, traffic, your the third pardies it as you're consuming. 100 00:06:05.120 --> 00:06:08.560 So that's like the story in a nutshell. Obviously we've 101 00:06:08.600 --> 00:06:12.040 done ap integrations, we've been optimizing them on our own, 102 00:06:12.199 --> 00:06:16.480 uh previously, but when we did it back then, we 103 00:06:16.519 --> 00:06:18.360 did the connect to dots. Only when talking with a 104 00:06:18.399 --> 00:06:20.839 lot of companies, we understood that, Okay, there's like a 105 00:06:20.879 --> 00:06:24.120 coming denominator among all of those companies. 106 00:06:24.879 --> 00:06:28.319 Yeah for sure. So like from my perspective, there's there's 107 00:06:29.759 --> 00:06:36.560 this array of APIs that's your application consumes. Each one 108 00:06:36.639 --> 00:06:42.240 of those has a separate building agreement, a separate tier, 109 00:06:43.720 --> 00:06:47.199 there's a PI keys that have to be managed for that. 110 00:06:47.720 --> 00:06:52.079 There's uh rate limiting. Each one, you know, may have 111 00:06:52.199 --> 00:06:56.920 different ways of showing that you're you're being rate limited, 112 00:06:57.079 --> 00:06:59.639 or how they return errors. You know, we won't even 113 00:06:59.639 --> 00:07:02.600 go down on the path of the APIs that return 114 00:07:02.720 --> 00:07:06.240 an HTP two hundred with a Jason blob that says 115 00:07:06.399 --> 00:07:08.199 error inside of it to let you know that there's 116 00:07:08.240 --> 00:07:10.800 an error. But like, those are all of the different 117 00:07:10.879 --> 00:07:14.240 things that you have to deal with when consuming the 118 00:07:14.319 --> 00:07:21.319 APIs for your application, and so it can be a 119 00:07:21.360 --> 00:07:25.399 lot of work. Like that's all work that is necessary 120 00:07:25.480 --> 00:07:29.839 for your application, but it's not really considered as part 121 00:07:29.920 --> 00:07:32.800 of building an application. I think a lot of us 122 00:07:33.600 --> 00:07:34.879 don't think about that. 123 00:07:34.959 --> 00:07:35.120 You know. 124 00:07:35.160 --> 00:07:37.120 We think about, oh, we've got to write our functions, 125 00:07:37.120 --> 00:07:39.639 we've got to build our Docker images, we've got to 126 00:07:39.639 --> 00:07:42.040 build the UI, and where should we put the button 127 00:07:42.079 --> 00:07:44.319 on the screen, you know, and we tend to overlook 128 00:07:44.360 --> 00:07:47.199 that until we have a production outage because of one 129 00:07:47.240 --> 00:07:48.399 of these API issues. 130 00:07:48.879 --> 00:07:51.920 He's really got some like past drama here. 131 00:07:51.399 --> 00:07:55.800 Right, this is we can just we can build this 132 00:07:55.879 --> 00:07:58.120 episode to my insurance company is therapy? 133 00:08:00.079 --> 00:08:02.639 I mean what I will really like even the two 134 00:08:02.800 --> 00:08:05.879 hundred with the error code and the body like, I'll 135 00:08:05.959 --> 00:08:10.839 take that over an API which does something either monetary related, 136 00:08:10.920 --> 00:08:15.439 physical related, or timeliness related and doesn't offer itempotency. 137 00:08:16.319 --> 00:08:19.759 Yeah, it's just and there's those there are those that 138 00:08:19.800 --> 00:08:21.319 are out there, and it's sort of ridiculous. 139 00:08:21.360 --> 00:08:21.480 You know. 140 00:08:22.519 --> 00:08:25.720 Can you go and talk to these companies and make them, 141 00:08:25.920 --> 00:08:30.040 you know, offer item potency, you know, automatic retries that 142 00:08:30.079 --> 00:08:35.519 don't double bill or don't send messages or emails to 143 00:08:35.559 --> 00:08:39.200 a user twice, Because I'd really like that. 144 00:08:40.200 --> 00:08:42.480 So you would imagine, right, I mean, if we can 145 00:08:42.519 --> 00:08:48.039 only talk with the entire API economy out there and 146 00:08:48.039 --> 00:08:51.000 and make sure that they're aligned in the same way 147 00:08:51.120 --> 00:08:54.720 so that companies will consume them better, which is one 148 00:08:54.759 --> 00:08:57.440 option that you can do. But the other option is saying, listen, 149 00:08:57.480 --> 00:09:00.159 this is a consumption problem. So let's put focus on 150 00:09:00.200 --> 00:09:03.399 the consumer another provider. Let's give active controls to the 151 00:09:03.440 --> 00:09:08.879 consumer and make the unified consumption layer or mediation there 152 00:09:08.919 --> 00:09:12.200 on top of it. I think, will you said it correctly? 153 00:09:12.240 --> 00:09:14.919 I mean most of the focus so far when it 154 00:09:14.960 --> 00:09:19.480 comes to third party APIs is around integrating with an API. 155 00:09:19.759 --> 00:09:22.600 We gotut tonnels of them. Either you're doing natively and 156 00:09:22.679 --> 00:09:25.200 you got or you doing with an iPads, you're doing 157 00:09:25.200 --> 00:09:27.039 with the marketplace. You got a lot of those solutions 158 00:09:27.039 --> 00:09:32.000 in place. They're been around for years, but there's not 159 00:09:32.120 --> 00:09:35.000 that much focus, if any, on the post integration side. 160 00:09:35.080 --> 00:09:39.519 Post integration is what happens when it's already running in production. 161 00:09:40.039 --> 00:09:44.240 Now there's a diff there's a difference between when you 162 00:09:44.320 --> 00:09:47.159 integrated with an API, with that API and now you're 163 00:09:47.200 --> 00:09:50.639 running production because in production, first of all, scale obviously, 164 00:09:50.799 --> 00:09:54.360 like immense scale that you couldn't test in staging, things 165 00:09:54.399 --> 00:09:57.360 tend to break and tends to break over time because 166 00:09:57.559 --> 00:10:02.720 scale get bigger over time, outages and the actual way 167 00:10:02.759 --> 00:10:07.519 that the API provider is behaving, you know, breaking changes, 168 00:10:07.559 --> 00:10:10.360 stuff like that. So that's something that you maybe maybe 169 00:10:10.399 --> 00:10:14.840 didn't encounter during development stage, but in production it's bound 170 00:10:14.840 --> 00:10:19.080 to happen. And I think there's less also less visibility 171 00:10:19.120 --> 00:10:23.159 and real time monitoring on the way that those APIs 172 00:10:23.200 --> 00:10:26.120 are interacting. You're interacting with those APIs, so there's a 173 00:10:26.120 --> 00:10:29.000 lot of unknowns and not a lot of focus on 174 00:10:29.039 --> 00:10:32.639 what it comes to do with managing those APIs in production. 175 00:10:33.399 --> 00:10:36.639 And this is where things begin to break. Companies begin 176 00:10:36.720 --> 00:10:38.919 to as as you described as you well describe it, 177 00:10:38.960 --> 00:10:41.799 I mean along the way when it breaks, you hear 178 00:10:41.840 --> 00:10:44.679 about it, and then obviously it takes time to understand 179 00:10:44.799 --> 00:10:47.120 does it something that has to do on the provider 180 00:10:47.200 --> 00:10:49.679 side or on my back end, So a lot of 181 00:10:49.759 --> 00:10:54.879 investigation over time, troubleshooting. It is a problem, and it's 182 00:10:54.919 --> 00:10:58.000 a problem that companies are like, you know, bearing with 183 00:10:58.039 --> 00:11:01.159 them along the way, and so it's mostly on their 184 00:11:01.200 --> 00:11:03.519 own trying to build those things on their own as 185 00:11:03.519 --> 00:11:07.840 they progress and as they grow. So definitely a problem. 186 00:11:08.159 --> 00:11:11.080 Yeah, I mean I totally get it though, because even 187 00:11:11.120 --> 00:11:15.320 with the ipass solutions or embedded eyepass, with the integrations, 188 00:11:15.919 --> 00:11:19.120 it's sort of this area where you see it as 189 00:11:19.159 --> 00:11:22.720 a blocker to start your project or start the integration 190 00:11:23.399 --> 00:11:27.240 to get the business value out. But it's just like security, 191 00:11:27.279 --> 00:11:29.480 I feel like it's one of those things where you 192 00:11:29.480 --> 00:11:32.200 can ignore it upfront and not think about it, and 193 00:11:32.240 --> 00:11:35.200 then later it's going to immediately bite you and take 194 00:11:35.240 --> 00:11:38.799 down your whole platform because the quote unquote project you 195 00:11:38.840 --> 00:11:41.600 started in your company to integrate with whatever that third 196 00:11:41.639 --> 00:11:43.600 party provider is is over. 197 00:11:43.720 --> 00:11:45.080 You know, maybe the team is gone. 198 00:11:45.440 --> 00:11:48.399 And so if you didn't start with the thought in 199 00:11:48.480 --> 00:11:50.240 mind of how are we going to make sure that 200 00:11:50.279 --> 00:11:53.879 this integration is successful over time, you're likely not in 201 00:11:53.919 --> 00:11:56.960 a very good spot where you can just do a 202 00:11:56.960 --> 00:11:59.360 little extra work and get the value out. You likely 203 00:11:59.480 --> 00:12:02.440 need a real tool to make the difference. 204 00:12:03.480 --> 00:12:08.440 I please agree with you, and I'll also refer to 205 00:12:08.480 --> 00:12:12.639 what you're saying in a term of resilience and availability. 206 00:12:12.919 --> 00:12:16.600 If you didn't thought in advance of okay, something is 207 00:12:16.600 --> 00:12:20.399 bound to happen with that third part API then, and 208 00:12:20.440 --> 00:12:23.519 you didn't thought of those retris in place, those circuit breakers, 209 00:12:24.039 --> 00:12:27.519 those fallback functions. So if one API goes down, you'll 210 00:12:27.559 --> 00:12:29.960 switch to the alternative. If you haven't thought about that, 211 00:12:30.000 --> 00:12:32.360 and by the way, most companies don't think about it 212 00:12:32.440 --> 00:12:36.799 until they encounter those things over time, then definitely, I 213 00:12:36.840 --> 00:12:39.919 mean things will be impacted. And the thing is that 214 00:12:40.480 --> 00:12:44.720 now these days, third party ap APIs SLA as a 215 00:12:44.759 --> 00:12:48.279 direct impact on your products. SLA. I mean, as we said, 216 00:12:48.320 --> 00:12:51.320 if there goes down, if they're malfunctioning, so does your product. 217 00:12:51.440 --> 00:12:55.519 So that's the mindset that we're trying to advocate to change. 218 00:12:55.600 --> 00:12:57.600 I mean, you need to think about your integrations, not 219 00:12:57.720 --> 00:13:00.559 in day one, but like in day one hundred when 220 00:13:00.559 --> 00:13:03.399 things will begin to scale and break, and what type 221 00:13:03.399 --> 00:13:07.399 of resilience have you put in place. That's the mindset 222 00:13:07.399 --> 00:13:10.360 that it's being active with the right integrations and with 223 00:13:10.440 --> 00:13:11.840 your maintenance over time. 224 00:13:12.720 --> 00:13:15.360 Yeah, and so one approach to this is you can 225 00:13:15.399 --> 00:13:19.519 do that yourself. You know, you can build in the monitoring, 226 00:13:19.559 --> 00:13:22.679 the alerting and and hope that you have the right 227 00:13:22.799 --> 00:13:26.679 error handling in place and do that for each API 228 00:13:26.840 --> 00:13:32.480 that your applications consuming. But I'm assuming that if we 229 00:13:32.600 --> 00:13:34.799 if I use something like Lunar dot dev, that I 230 00:13:34.840 --> 00:13:36.840 get a lot of that stuff for free just by 231 00:13:36.960 --> 00:13:38.279 using your platform. 232 00:13:37.879 --> 00:13:42.159 Right right, I mean worth maybe saying in a sentence 233 00:13:42.320 --> 00:13:46.279 about what we do and who we are. We're an 234 00:13:46.320 --> 00:13:53.399 API consumption management platform. We're giving that that tool or 235 00:13:53.480 --> 00:13:59.240 that platform for engineering teams to monitor, manage, and actively 236 00:13:59.279 --> 00:14:02.679 optimize their outgoing traffic. The way that the product works 237 00:14:02.720 --> 00:14:06.240 is basically by two components. So you got, first of all, 238 00:14:06.279 --> 00:14:08.879 the main thing, which is the egress gateway. This is 239 00:14:08.919 --> 00:14:12.000 where all of the API calls will run through or 240 00:14:12.039 --> 00:14:15.080 selectively the API calls that you want to manage. And 241 00:14:15.120 --> 00:14:19.039 you've got the component that will tunnel that traffic through 242 00:14:19.080 --> 00:14:21.639 the gateway instead of going to the actual provider. It 243 00:14:21.679 --> 00:14:25.200 will be tunneled or rerouted via the gateway. There's various 244 00:14:25.240 --> 00:14:26.759 methods to do so. You can do it with an 245 00:14:26.840 --> 00:14:29.360 SDK intersted of the traffic before encryption. You can do 246 00:14:29.519 --> 00:14:33.639 with you the company changing the URL and so it 247 00:14:33.679 --> 00:14:35.960 will be pointed to the gateway and at the head 248 00:14:36.000 --> 00:14:38.320 or on top of it. So there's like multiple ways 249 00:14:38.320 --> 00:14:40.279 of routing the traffic. But the main thing is that 250 00:14:40.320 --> 00:14:43.000 once the traffic is being routed to the Egress gateway, 251 00:14:43.360 --> 00:14:45.960 this is where you're seeing first of all, as you mentioned, 252 00:14:46.159 --> 00:14:49.120 visibility for the first time in real time. But what's 253 00:14:49.159 --> 00:14:51.960 important with visibility it's not just okay, those are my 254 00:14:52.039 --> 00:15:00.440 API calls. It's the actual performance performance understanding of how 255 00:15:00.480 --> 00:15:04.360 those APIs are interacting, Like what's their error, what's the latency, 256 00:15:04.559 --> 00:15:07.360 what's the duration that it takes for an API call 257 00:15:07.480 --> 00:15:11.600 to make it and make it back to your system. 258 00:15:11.840 --> 00:15:14.279 All of those things and much more. Those are the 259 00:15:14.320 --> 00:15:17.519 type of visibility there is lacking and you need that 260 00:15:17.600 --> 00:15:21.240 visibility to have all of those controls that we talked about, 261 00:15:21.279 --> 00:15:24.840 I mean, brasilience and keep track in terms of security, 262 00:15:24.879 --> 00:15:29.120 how much are you're enforcing security over your API interactions 263 00:15:29.639 --> 00:15:33.000 stuff like that. So the Egress gateway is there to 264 00:15:33.039 --> 00:15:35.440 provide it with visibility. But then on top of it, 265 00:15:36.200 --> 00:15:40.960 because the Egress gateway has actual controls over on request 266 00:15:41.120 --> 00:15:45.919 or response, you can have actual controls to modify the traffic, 267 00:15:46.399 --> 00:15:49.919 to change it, to shift it to orchestrate that traffic. 268 00:15:50.360 --> 00:15:53.720 And now you can enforce egress policies such as cashing 269 00:15:53.799 --> 00:15:57.080 API cost to throw party APIs for example, if you 270 00:15:57.080 --> 00:16:00.039 want to reduce some costs and avoid those redundant a 271 00:16:00.080 --> 00:16:05.799 PI calls, or maybe improve improve latency same aspect, or 272 00:16:05.840 --> 00:16:09.000 you want to define your own type of throubling mechanism, 273 00:16:09.080 --> 00:16:11.039 like the way that you're pacing, the way that you're 274 00:16:11.039 --> 00:16:15.639 making outgoing calls or queuing API calls by priority, all 275 00:16:15.679 --> 00:16:19.559 of those things which we can name as API middleware. 276 00:16:19.720 --> 00:16:22.799 Those are the things that once you're tunneling traffic via 277 00:16:22.879 --> 00:16:26.960 the gateway, you can have active controls upon so you 278 00:16:27.000 --> 00:16:29.159 can have better resilience as we talked about, you can 279 00:16:29.200 --> 00:16:32.039 reduce some costs, and you can have a better security 280 00:16:32.080 --> 00:16:34.759 and efficiency the way that you're interacting with those APIs 281 00:16:34.799 --> 00:16:38.159 without changing your existing infrastructure and your existing code. 282 00:16:38.759 --> 00:16:41.080 There's something about this that I really like because I 283 00:16:41.120 --> 00:16:45.000 feel like we've integrated with lots of platforms as a 284 00:16:45.039 --> 00:16:48.679 company and over my career, and something I keep getting 285 00:16:48.799 --> 00:16:52.639 back from support requests are, hey, can you send us 286 00:16:52.679 --> 00:16:57.600 your logs regarding that? And I'm like, our logs for 287 00:16:57.720 --> 00:17:02.159 calling your service? So that that thing that you're supposed 288 00:17:02.240 --> 00:17:05.240 to have, Oh yeah, we prone it after like two, 289 00:17:05.680 --> 00:17:09.200 three days or seven days. I'm like, I don't I 290 00:17:09.240 --> 00:17:11.119 don't know what to tell you, but like I'm not 291 00:17:11.359 --> 00:17:14.119 logging what's going on on your side, Like I don't 292 00:17:14.119 --> 00:17:16.240 have that ridiculous data. A matter of fact, you know 293 00:17:16.279 --> 00:17:18.160 of anything that's exactly the sort of thing that we're 294 00:17:18.240 --> 00:17:21.240 dropping intentionally unless there's a problem because I don't want 295 00:17:21.240 --> 00:17:23.200 to record unnecessary due look at. 296 00:17:23.119 --> 00:17:23.599 Data like that. 297 00:17:24.119 --> 00:17:26.599 Uh So you know, there's a there's a really interesting 298 00:17:26.680 --> 00:17:29.400 aspect here where you don't want it to be a 299 00:17:29.440 --> 00:17:32.920 first class application notion to have to care about storing 300 00:17:32.960 --> 00:17:35.759 these requestomer responses from a third party in a way. 301 00:17:36.240 --> 00:17:38.559 Either it's application data in which case you're storing in 302 00:17:38.559 --> 00:17:40.759 a different way in your database, or it's third party data, 303 00:17:40.799 --> 00:17:43.519 which like, don't you have that already that you can 304 00:17:43.640 --> 00:17:46.319 you know, use to validate whatever I'm talking about. So 305 00:17:46.920 --> 00:17:49.359 there is something huge here for support requests. And I'm 306 00:17:49.400 --> 00:17:53.400 wondering whether or not there's like a common offender that 307 00:17:53.440 --> 00:17:56.039 you find that like all your customers like, oh yeah, 308 00:17:56.079 --> 00:17:59.759 we use Lunar dot dev always with this platform or 309 00:17:59.799 --> 00:18:02.359 this platform, like there's a lot of mileage out of it. 310 00:18:03.039 --> 00:18:03.880 Can you talk about that? 311 00:18:04.640 --> 00:18:07.119 So I think that in terms of platform, I think 312 00:18:07.119 --> 00:18:10.799 that like the majority of our customers are interacting directly 313 00:18:10.839 --> 00:18:15.400 with the API provider because once again we can think 314 00:18:15.400 --> 00:18:18.440 about I mean, at least that's the pattern that we 315 00:18:18.480 --> 00:18:21.759 saw up until now. When it's a business critical API, 316 00:18:22.759 --> 00:18:25.240 you'll you want to have that direct connection. You don't 317 00:18:25.240 --> 00:18:27.119 want to be reliant on a third party that will 318 00:18:27.160 --> 00:18:29.920 tell you this and something brokes with your something has 319 00:18:29.960 --> 00:18:33.759 been broken with your API. So they're direct linkage with 320 00:18:33.799 --> 00:18:38.240 those API providers. I will say that the vast majority 321 00:18:38.279 --> 00:18:40.759 of the companies, I mean I'll shift the question a bit, 322 00:18:40.880 --> 00:18:44.400 the majority of them always want to start with visibility. 323 00:18:44.480 --> 00:18:46.440 I mean, first of all, let me understand what is 324 00:18:46.440 --> 00:18:48.920 happening out there. I mean, if there was sprawl, if 325 00:18:48.920 --> 00:18:51.640 there's lack give you discovery, give you catalog and give 326 00:18:52.000 --> 00:18:55.200 me an understanding in real time what is happening past 327 00:18:55.240 --> 00:18:59.480 that phase. You you'll be open to the understanding or 328 00:18:59.559 --> 00:19:03.359 the idea that those iterations might have problems and how 329 00:19:03.400 --> 00:19:05.559 can you remediate them. But I think that if there's 330 00:19:05.640 --> 00:19:09.839 lack a common ground among all the companies that we've 331 00:19:09.839 --> 00:19:11.920 seen is first of all, let me for the first 332 00:19:11.960 --> 00:19:15.599 time understand how my API calls are behaving, how that 333 00:19:15.720 --> 00:19:19.000 third party is interacting, so I can decide later on 334 00:19:19.359 --> 00:19:23.119 I want to actually want to shift and change and 335 00:19:23.319 --> 00:19:26.319 orchestrate the traffic so it can fit my business logic. 336 00:19:27.599 --> 00:19:29.680 I hope that answer to the question because I shifted 337 00:19:29.720 --> 00:19:32.119 it just yeah. 338 00:19:32.200 --> 00:19:38.200 I think visibility just can't be overstated enough because that's 339 00:19:38.279 --> 00:19:42.920 huge because that's the basis of your costs for APIs. 340 00:19:42.920 --> 00:19:50.480 It's it's consumption based pricing, and it's it's it's just 341 00:19:50.559 --> 00:19:55.559 critical to understand how often you're using these APIs, and 342 00:19:55.599 --> 00:19:57.400 it's really hard to do because if you have to 343 00:19:57.440 --> 00:20:02.079 implement it yourself client side for every single API that 344 00:20:02.160 --> 00:20:06.079 you consume, that's so much ated work. And if you 345 00:20:06.160 --> 00:20:08.359 try to get it to if you try to get 346 00:20:08.359 --> 00:20:11.960 it from the API provider, a lot of my experience 347 00:20:12.039 --> 00:20:15.000 with that has been that it's challenging to get you know, 348 00:20:15.480 --> 00:20:19.480 you're getting like four to twenty nine throttled, and so 349 00:20:19.559 --> 00:20:22.400 you log into their platform to see what's going on 350 00:20:23.400 --> 00:20:26.519 and they're like, yeah, you're getting throttled. I'm like, well, 351 00:20:26.799 --> 00:20:29.400 how much, how many requests are making? How long has 352 00:20:29.440 --> 00:20:31.880 this been going on? And that type of visibility is 353 00:20:31.920 --> 00:20:35.359 not there, and you've. 354 00:20:35.200 --> 00:20:41.880 Actually, i think stated not the worst use case, because 355 00:20:42.000 --> 00:20:45.880 those are API providers. They will give you some kind 356 00:20:45.920 --> 00:20:50.000 of an answer and understanding a dashboard to what is happening. 357 00:20:50.640 --> 00:20:54.119 You'd be surprised or not surprised how many APIs, I mean, 358 00:20:54.559 --> 00:20:59.200 how many APIs are not third party APIs meaning that 359 00:20:59.279 --> 00:21:02.839 the core offering of that company is not it's API. 360 00:21:03.279 --> 00:21:05.279 It's just something on the site, something that it has 361 00:21:05.359 --> 00:21:07.920 to do. Those are I mean I've heard someone, I've 362 00:21:07.920 --> 00:21:11.279 talked with someone just recently and he said, I'm going 363 00:21:11.319 --> 00:21:15.440 to classify the world of APIs into two sections. There's 364 00:21:15.720 --> 00:21:18.559 the APIs that you want to use, and the APIs 365 00:21:18.559 --> 00:21:22.359 are forced or must use. And those forced or must 366 00:21:22.519 --> 00:21:27.440 used those are probably poorly documented legacy APIs. I'm going 367 00:21:27.519 --> 00:21:30.200 to say, like a bad woord soap based APIs in 368 00:21:30.279 --> 00:21:35.079 some and those are APIs that it's hard to manage, 369 00:21:35.160 --> 00:21:38.039 it's hard to understand, like what is happening in real time? 370 00:21:38.640 --> 00:21:42.160 And and as you mentioned, it's it's it's an ongoing problem. 371 00:21:42.319 --> 00:21:45.480 And even if you did have a clear view among 372 00:21:45.599 --> 00:21:48.240 all of the API providers, like how much I'm a 373 00:21:48.279 --> 00:21:50.640 consuming real time when it's going to be when I'm 374 00:21:50.680 --> 00:21:53.599 going to hit those fourty nines, think about about the 375 00:21:53.640 --> 00:21:55.799 sheer amount of APIs that need to check each and 376 00:21:55.880 --> 00:21:59.480 every dashboard to get that understanding. I mean, it kind 377 00:21:59.480 --> 00:22:02.400 of goes show that you need to have active controls. 378 00:22:02.440 --> 00:22:06.039 You need to have that visibility from your side keeping 379 00:22:06.079 --> 00:22:09.039 track of it. I'm staying like, based on the tier 380 00:22:09.119 --> 00:22:12.839 that you've purchased, what is their usage over time when 381 00:22:12.839 --> 00:22:15.599 you're going to be bound by those forty nines And 382 00:22:15.640 --> 00:22:19.440 as we said, tech active controls upon that data. So 383 00:22:19.480 --> 00:22:21.440 if you know that like you're being bounded to hit 384 00:22:21.519 --> 00:22:24.400 those forty nine is like a week from now or 385 00:22:24.400 --> 00:22:27.079 maybe like a few minutes from now, then you want 386 00:22:27.119 --> 00:22:31.039 to change the pace or the order of outgoing API 387 00:22:31.119 --> 00:22:34.720 calls so you can prioritize your VIP customers. First, make 388 00:22:35.200 --> 00:22:39.440 those API comes first instead of the freemium customers for example. 389 00:22:39.799 --> 00:22:44.640 So visibility can go up to a certain degree from 390 00:22:44.680 --> 00:22:46.720 the provider side, and the vast majority of them are 391 00:22:46.759 --> 00:22:49.319 not giving me that full visibility. But then the controls 392 00:22:49.319 --> 00:22:51.160 of what happens and the actions that need to be 393 00:22:51.200 --> 00:22:53.880 taken upon that visibility, this is on you. This is 394 00:22:53.920 --> 00:22:59.839 the company, this is the consumer of the API. And yeah, 395 00:23:00.039 --> 00:23:03.960 this is like it is a thing. It is a thing, 396 00:23:04.119 --> 00:23:07.039 and it varies across the industries. You would imagine that 397 00:23:07.119 --> 00:23:11.599 maybe it's like just a subset of APIs. No freighting industry, 398 00:23:11.759 --> 00:23:17.319 travel tech industry, even like the companies that consume APIs 399 00:23:17.359 --> 00:23:20.039 on behalf of their customers. Think of all of the 400 00:23:20.079 --> 00:23:24.960 security posture management type of companies that they will do 401 00:23:25.039 --> 00:23:28.079