1
00:00:05,160 --> 00:00:09,039
Speaker 1: 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
Speaker 2: Warren, Hey, thanks for having me back.

8
00:00:27,239 --> 00:00:31,280
Speaker 3: 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
Speaker 2: 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
Speaker 3: 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
Speaker 1: 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
Speaker 2: It's no bad pr Yeah, that's the.

21
00:01:12,560 --> 00:01:16,920
Speaker 1: 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
Speaker 4: Man, I'm good, Thank you. Great to be here. Guys.

32
00:01:53,159 --> 00:02:00,159
Speaker 1: 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
Speaker 4: 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
Speaker 3: 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
Speaker 1: 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
Speaker 4: 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
Speaker 1: 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
Speaker 4: You know.

124
00:07:35,160 --> 00:07:37,120
Speaker 1: 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
Speaker 3: He's really got some like past drama here.

131
00:07:51,399 --> 00:07:55,800
Speaker 1: 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
Speaker 3: 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
Speaker 2: 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
Speaker 1: You know.

140
00:08:22,519 --> 00:08:25,720
Speaker 3: 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
Speaker 4: 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
Speaker 3: 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
Speaker 2: You know, maybe the team is gone.

198
00:11:45,440 --> 00:11:48,399
Speaker 3: 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
Speaker 4: 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
Speaker 1: 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
Speaker 4: 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
Speaker 3: 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
Speaker 2: Data like that.

297
00:17:24,119 --> 00:17:26,599
Speaker 3: 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
Speaker 2: Can you talk about that?

311
00:18:04,640 --> 00:18:07,119
Speaker 4: 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
Speaker 1: 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
Speaker 4: 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
some kind of a scanning and posture management. Those are like,

402
00:23:28,359 --> 00:23:32,440
once again, another problem that is being opened up. Everyone

403
00:23:32,680 --> 00:23:35,240
has its own type of sickness and problems when it

404
00:23:35,240 --> 00:23:37,519
comes to consuming APIs, and everyone has been building their

405
00:23:37,559 --> 00:23:40,200
own top of mechanisms to deal with them and to

406
00:23:40,279 --> 00:23:43,519
gain that type of visibility so that they can act accordingly.

407
00:23:44,400 --> 00:23:46,240
Speaker 1: For sure, I think the scale of this problem just

408
00:23:46,279 --> 00:23:50,759
gets more and more. I heard of a comment recently,

409
00:23:50,839 --> 00:23:52,559
and it's not one hundred percent true, but I think

410
00:23:52,559 --> 00:23:56,920
it resonates with some truth that we're not software engineers anymore.

411
00:23:57,200 --> 00:24:01,519
We're we just both differ and APIs together to get

412
00:24:01,519 --> 00:24:02,319
a different result.

413
00:24:05,119 --> 00:24:08,599
Speaker 4: Someone told me that we're the some of all of

414
00:24:08,640 --> 00:24:15,440
the APIs were consumers. It's like being philosophical over here.

415
00:24:15,720 --> 00:24:17,200
Speaker 1: That's great. I like that.

416
00:24:18,480 --> 00:24:20,599
Speaker 4: Yeah.

417
00:24:20,640 --> 00:24:23,720
Speaker 1: So in terms of working with with Lunar, what does

418
00:24:23,759 --> 00:24:28,400
it look like to use Lunar to solve this problem? Like,

419
00:24:28,440 --> 00:24:31,880
do you do all of your when you when you

420
00:24:31,920 --> 00:24:35,079
integrate with Lunar, do all of your API calls go

421
00:24:35,240 --> 00:24:40,640
to Lunar and then you relay them through there? Or

422
00:24:40,839 --> 00:24:43,160
or how does that? How does that work?

423
00:24:43,640 --> 00:24:43,880
Speaker 2: Yeah?

424
00:24:43,920 --> 00:24:46,160
Speaker 4: So, first of all, Lunar is a self hosted solution.

425
00:24:46,559 --> 00:24:49,599
We perceive ourselves as as a mediation there. So we're

426
00:24:49,599 --> 00:24:54,680
an infrastructure component. Companies are installing Lunar on their own

427
00:24:54,880 --> 00:24:57,079
managing it. You have the control plane. The control plane

428
00:24:57,079 --> 00:24:59,839
is as SaaS one, but the infrastructure itself, the egress

429
00:24:59,839 --> 00:25:02,759
and the routers of the traffic, those are self hosted.

430
00:25:03,640 --> 00:25:04,000
Speaker 1: UH.

431
00:25:04,319 --> 00:25:06,680
Speaker 4: Phase One of the of the product is saying okay,

432
00:25:07,440 --> 00:25:11,000
once you install the Egress product, the aggress gateway. Then

433
00:25:11,279 --> 00:25:14,079
you choose which APIs you want a tunnel. You can

434
00:25:14,119 --> 00:25:18,319
either choose to tunnel everything or from specific applications or

435
00:25:18,400 --> 00:25:20,759
just a subset of it. Once it's being tunneled, the

436
00:25:20,799 --> 00:25:24,799
first thing that you're getting is that discovery and that cataloging.

437
00:25:25,119 --> 00:25:27,640
That catalog has been is going to be filled up

438
00:25:27,680 --> 00:25:30,440
in real time based on the actual API calls that

439
00:25:30,519 --> 00:25:34,160
are making. The system can detect what type of API

440
00:25:34,200 --> 00:25:37,880
calls are being set outside based on the domain, uh,

441
00:25:38,759 --> 00:25:44,000
the way that domain looks like. And then once those

442
00:25:44,039 --> 00:25:46,960
API have been discovered, then you're getting that first of

443
00:25:47,000 --> 00:25:49,799
all visibility. You can either see it from the control

444
00:25:49,799 --> 00:25:52,640
plane that Lunar offers or from your data dog and

445
00:25:52,720 --> 00:25:55,640
whatever APM you're using. And on top of it, what

446
00:25:55,720 --> 00:25:58,279
we're doing this is like the next phase is on

447
00:25:58,359 --> 00:26:02,000
top of getting that visible in real time, we're saying, listen,

448
00:26:02,240 --> 00:26:05,680
we're detecting problems over here. We're seeing that I mean,

449
00:26:05,720 --> 00:26:09,440
you're surpassed a specific threshold of forty nine's for example.

450
00:26:10,039 --> 00:26:13,240
And then the active part of the system kicks in

451
00:26:13,319 --> 00:26:15,599
because now we can offer you policies we call them

452
00:26:15,799 --> 00:26:21,240
clows revidation flows that can have active controls based on

453
00:26:21,240 --> 00:26:23,720
that problem. If you're seeing a forty nine an, you

454
00:26:23,799 --> 00:26:27,839
want to paste the outgoing traffic in a way that

455
00:26:27,920 --> 00:26:32,519
you can define a R right limit policy. It can

456
00:26:32,559 --> 00:26:35,039
be a concurrency based, it can be a strategy based

457
00:26:35,079 --> 00:26:39,640
where you're holding a specific you know, pacing mind. So

458
00:26:40,559 --> 00:26:43,119
it can be also cache in some of those API calls.

459
00:26:43,200 --> 00:26:46,400
So every middleware that you can think of, we're implementing

460
00:26:46,480 --> 00:26:48,960
as we go into the system so that if you

461
00:26:49,079 --> 00:26:51,519
encountering a problem, the system will detect it over time

462
00:26:51,559 --> 00:26:53,960
and then can suggest you with a solution. A solution

463
00:26:54,200 --> 00:26:57,599
is just enforcing that policy on top of the gateway

464
00:26:57,640 --> 00:27:00,559
instead of actually writing it these days in code within

465
00:27:00,599 --> 00:27:05,079
your application. That's the way that like the system works,

466
00:27:05,079 --> 00:27:08,920
and people are onboarding additional APIs once they're gaining that

467
00:27:09,039 --> 00:27:12,079
trust with the system and then seeing additional problem with

468
00:27:12,119 --> 00:27:16,759
them enforcing them. Eventually, what we're seeing ourselves is that

469
00:27:17,119 --> 00:27:22,240
missing infrastructure layer too much needed. I think cloud native

470
00:27:22,279 --> 00:27:25,599
companies they're making API calls, they need something to manage

471
00:27:25,599 --> 00:27:28,559
and orchestrate that traffic. And this is basically lunar.

472
00:27:29,720 --> 00:27:31,279
Speaker 1: I like the fact that it's self hosted.

473
00:27:32,039 --> 00:27:38,160
Speaker 4: Yeah, I think that it's something that we grew upon

474
00:27:39,079 --> 00:27:41,359
I mean it grew on us. I mean I mean

475
00:27:41,480 --> 00:27:44,799
that maybe it was an easier decision to start us,

476
00:27:44,839 --> 00:27:47,640
but we understood that in terms of we don't don't

477
00:27:47,640 --> 00:27:50,079
want to deal with the cost of the outgoing API

478
00:27:50,200 --> 00:27:53,119
calls if it was a SAA solution, We don't want

479
00:27:53,160 --> 00:27:56,720
to have some kind of a risk in terms of

480
00:27:56,799 --> 00:28:01,160
PII being leaked outside like actually API cos of companies,

481
00:28:02,559 --> 00:28:04,599
and we want to have as low latency as possible.

482
00:28:04,640 --> 00:28:09,079
Obviously this call for a cell as solution, and this

483
00:28:09,240 --> 00:28:12,920
is like where the system and the product shifted towards

484
00:28:13,519 --> 00:28:13,799
right on.

485
00:28:14,559 --> 00:28:18,000
Speaker 3: We had a similar discussion actually internally for our products.

486
00:28:18,000 --> 00:28:22,440
But since we're not a proxy, two requests, it's a

487
00:28:22,720 --> 00:28:25,200
sort of a second request that just goes somewhere else,

488
00:28:25,240 --> 00:28:28,160
and so in that regard, it's not a concern for

489
00:28:28,240 --> 00:28:31,200
us being a SaaS. But given that a model is

490
00:28:31,240 --> 00:28:35,279
having the request go through the gateway, you would need

491
00:28:35,400 --> 00:28:39,200
realistically the gateways as close to your customers, between your

492
00:28:39,200 --> 00:28:42,960
customers and their users everywhere those users are, which is

493
00:28:43,000 --> 00:28:47,960
even more ridiculous problem than what we realistically have. And

494
00:28:48,680 --> 00:28:51,640
I can definitely see that I have to ask it's

495
00:28:51,680 --> 00:28:55,240
not like you're hijacking tls sor it's to proxy the

496
00:28:55,279 --> 00:28:59,079
traffic you have like some sort of HHDP SDK that

497
00:28:59,319 --> 00:29:02,039
you use instead of whatever the default rest or HDP

498
00:29:02,200 --> 00:29:07,039
client or soap client is that the actual application is using.

499
00:29:07,079 --> 00:29:09,920
Speaker 4: I guess that's right. I mean, if it's an est gate,

500
00:29:09,960 --> 00:29:12,279
we're's acting the traffic and then she depeat just before

501
00:29:12,319 --> 00:29:15,039
it's being equipted on that traffic, and then the ntail

502
00:29:15,039 --> 00:29:17,880
list will take place from the gateway to the third

503
00:29:17,880 --> 00:29:18,680
party appear.

504
00:29:19,279 --> 00:29:21,880
Speaker 1: Good call out, Warren, it's man in the middle as

505
00:29:21,880 --> 00:29:22,400
a service.

506
00:29:24,519 --> 00:29:28,079
Speaker 3: Well, I mean, you know, it's funny what you're talking about,

507
00:29:28,119 --> 00:29:31,759
because almost ten years ago, I feel like we were

508
00:29:31,799 --> 00:29:34,599
in this spot where all the problems you were talking

509
00:29:34,599 --> 00:29:36,920
about were exactly the things that we were dealing with.

510
00:29:36,960 --> 00:29:38,000
Speaker 2: And it wasn't about production.

511
00:29:38,160 --> 00:29:41,279
Speaker 3: It was like, we're calling out from our service to

512
00:29:41,319 --> 00:29:44,720
another service internally in our company, managed by a different team,

513
00:29:45,240 --> 00:29:47,319
and they can't handle the load that we need to

514
00:29:47,319 --> 00:29:51,559
support our customers. And so we added in a middleware

515
00:29:51,799 --> 00:29:55,960
in c sharp as it was to basically buffer the

516
00:29:56,039 --> 00:29:59,400
request going out to make sure we didn't hose them

517
00:29:59,640 --> 00:30:03,640
by sort of rate limiting ourselves and try to do

518
00:30:03,720 --> 00:30:06,119
some traffic shaping there, and like that was one of

519
00:30:06,119 --> 00:30:09,079
the things we did because they couldn't be trusted to

520
00:30:09,160 --> 00:30:13,799
handle real requests, which is just absolutely so ridiculous, And

521
00:30:13,799 --> 00:30:16,240
we open source that and like other teams started using

522
00:30:16,279 --> 00:30:19,119
it in the company, which is like the opposite of

523
00:30:19,160 --> 00:30:21,640
what you think when you want to deal with requests

524
00:30:21,640 --> 00:30:23,279
coming in and you're like, oh, well, you know, we

525
00:30:23,319 --> 00:30:25,680
want to rate limit them. We were like self rate limiting.

526
00:30:25,880 --> 00:30:27,319
And that wasn't the only time, Like, there were a

527
00:30:27,359 --> 00:30:30,519
couple other situations. The biggest one is, you know, I

528
00:30:30,519 --> 00:30:31,799
don't know how much I want to bring this up,

529
00:30:31,799 --> 00:30:33,920
but like one of our competitors in the off space

530
00:30:34,200 --> 00:30:40,240
they charge for individual client JWT token generation, and lots

531
00:30:40,240 --> 00:30:42,880
of times the application you have on your side of

532
00:30:42,920 --> 00:30:45,839
the service or micro service or whatever doesn't have a

533
00:30:45,839 --> 00:30:47,720
good idea of how to cash right. There's a lot

534
00:30:47,720 --> 00:30:51,079
of concurrency and separate containers being spun UF especially functioned

535
00:30:51,079 --> 00:30:54,160
as a service, and so internally there was a team

536
00:30:54,160 --> 00:30:58,319
at our company who wrote a proxy to like our

537
00:30:58,359 --> 00:31:03,160
now competitor to cash these requests and just return an

538
00:31:03,200 --> 00:31:05,240
outdated token if it was still valid. I'm just like,

539
00:31:07,359 --> 00:31:09,880
if you know you're running into these situations. You really

540
00:31:09,880 --> 00:31:11,519
have a couple of options here. Number one is, you know,

541
00:31:11,599 --> 00:31:14,960
please pick a different provider. Like you know, there's multiple

542
00:31:14,960 --> 00:31:17,119
third party providers. Some of them don't charge you for

543
00:31:17,160 --> 00:31:20,759
that ridiculous notion, while other than are. And obviously the

544
00:31:20,799 --> 00:31:23,240
second option is, you know, go build your something yourself

545
00:31:23,359 --> 00:31:26,160
to prevent making these calls. And the third one is,

546
00:31:26,359 --> 00:31:28,720
I guess you know, now just use lunar debt.

547
00:31:28,759 --> 00:31:29,759
Speaker 2: That's an obvious answer.

548
00:31:30,799 --> 00:31:34,799
Speaker 4: Thank you, Warrence, first of all, but I'm with you

549
00:31:34,839 --> 00:31:37,359
on that. I mean, first of all, what you're saying

550
00:31:37,400 --> 00:31:39,119
is really interesting to think the bigger companies that were

551
00:31:39,119 --> 00:31:43,359
spoken with that problem that lunar is position itself like

552
00:31:44,599 --> 00:31:48,359
active controls, the third party API conception. This is an

553
00:31:48,400 --> 00:31:54,279
internal problem because there's serving so many in like inner

554
00:31:54,319 --> 00:31:57,960
API calls that their services are being like they're having

555
00:31:58,000 --> 00:32:01,319
their own domains. They're like a third API to the organization.

556
00:32:01,720 --> 00:32:04,400
So that's like a thing. And I think that that pattern,

557
00:32:04,920 --> 00:32:06,640
as we talked just talking about it, this is like

558
00:32:06,680 --> 00:32:09,200
a common pattern. I mean, it's not it's not rocket

559
00:32:09,559 --> 00:32:13,279
rocket science in a way, but but the pattern is

560
00:32:13,319 --> 00:32:16,319
that companies have been building it on their own. Now

561
00:32:16,839 --> 00:32:20,160
we can discuss whether it makes sense to build it

562
00:32:20,200 --> 00:32:23,640
on their own. But I think that the main argument

563
00:32:23,640 --> 00:32:26,039
that I'm going to make is that why would you

564
00:32:26,039 --> 00:32:27,920
build it on your own? Yeah, you can build that

565
00:32:27,960 --> 00:32:30,759
type of gateway on your own. It's take it ticket proxy,

566
00:32:31,480 --> 00:32:34,799
choose whatever you want, choose engene x, choose a j proxy.

567
00:32:35,440 --> 00:32:37,920
You can build it. Question is why, though, I mean

568
00:32:38,400 --> 00:32:42,559
why building something to maintain third p d API integrations

569
00:32:42,599 --> 00:32:47,599
where your core purpose is innovative and like bring new

570
00:32:47,680 --> 00:32:50,279
value to the actual product that you're building, so that

571
00:32:50,440 --> 00:32:53,920
maintenance over time, it's it's something that it's like seamless

572
00:32:53,920 --> 00:32:55,920
to the I, but over time you're seeing that you're

573
00:32:55,920 --> 00:33:00,079
dedicating much more task force to manage that infrastructure, to

574
00:33:00,119 --> 00:33:01,920
make sure that it's scalable, that it's not a single

575
00:33:01,920 --> 00:33:04,799
point of failure. I mean, it becomes another thing on

576
00:33:05,319 --> 00:33:08,640
another animal on its own within your infrastructure. So we're

577
00:33:08,680 --> 00:33:12,480
saying in that build versus by dilemma, you should really

578
00:33:12,480 --> 00:33:14,960
think technical consideration, how much time will take you to

579
00:33:15,039 --> 00:33:17,920
build it and maintain and maintain it, and whether you

580
00:33:17,960 --> 00:33:20,039
need to do it as part of your core purpose.

581
00:33:20,799 --> 00:33:23,640
Like our claim is that you don't have to know

582
00:33:23,920 --> 00:33:29,480
and so you can you know, use it, you can

583
00:33:29,640 --> 00:33:31,880
work with us and as you go stuff like that.

584
00:33:31,920 --> 00:33:34,319
So yeah, I think that we're trying to shift it

585
00:33:34,400 --> 00:33:36,519
partim of you don't need to build it on your own.

586
00:33:36,599 --> 00:33:39,200
Speaker 3: Nay, yeah, I mean one of the things that really

587
00:33:39,200 --> 00:33:44,640
comes to mind is that with larger companies, their products

588
00:33:45,359 --> 00:33:47,759
with well oiled APIs, and there's very few of them

589
00:33:47,759 --> 00:33:49,079
out there that I'm like, oh, that's a good API.

590
00:33:49,160 --> 00:33:50,960
I think one that comes to mind often is strip

591
00:33:51,319 --> 00:33:54,559
you probably maybe don't need a solution like this, But

592
00:33:54,599 --> 00:33:57,319
there's so many companies out there that are making APIs

593
00:33:57,359 --> 00:33:59,920
where it's not their core competency and they're not good

594
00:34:00,440 --> 00:34:03,359
and if they offer I can't believe I'm saying this.

595
00:34:03,480 --> 00:34:08,039
Some companies don't offer multiple API keys to interact with

596
00:34:08,079 --> 00:34:12,039
their APIs. And so if you have multiple like if

597
00:34:12,079 --> 00:34:15,199
you have a company a product that interacts with one

598
00:34:15,199 --> 00:34:18,800
of the chat services, they have an API and you

599
00:34:18,880 --> 00:34:23,159
only get one API key per chat bot, and so

600
00:34:23,400 --> 00:34:25,320
what would you do if you had multiple teams in

601
00:34:25,360 --> 00:34:29,400
your company that both needed to access that chatbot, you know,

602
00:34:29,480 --> 00:34:32,400
utilized services because you have maybe two pizza teams and

603
00:34:32,480 --> 00:34:35,360
micro services and so it's not even a matter of

604
00:34:35,400 --> 00:34:38,239
building the competency yourself. It's really like, are you going

605
00:34:38,320 --> 00:34:43,440
to build this chat bot application proxy just to communicate

606
00:34:43,480 --> 00:34:45,400
with that thing? And like what would go into that event?

607
00:34:45,840 --> 00:34:48,880
And so it's not like you just build something yourself.

608
00:34:48,920 --> 00:34:51,880
It's like you really need a core thing here in

609
00:34:51,960 --> 00:34:52,440
order for.

610
00:34:52,360 --> 00:34:52,840
Speaker 1: It to work.

611
00:34:52,920 --> 00:34:55,639
Speaker 3: And well, there's an open source solution to just go

612
00:34:55,679 --> 00:34:59,559
and cross that chasm right away without having to.

613
00:35:00,320 --> 00:35:02,079
Speaker 2: I mean, you're not going to build this into your sort.

614
00:35:02,119 --> 00:35:02,880
Speaker 4: There's no way you can.

615
00:35:02,760 --> 00:35:05,559
Speaker 3: Split an apike into two services. Like that's not even

616
00:35:05,559 --> 00:35:07,679
an option, right, You're going to build a proxy.

617
00:35:07,320 --> 00:35:10,199
Speaker 4: And some Sorry I like that. I mean, this is

618
00:35:10,239 --> 00:35:14,679
a truly interesting thing that we actually seen and because

619
00:35:14,719 --> 00:35:17,480
we've heard it from customers who developed it. And I'll explain.

620
00:35:18,039 --> 00:35:20,480
This is a problem where you have multiple consumers consuming

621
00:35:20,480 --> 00:35:23,960
the same API key. Now all those consumers are sharing

622
00:35:24,000 --> 00:35:28,679
the same quota. Yeah, it's so until you've hit that problem,

623
00:35:29,199 --> 00:35:32,320
if you want to rate limit based on a single key,

624
00:35:32,519 --> 00:35:35,239
I mean, you can do it rather easily by with

625
00:35:35,400 --> 00:35:40,360
code in your application. Once you need to distribute the

626
00:35:40,440 --> 00:35:43,360
quota among different consumers, you've got to have something in

627
00:35:43,400 --> 00:35:46,199
place which is like that that single point which is

628
00:35:46,239 --> 00:35:49,320
a proxy or gateway. Now what we've done in that

629
00:35:49,360 --> 00:35:51,960
perspective is saying, listen, if we're in possession of that

630
00:35:52,039 --> 00:35:57,199
API key, then we can generate subkeys or few or keys.

631
00:35:57,320 --> 00:36:03,360
Those sub keys can be find better find grade control,

632
00:36:03,480 --> 00:36:05,920
meaning that you can have a subset of the quota

633
00:36:06,039 --> 00:36:08,199
being assigned to every key. So first of all, you

634
00:36:08,239 --> 00:36:11,000
can have granular controls over that sub key. So now

635
00:36:11,119 --> 00:36:14,719
production and staging will consume eighty twenty percent based on

636
00:36:14,760 --> 00:36:17,559
your logic for example. But the thing that you're getting

637
00:36:17,599 --> 00:36:20,760
on top of it is also a security enhancement because

638
00:36:20,840 --> 00:36:25,760
now no longer will the developers will have or the

639
00:36:25,840 --> 00:36:29,599
threat of having the actual key in plain sight. You

640
00:36:29,639 --> 00:36:33,159
will have always that generated subkey that will be translated

641
00:36:33,199 --> 00:36:35,199
within the gateway to the actual key and make those

642
00:36:35,239 --> 00:36:39,599
API calls. So all of those mechanisms in place will

643
00:36:39,599 --> 00:36:42,920
have to take place with a proxy in the middle.

644
00:36:43,559 --> 00:36:45,639
And it's an it's like an it's a non issue.

645
00:36:45,679 --> 00:36:47,360
I mean, as you said, this is like chat what

646
00:36:47,599 --> 00:36:50,280
is one option, But we've heard it all across the board,

647
00:36:50,800 --> 00:36:53,559
so that's like, this is one of the interesting patterns

648
00:36:53,559 --> 00:36:56,719
that we saw along the way with API consumption problems.

649
00:36:56,920 --> 00:36:59,400
It varies across the industries by the way, first across

650
00:37:00,199 --> 00:37:03,679
company sizes. It's one of those interesting takes. And then

651
00:37:04,039 --> 00:37:05,880
adding on top of it, think that maybe you want

652
00:37:05,920 --> 00:37:09,239
to regulate the traffic based on a cue base, so

653
00:37:09,760 --> 00:37:13,400
staging will be prioritized more production than staging, so you

654
00:37:13,440 --> 00:37:15,960
want to pace that traffic. You can do all of those,

655
00:37:16,599 --> 00:37:19,360
all those type of middleworm manipulations. Was you got that

656
00:37:20,320 --> 00:37:22,519
proxy in place or that get way in place.

657
00:37:23,360 --> 00:37:25,239
Speaker 3: I'm sparking a little bit because you said, you know,

658
00:37:25,320 --> 00:37:28,920
there's no there's no other way around this, and I'll

659
00:37:29,000 --> 00:37:31,679
tell you one because I've seen it in practice where

660
00:37:31,719 --> 00:37:35,599
all the services log their own usage and then export

661
00:37:35,599 --> 00:37:37,559
it to a third party system where they try to

662
00:37:37,599 --> 00:37:41,679
aggregate the usage backup to understand what's actually happening after

663
00:37:41,679 --> 00:37:44,639
the fact. And it just seems so nonsensical to try

664
00:37:44,679 --> 00:37:48,400
to log this data within the service because you're like

665
00:37:48,519 --> 00:37:50,960
it was bad enough before where you were sharing something,

666
00:37:51,000 --> 00:37:55,079
but now you're adding a lot of complexity to your

667
00:37:55,480 --> 00:37:58,880
logging an observability system just so that you can pull

668
00:37:58,880 --> 00:38:01,920
out this non application related metric that really has nothing

669
00:38:01,960 --> 00:38:03,440
to do with the application at all.

670
00:38:04,280 --> 00:38:06,840
Speaker 4: And I will give you another method, actual method we've

671
00:38:06,840 --> 00:38:09,400
heard this is like a company I P O company,

672
00:38:09,599 --> 00:38:15,320
a big one same problem, one key, uh two consumers.

673
00:38:16,119 --> 00:38:20,920
They're sharing that data via mail, so they're establishing a

674
00:38:21,000 --> 00:38:24,480
protocol with email of saying listen, you will not surpass

675
00:38:24,559 --> 00:38:27,400
that threshold and I will take and if we'll have

676
00:38:27,519 --> 00:38:30,039
some kind of spillover, that will relate to you with

677
00:38:30,119 --> 00:38:32,559
another email message saying listen, I've got some of that

678
00:38:32,639 --> 00:38:34,679
quota left, so you can use it. This is the

679
00:38:34,679 --> 00:38:37,280
way that it works these days. I mean not these

680
00:38:37,320 --> 00:38:42,039
days it works for companies are not having that infrastructure mindset.

681
00:38:42,679 --> 00:38:44,599
It should it should be an architecture. I mean, this

682
00:38:44,679 --> 00:38:48,400
is what you're trying to advocate out there. So yeah,

683
00:38:48,440 --> 00:38:50,920
it can it can go. It can go rogue and

684
00:38:51,360 --> 00:38:52,599
worse pretty fast.

685
00:38:53,199 --> 00:38:57,880
Speaker 1: I like the idea of issuing sub keys. That's pretty

686
00:38:57,920 --> 00:39:01,480
cool because it is very I don't I would, I

687
00:39:01,480 --> 00:39:03,239
don't know if the commons right word. But it's not

688
00:39:03,360 --> 00:39:07,880
unusual to see where you need to connect to the

689
00:39:07,960 --> 00:39:11,639
production grade API service to get the quality of data

690
00:39:11,639 --> 00:39:13,599
that you need. And so then you have a scenario

691
00:39:13,679 --> 00:39:19,639
where you have a dev application that they load test it,

692
00:39:20,199 --> 00:39:23,599
blue out your quota and now prod's dead for that.

693
00:39:25,039 --> 00:39:30,039
Speaker 4: If I had if I had a nickel, I had

694
00:39:30,039 --> 00:39:32,920
a few nickels, right, I want to want to over exaggerate,

695
00:39:33,000 --> 00:39:35,480
but uh, yeah, completely agree with you.

696
00:39:35,760 --> 00:39:38,000
Speaker 3: Yeah, I mean it's sort of ridiculous that these things exist, though,

697
00:39:38,039 --> 00:39:39,960
Like I would really like, Okay, you know, don't have

698
00:39:40,000 --> 00:39:43,400
to think about that. PROD and non PROD have different

699
00:39:43,480 --> 00:39:47,760
keys for different universes, and uh, there's no way that

700
00:39:47,800 --> 00:39:49,280
you could you could have a problem there and you

701
00:39:49,280 --> 00:39:52,239
would never need to share keys between different consumers because

702
00:39:52,239 --> 00:39:54,760
each consumer has their own key which has their own

703
00:39:54,920 --> 00:39:59,079
individual permissions there. Like that seems so table stakes to me.

704
00:40:00,119 --> 00:40:03,599
But I think I'm heavily influenced here because you know,

705
00:40:03,639 --> 00:40:05,760
we offer like API keys as a service within our

706
00:40:05,800 --> 00:40:10,119
own product, and I know not everyone's using it. Like

707
00:40:10,199 --> 00:40:11,920
I wish I could say, oh yeah, everyone's using everyone

708
00:40:11,920 --> 00:40:14,159
in the world using our products, so they have API

709
00:40:14,239 --> 00:40:16,039
keys as a service, you know, out of the box.

710
00:40:16,039 --> 00:40:18,800
But they're not like and these APIs like they're made.

711
00:40:18,800 --> 00:40:22,320
As you said, every industry has some technology which there's

712
00:40:22,320 --> 00:40:26,440
some way along the technology adoption curve for really API

713
00:40:26,559 --> 00:40:29,920
understanding like lax documentation or not even using JSON or

714
00:40:30,519 --> 00:40:33,519
binary format like compressed binary format to communicate, but they're

715
00:40:33,599 --> 00:40:38,519
using XML or SOAP or something else more ridiculous, just

716
00:40:38,559 --> 00:40:41,159
really unfortunately. I want to go back to under the

717
00:40:41,239 --> 00:40:45,199
rock that I you know, maybe live on der where

718
00:40:45,199 --> 00:40:47,400
it's a little bit nicer, where people aren't doing this.

719
00:40:48,960 --> 00:40:50,199
Speaker 4: Yeah.

720
00:40:50,239 --> 00:40:54,920
Speaker 1: So, you, Warren, you brought up the chatbot idea, and

721
00:40:54,960 --> 00:40:57,639
it made me think of the show prep notes that

722
00:40:57,679 --> 00:41:03,119
we had prior to the show, and in there you've

723
00:41:03,159 --> 00:41:08,360
got AI driven APIs. So can you elaborate on that

724
00:41:08,440 --> 00:41:11,559
phrase because I'm super curious to learn more about that.

725
00:41:12,840 --> 00:41:14,719
Speaker 4: Yeah. So, first of all, I was looking at the

726
00:41:15,440 --> 00:41:19,519
and the counter of the of the recordings that we started,

727
00:41:20,000 --> 00:41:22,599
and it's minutes forty one since we brought up AI

728
00:41:22,719 --> 00:41:29,400
for the first time, which is like, which is cool. Yeah,

729
00:41:29,679 --> 00:41:33,400
I think that maybe like the way that that I

730
00:41:33,480 --> 00:41:39,840
want to approach that topic is not necessarily AI APIs,

731
00:41:39,960 --> 00:41:44,679
but the coupling that is now taking place and will

732
00:41:44,719 --> 00:41:48,199
take place with companies trying to embed some kind of

733
00:41:48,199 --> 00:41:54,239
an AI offering to them. So obviously, like the vast

734
00:41:54,239 --> 00:42:01,960
majority of them will are and will integrate with aiapis.

735
00:42:02,079 --> 00:42:04,440
I mean, you got a bunch of them these days

736
00:42:04,719 --> 00:42:09,159
competing over cost and accuracy. And the thing is that

737
00:42:09,800 --> 00:42:13,639
we can look at AI APIs like open AI and

738
00:42:13,960 --> 00:42:18,559
Gemini and whatnot as a subset of the problem that

739
00:42:18,559 --> 00:42:20,599
we've been talking about for the past forty minutes, which

740
00:42:20,639 --> 00:42:25,039
is like API consumption problems. But if you were to

741
00:42:25,480 --> 00:42:28,599
like dive a bit deeper, then we'll stand that even

742
00:42:28,639 --> 00:42:33,559
though there are another set of APIs, there's like something

743
00:42:33,559 --> 00:42:37,639
pretty unique to them. It's either the tokens that it's

744
00:42:37,679 --> 00:42:41,480
the currency that you're using. So every API cod being

745
00:42:41,519 --> 00:42:43,960
made with the prompt can be boiled down to a

746
00:42:44,039 --> 00:42:49,159
number of tokens, which will correlate with costs. And this

747
00:42:49,239 --> 00:42:50,719
is a problem on its own. I mean, how do

748
00:42:50,760 --> 00:42:55,119
you keep track over the tokens being consumed? How do

749
00:42:55,159 --> 00:42:58,679
you have active controls and regulation on API code based

750
00:42:58,719 --> 00:43:01,920
on the number of tokens the consumed and used. So

751
00:43:01,960 --> 00:43:04,559
this is like one aspect of it, and the second

752
00:43:04,559 --> 00:43:07,679
of second of an aspect of it is security, which

753
00:43:07,719 --> 00:43:11,840
is like we just I think stretching the surface. I mean,

754
00:43:12,280 --> 00:43:14,840
how do you make sure that you're not abusing that

755
00:43:15,960 --> 00:43:19,679
AI capabilities to extract something that you weren't meant to

756
00:43:19,719 --> 00:43:22,840
extract if you're I mean, if there's a malicious actor.

757
00:43:23,119 --> 00:43:26,280
How do you make sure that you're not like sending

758
00:43:26,519 --> 00:43:30,000
over those API calls sensorive data that you weren't supposed

759
00:43:30,159 --> 00:43:34,960
supposed to send. Those are like things that begins to

760
00:43:35,000 --> 00:43:38,400
be pretty unique with AI APIs that companies need to

761
00:43:38,440 --> 00:43:41,400
think upon. And I said that the last thing or

762
00:43:41,440 --> 00:43:44,440
maybe like the third thing is cost because those are

763
00:43:44,480 --> 00:43:47,599
cost the APIs. I mean you have to have active

764
00:43:47,679 --> 00:43:50,880
controls and predictions on how much will it cost you

765
00:43:50,920 --> 00:43:53,199
to consume those APIs, And then you need to do

766
00:43:53,280 --> 00:43:56,039
like the second phase, which is okay, if that's a

767
00:43:56,119 --> 00:43:58,920
cost the API, do I actually need to make that

768
00:43:59,000 --> 00:44:02,880
API call to cheat GPT like to GPT four, or

769
00:44:02,960 --> 00:44:08,159
maybe I can have it to maybe like a less

770
00:44:08,199 --> 00:44:13,320
expensive API, maybe like open source type of APM, maybe

771
00:44:13,360 --> 00:44:15,920
like hiding face or stuff like that. So a lot

772
00:44:15,920 --> 00:44:18,840
of consideration that needs to take place, which pretty unique

773
00:44:18,880 --> 00:44:22,079
to AI. And you need to regulate that traffic as

774
00:44:22,159 --> 00:44:24,639
you need to regulate it with other APIs out there.

775
00:44:25,840 --> 00:44:27,639
And I think that this is like the next phase

776
00:44:27,679 --> 00:44:31,920
of AI and APIs and the problems that associated with

777
00:44:31,960 --> 00:44:33,679
them and will only grow over time.

778
00:44:34,440 --> 00:44:36,480
Speaker 3: I think you're underselling it here actually a little bit.

779
00:44:36,519 --> 00:44:38,360
If I think about it just a little bit longer.

780
00:44:38,679 --> 00:44:43,199
You actually have the capability of altering a hypothetical system

781
00:44:43,320 --> 00:44:49,480
prompt to restrict the responses back from AI enabled APIs,

782
00:44:49,519 --> 00:44:55,280
like hey, you know, prefects, whatever the prompt is that's

783
00:44:55,320 --> 00:44:58,079
being sent with, and your response should be less than

784
00:44:58,119 --> 00:45:01,920
one hundred characters or a hundred tokens long. And then

785
00:45:01,960 --> 00:45:05,480
you're sort of guaranteeing that extra security in there, which

786
00:45:05,519 --> 00:45:09,400
is something which isn't really necessary with non AI enabled

787
00:45:09,440 --> 00:45:11,480
ones where they don't usually count per tokens.

788
00:45:11,480 --> 00:45:13,800
Speaker 2: It's usually maybe it's by data.

789
00:45:13,559 --> 00:45:16,760
Speaker 3: Out, which isn't so common, but for sure way more

790
00:45:16,760 --> 00:45:17,840
common in the I space.

791
00:45:18,599 --> 00:45:22,559
Speaker 4: Completely agreeing with you. Yeah, and you can also talk

792
00:45:22,559 --> 00:45:27,280
about hallucinations and stuff that really lacks sicknesses of AI

793
00:45:28,519 --> 00:45:30,559
APIs on their own and how you want to deal

794
00:45:30,599 --> 00:45:32,679
with it from the application that I mean, from the

795
00:45:32,719 --> 00:45:36,800
API calls perspective. So that's lack just the beginner of things.

796
00:45:37,360 --> 00:45:40,559
All we know that if you had to, if you

797
00:45:40,639 --> 00:45:44,679
had an infrastructure that will give you controls over requesting responses,

798
00:45:45,360 --> 00:45:49,559
and you can see that full visibility including the payload,

799
00:45:49,760 --> 00:45:52,840
which within the payload before it's been improveted, you can

800
00:45:52,840 --> 00:45:56,239
see the actual prompt and everything. Then you can have

801
00:45:56,679 --> 00:45:59,800
smart decisions that can take place from a security standpoint

802
00:45:59,800 --> 00:46:03,440
of view, you from catching a standpoint of view, you know,

803
00:46:03,800 --> 00:46:08,400
usage bay pattern stuff. So yeah, that's like another aspect

804
00:46:08,400 --> 00:46:08,599
to it.

805
00:46:08,920 --> 00:46:15,320
Speaker 1: Yeah, that's crazy because when using uh an ai tech

806
00:46:15,440 --> 00:46:19,480
service like that, the scope of what you could send

807
00:46:19,559 --> 00:46:24,280
that is just limitless. And since there's direct costs associated

808
00:46:24,280 --> 00:46:29,239
with that, that's a whole new budgeting paradigm of evaluating

809
00:46:29,320 --> 00:46:32,480
is this the right use of this API or or

810
00:46:32,519 --> 00:46:34,840
should we do were doing something different there?

811
00:46:35,679 --> 00:46:42,800
Speaker 4: Exactly. There's an ongoing debate whether over time you will

812
00:46:42,840 --> 00:46:45,639
need to shift between AI A PI, so let's say

813
00:46:45,760 --> 00:46:50,840
Gemini and open AI and Mistral because of accuracy and costs,

814
00:46:52,000 --> 00:46:54,079
you know, and based on your business logic, you will

815
00:46:54,079 --> 00:46:58,320
decide for those apichos, I want to have them vieah

816
00:46:58,679 --> 00:47:01,239
Opening Eye because it will be less expensive or maybe

817
00:47:01,320 --> 00:47:04,920
more accurate or the other alternative. This is like one

818
00:47:04,960 --> 00:47:09,039
aspect that maybe will unfold over time. But the other

819
00:47:09,559 --> 00:47:14,639
claim is that actually those AI APIs will converge and

820
00:47:15,920 --> 00:47:18,480
the best, like the big players out there, will kind

821
00:47:18,480 --> 00:47:22,760
of even out in terms of accuracy and cost, and

822
00:47:22,800 --> 00:47:24,719
then the only player that you have to play is

823
00:47:24,760 --> 00:47:27,480
with the niche. AI APIs those are that has been

824
00:47:27,519 --> 00:47:30,599
trained on a specific model. They will give you that

825
00:47:30,960 --> 00:47:35,039
fine brained offering to it. As I said, like, it's

826
00:47:35,039 --> 00:47:39,119
still the early days. We're not none of us know

827
00:47:39,280 --> 00:47:42,039
at that point of time what will be the way

828
00:47:42,079 --> 00:47:44,840
that companies will consume AI APIs at scale. All we

829
00:47:44,960 --> 00:47:48,639
know is that they will consume it at scale. They

830
00:47:48,679 --> 00:47:51,880
will have to regulate the traffic, have proper controls, see

831
00:47:51,880 --> 00:47:56,000
the prompt take actions accordingly, have visibility. So there's like

832
00:47:56,079 --> 00:47:58,719
a lot of things to be unfold. I think over

833
00:47:58,800 --> 00:48:03,440
time and I'll spark. Another thing here is that we're apatam.

834
00:48:03,440 --> 00:48:07,559
Now we've been talking about direct consumption of AI. I

835
00:48:07,559 --> 00:48:11,599
mean you're making some kind of a call and that

836
00:48:11,920 --> 00:48:15,199
has been streamed as an API called to to opening

837
00:48:15,280 --> 00:48:18,519
up for example. But the next phase that people were

838
00:48:18,559 --> 00:48:22,480
talking about and just starting to you know, unravel is

839
00:48:22,639 --> 00:48:27,559
those AI agents, which means that an agent will be

840
00:48:27,599 --> 00:48:31,480
able to make other API calls based on IS integrations

841
00:48:31,519 --> 00:48:34,880
with other systems that you have within the organization. So

842
00:48:34,960 --> 00:48:38,800
that AI agent will spark, like propagate a lot of

843
00:48:38,840 --> 00:48:42,960
API calls from other API integrations. Think about the sheer

844
00:48:42,960 --> 00:48:45,760
amount of API traffic that will be sent via that

845
00:48:47,079 --> 00:48:50,440
uncontrolled AI agent, that component that is not even like

846
00:48:50,679 --> 00:48:53,360
a human. This is like something that embedded within your

847
00:48:53,480 --> 00:48:56,360
own product, and now it was making all of those

848
00:48:56,400 --> 00:48:59,199
API calls, connecting so many places, making those I do

849
00:48:59,239 --> 00:49:04,000
you keep tracking it? So this is like another I

850
00:49:04,000 --> 00:49:07,039
think challenge on its own that will unfold over time.

851
00:49:07,599 --> 00:49:11,039
Speaker 3: I mean, I think part of the struggle here is

852
00:49:11,079 --> 00:49:15,119
the value maybe not so clear, and so by the

853
00:49:15,119 --> 00:49:19,480
companies offering AIS as a service or APIs that give

854
00:49:19,519 --> 00:49:22,400
access to an AI as a service because otherwise they

855
00:49:22,400 --> 00:49:26,000
probably would charge by value and not by tokens. And

856
00:49:26,039 --> 00:49:27,639
then I think we'll get to a better state. But

857
00:49:27,880 --> 00:49:31,039
we've already gotten to the point where niches have popped up,

858
00:49:31,639 --> 00:49:35,000
things like sentiment analysis or image generation or so like.

859
00:49:35,079 --> 00:49:39,159
There are already this case where a single prompt may

860
00:49:39,599 --> 00:49:43,400
focus going into a different direction based off of whatever

861
00:49:43,400 --> 00:49:44,840
the sort of data that we're looking for. So I

862
00:49:44,880 --> 00:49:49,039
think both of your hypotheses are It's not a duality.

863
00:49:49,039 --> 00:49:51,559
Both of them are true. We'll get niches of AIS

864
00:49:52,079 --> 00:49:54,000
of having to select the appropriate model at the right

865
00:49:54,039 --> 00:49:56,559
time depending on the type of data that you're looking for.

866
00:49:56,840 --> 00:49:59,440
But we're already at the point. I think of the

867
00:49:59,480 --> 00:50:03,760
other fact as well, where individual companies are being more commoditized,

868
00:50:03,800 --> 00:50:05,400
like you like, oh, I don't care if I use

869
00:50:05,440 --> 00:50:08,559
Gemini or Opening Eye or Anthropics Claude model, like they're

870
00:50:08,599 --> 00:50:11,400
all like, you know, one's better than other.

871
00:50:11,519 --> 00:50:11,719
Speaker 2: May be.

872
00:50:12,079 --> 00:50:14,239
Speaker 3: I think those companies that have the most money, though,

873
00:50:14,320 --> 00:50:17,599
will be the ones that go forth and just do

874
00:50:17,679 --> 00:50:20,199
the Aw's better Rock thing, which is we're just going

875
00:50:20,280 --> 00:50:23,119
to call all the models from every company at once

876
00:50:23,519 --> 00:50:26,079
and use it to compare the results, because it offers

877
00:50:26,119 --> 00:50:27,320
a couple of different strategies.

878
00:50:27,320 --> 00:50:27,599
Speaker 2: Actually.

879
00:50:27,639 --> 00:50:30,079
Speaker 3: The first one is you know that the result is

880
00:50:30,159 --> 00:50:33,320
sort of higher probability to be right. The second one

881
00:50:33,440 --> 00:50:36,000
is that if one of the models has a security vulnerability,

882
00:50:36,239 --> 00:50:39,280
the other ones will actually refuse to return the same answer,

883
00:50:39,519 --> 00:50:41,840
so you'll know that there's a problem with the request

884
00:50:41,920 --> 00:50:44,039
of the prompt that's gone out there. So if you're

885
00:50:44,039 --> 00:50:47,880
just passing along the colors, you know, a data entry.

886
00:50:48,079 --> 00:50:49,440
Speaker 2: But I think positioning.

887
00:50:48,960 --> 00:50:51,760
Speaker 3: Yourself in this in this spot here does have a

888
00:50:51,840 --> 00:50:55,679
huge sort of untapped security aspect that I imagine today

889
00:50:55,719 --> 00:50:58,719
people may not even really be thinking about, but they

890
00:50:58,719 --> 00:50:59,119
should be.

891
00:51:00,440 --> 00:51:06,119
Speaker 4: Yeah, an interesting perspective. What you said out there pretty cool.

892
00:51:06,199 --> 00:51:08,360
I mean I'm assuming that not of the not all

893
00:51:08,400 --> 00:51:12,280
companies will have the ability to just make a course

894
00:51:12,320 --> 00:51:15,840
to every API provider out there, But that's interesting. This

895
00:51:15,840 --> 00:51:18,000
This is also a way to, i think, to battle

896
00:51:18,039 --> 00:51:20,480
with hallucination in the way I mean take the answer

897
00:51:20,519 --> 00:51:25,760
of one model and then round the same like same

898
00:51:25,800 --> 00:51:28,039
thing on top of the other model and compare between them.

899
00:51:28,360 --> 00:51:30,199
Speaker 3: I mean, if you're interested about this topic, there's a

900
00:51:30,199 --> 00:51:35,480
great GitHub repository that was created by Remy McCarthy and

901
00:51:35,880 --> 00:51:39,639
Clinton Gibbler of a TLDR where they went through like

902
00:51:39,679 --> 00:51:43,280
fifty different AI related papers, recent ones about how to

903
00:51:43,320 --> 00:51:47,039
deal with problem of the am models and real strategy

904
00:51:47,119 --> 00:51:49,119
is take the output from the model and pass it

905
00:51:49,320 --> 00:51:51,039
to the input of another model and say, hey, like

906
00:51:51,079 --> 00:51:54,039
regenerate the prompt and do this cycle or you know

907
00:51:54,239 --> 00:51:57,199
saying you know, split the the prompt into two pieces

908
00:51:57,360 --> 00:51:59,679
and run it against different models and then combining the result.

909
00:51:59,719 --> 00:52:02,679
And you do multiple of these things over and over again,

910
00:52:03,000 --> 00:52:06,679
and it sort of eliminates the possibility of malicious actor.

911
00:52:07,360 --> 00:52:09,400
So like, if this is an interesting topic, like there's

912
00:52:09,440 --> 00:52:11,440
there there's so many of these are like wow, you

913
00:52:11,480 --> 00:52:13,639
could really be doing a lot of interesting things in

914
00:52:13,679 --> 00:52:14,119
this space.

915
00:52:14,679 --> 00:52:16,960
Speaker 4: That's really cool. Yeah, it is truly interesting.

916
00:52:18,199 --> 00:52:19,719
Speaker 1: That's going deep down the rabbit hole.

917
00:52:22,679 --> 00:52:23,800
Speaker 2: I gonna go deep down there.

918
00:52:23,840 --> 00:52:27,639
Speaker 3: There's this article that came out that said that still

919
00:52:27,760 --> 00:52:30,559
no companies are making money from AI in any way,

920
00:52:30,880 --> 00:52:33,519
shape or form other than I guess in Nvidia right

921
00:52:33,559 --> 00:52:34,599
for selling the shovels.

922
00:52:38,079 --> 00:52:41,239
Speaker 4: Yes, I think that every time that I'm speaking about

923
00:52:41,360 --> 00:52:44,320
like AI, AI, A P I is the future of

924
00:52:44,400 --> 00:52:48,320
it it all. Eventually it will sound like a Bacon

925
00:52:48,400 --> 00:52:53,320
Morphy episode along the way, and that's what I'm saying, Like, Okay,

926
00:52:53,360 --> 00:52:55,960
I gotta unfold, like I gotta go back, I gotta

927
00:52:55,960 --> 00:52:56,400
go back.

928
00:52:56,679 --> 00:52:58,760
Speaker 3: I mean basically, there was that one episode where it

929
00:52:58,800 --> 00:53:01,159
was like the story worry within the story with the

930
00:53:01,199 --> 00:53:03,039
train dude, and the end of it was like a

931
00:53:03,079 --> 00:53:04,960
heist and he's like, that's what I want to do

932
00:53:05,039 --> 00:53:06,480
to think, That's what I want to do to think,

933
00:53:06,519 --> 00:53:08,639
and they were like just stuck at an infinite cycle here.

934
00:53:08,760 --> 00:53:10,599
Speaker 2: That's that's for sure where we're going.

935
00:53:13,679 --> 00:53:19,320
Speaker 4: Exactly unsubscribe. I'm one off.

936
00:53:23,199 --> 00:53:25,960
Speaker 1: So I want to shift topics here real quick. Let's

937
00:53:25,960 --> 00:53:26,800
talk about running.

938
00:53:28,280 --> 00:53:30,760
Speaker 4: Let's stuck about running. All right, let's do it.

939
00:53:31,280 --> 00:53:32,920
Speaker 1: Yeah, so I take your runner.

940
00:53:34,079 --> 00:53:37,000
Speaker 4: I am not a pro one, but it's something I've

941
00:53:37,000 --> 00:53:41,599
been doing for since since adolescence, right.

942
00:53:41,480 --> 00:53:46,480
Speaker 1: On, Like long distance, you have a specialty, favorite thing

943
00:53:46,519 --> 00:53:46,719
to do.

944
00:53:48,360 --> 00:53:50,360
Speaker 4: So I think I'm trying to keep the casual. I've

945
00:53:50,360 --> 00:53:52,559
been running like as much as I can, like two

946
00:53:52,599 --> 00:53:56,119
or three times a week and usually, so I'm going

947
00:53:56,199 --> 00:53:58,480
to go with the metric system. I can't relate it

948
00:53:58,519 --> 00:54:02,599
to miles fair enough, apologies and advanced to all of

949
00:54:02,639 --> 00:54:07,119
our audience. I don't apologize, but it's like between ten

950
00:54:07,199 --> 00:54:12,679
to fifteen and Kate. So yeah, this is like a

951
00:54:12,719 --> 00:54:16,400
way to clean your your mind and find teeing yourself

952
00:54:16,400 --> 00:54:20,559
and just like you know, really stress something I've been

953
00:54:20,559 --> 00:54:22,360
doing for a lot of time. It's like my own

954
00:54:22,400 --> 00:54:25,000
type of meditation. Yeah.

955
00:54:25,320 --> 00:54:28,119
Speaker 1: I'm glad you went there because I did an experiment

956
00:54:28,239 --> 00:54:30,920
last year with running and that was one of the

957
00:54:30,960 --> 00:54:36,480
big unexpected learnings I had is that running really is meditation.

958
00:54:38,280 --> 00:54:40,159
And when I when I first started running, you know,

959
00:54:40,280 --> 00:54:43,199
I had music going and stuff, and then over time

960
00:54:43,280 --> 00:54:48,400
I just ditched everything because for two reasons. One because

961
00:54:48,920 --> 00:54:53,039
running long distance running was such a meditative experience that

962
00:54:54,199 --> 00:54:57,679
whenever you got done, it was like, wow, I feel

963
00:54:57,719 --> 00:55:01,920
so much better despite being physically hired. But the other

964
00:55:02,119 --> 00:55:04,360
thing I learned was like, there's actually a lot to

965
00:55:04,440 --> 00:55:08,079
keep track of while you're running. You know, you're focused

966
00:55:08,119 --> 00:55:11,199
on what's my run cadence? Look like, where am I

967
00:55:11,320 --> 00:55:14,559
landing on my feet? Is my is my stride? Right?

968
00:55:14,719 --> 00:55:17,719
What's my respiratory rate? You know, and there's so much,

969
00:55:17,760 --> 00:55:20,000
so many things that you need to focus on to

970
00:55:20,039 --> 00:55:22,920
do this effectively. That if you have music playing as

971
00:55:22,960 --> 00:55:27,760
a distraction, then you you're you're running quality suffers from

972
00:55:27,800 --> 00:55:30,360
it as well as you don't get that great meditative

973
00:55:30,400 --> 00:55:31,360
experience out of it.

974
00:55:32,280 --> 00:55:35,320
Speaker 2: I agree, Yeah, sorry, go ahead.

975
00:55:35,320 --> 00:55:37,599
Speaker 3: Sorry the you know, I used to do this and

976
00:55:37,760 --> 00:55:40,639
I had the arran thoughts like that would be like,

977
00:55:40,719 --> 00:55:43,280
oh oh no, like there is this bug in production

978
00:55:43,480 --> 00:55:46,519
somewhere that I would like, like I wrote code that

979
00:55:46,599 --> 00:55:48,639
you know is a problem, or I just thought of

980
00:55:48,679 --> 00:55:50,480
this thing that I have to like I have to

981
00:55:50,480 --> 00:55:53,159
write it down, Like I'd just be like an hour later,

982
00:55:53,199 --> 00:55:55,000
I'd be like, Okay, what was that thing that I

983
00:55:55,440 --> 00:55:57,199
figured out while I was meditating?

984
00:55:57,639 --> 00:55:58,800
Speaker 2: Uh, you know, while running?

985
00:55:58,840 --> 00:56:01,079
Speaker 3: And it was like a huge problem and I never

986
00:56:01,119 --> 00:56:02,480
really really got over that.

987
00:56:03,800 --> 00:56:06,039
Speaker 4: So I think that if you were to multiply the

988
00:56:06,119 --> 00:56:09,639
duration of your run it was you, you will go

989
00:56:09,760 --> 00:56:12,800
past that. What was what was I thinking about? And

990
00:56:12,840 --> 00:56:15,280
it's like it doesn't matter. I mean everything is a

991
00:56:15,320 --> 00:56:19,920
federal in life. I mean, I mean it doesn't really matter.

992
00:56:20,000 --> 00:56:27,039
I mean it's okay exactly. Yeah, So I know, like

993
00:56:27,239 --> 00:56:30,599
I want to. I think that's the right time to

994
00:56:30,679 --> 00:56:36,000
surface it that you're saying. Like usually in your episodes,

995
00:56:37,400 --> 00:56:40,480
the person that it's making is being interviewed as some

996
00:56:40,599 --> 00:56:43,239
kind of recommendation to make, And I thought about what

997
00:56:43,280 --> 00:56:46,039
I want to want to recommend, and that's this. There's

998
00:56:46,119 --> 00:56:48,920
this book that I've read a few years ago, one

999
00:56:48,920 --> 00:56:53,119
of my favorites. It's called bon Bone to one right,

1000
00:56:53,239 --> 00:56:55,159
and it talks have you heard about this one?

1001
00:56:55,719 --> 00:56:57,639
Speaker 1: I've read this one is such a great book.

1002
00:56:58,239 --> 00:57:00,800
Speaker 4: I love it. You heard about it? Robin?

1003
00:57:01,920 --> 00:57:02,000
Speaker 3: No?

1004
00:57:02,159 --> 00:57:05,559
Speaker 4: Actually, so this this, dude, it's like an actual story.

1005
00:57:05,599 --> 00:57:09,239
It's not something fictional. It's fictional. It's not science fiction.

1006
00:57:10,760 --> 00:57:13,599
He is pained by running, He want to gave up

1007
00:57:13,639 --> 00:57:15,800
on that is a journalist and then he heard about

1008
00:57:15,800 --> 00:57:20,679
this tribe in the in Mexico in Mexico, in rural Mexico,

1009
00:57:20,960 --> 00:57:23,840
that they're running the long distance miles. I mean as

1010
00:57:23,840 --> 00:57:25,840
a way of living. They don't have cars. They're just

1011
00:57:25,960 --> 00:57:28,599
running for a living. And it goes out to this

1012
00:57:28,880 --> 00:57:32,000
to this tribe and he like discovers that they're the

1013
00:57:32,719 --> 00:57:36,800
ultimate ultra marathon runners. I mean they can run for

1014
00:57:37,039 --> 00:57:39,960
miles over miles without getting tired. There actually can beat

1015
00:57:40,280 --> 00:57:45,400
the vast majority of the pro ultramarathon runners. And then

1016
00:57:45,599 --> 00:57:49,239
is investigated over time you understand that like people are

1017
00:57:49,239 --> 00:57:52,840
actually born to run, I mean one of the old

1018
00:57:52,880 --> 00:57:55,800
methods of hunting. And he founds like a tribe that

1019
00:57:55,920 --> 00:58:00,480
actually still doing it in in Africa. They're running until

1020
00:58:00,519 --> 00:58:05,000
they're like until that the cattle or the target is

1021
00:58:05,039 --> 00:58:09,639
being you know, exhausted. Because humans as opposed to other

1022
00:58:10,239 --> 00:58:13,960
most of the mammals can really have endurance over time

1023
00:58:14,000 --> 00:58:17,599
because they have sweats so they can ventilate everything. Most

1024
00:58:17,639 --> 00:58:21,360
animals will have to breathe to do so, and it's

1025
00:58:21,400 --> 00:58:24,920
like breathe per gallop because there are four legged animals,

1026
00:58:25,159 --> 00:58:28,320
so they can outpace you at any time. But eventually,

1027
00:58:28,840 --> 00:58:32,920
like fifty k of running, they will crash down being

1028
00:58:32,920 --> 00:58:35,559
exhausted and this is where you're going to stick your ar,

1029
00:58:36,199 --> 00:58:40,519
you know, sphear and take take me down back home.

1030
00:58:40,719 --> 00:58:44,280
So kind of saying that, like at the gist of things,

1031
00:58:44,400 --> 00:58:48,320
people are born to run for long distance runners in

1032
00:58:48,440 --> 00:58:51,920
our anatomy, and we just forget about it along the

1033
00:58:52,760 --> 00:58:56,440
you know, over the course of years. Yeah.

1034
00:58:56,559 --> 00:59:00,519
Speaker 1: I really like that format of book because the author

1035
00:59:00,679 --> 00:59:03,079
and I can't remember the author's name, but the way

1036
00:59:03,119 --> 00:59:06,840
they broke the book up was it's an entertaining story

1037
00:59:07,199 --> 00:59:10,079
in itself, but then they would break up the sections

1038
00:59:10,079 --> 00:59:14,079
of the story and go into the science of why

1039
00:59:14,159 --> 00:59:18,199
that part of the story was true or how that

1040
00:59:18,239 --> 00:59:20,920
part of the story works. And so the book would

1041
00:59:20,920 --> 00:59:24,679
switch back and forth between here's like an entertaining section

1042
00:59:24,719 --> 00:59:27,719
of the story, here's the science behind that, here's the

1043
00:59:27,760 --> 00:59:29,880
next part of the story, here's the science behind that.

1044
00:59:30,239 --> 00:59:33,159
And so it was both entertaining and educational at the

1045
00:59:33,159 --> 00:59:35,920
same time and just a fascinating read.

1046
00:59:37,039 --> 00:59:40,079
Speaker 4: Completely agree with you. By the way, this is the

1047
00:59:40,119 --> 00:59:42,440
book that sparked the barefoot.

1048
00:59:42,079 --> 00:59:47,480
Speaker 1: Running trend, right, so do you run barefoot?

1049
00:59:47,719 --> 00:59:52,559
Speaker 4: No way, I'm not of the trend. I'm just like

1050
00:59:52,599 --> 00:59:55,760
talking about the trends, but I'm giving my nikes and

1051
00:59:55,800 --> 00:59:58,679
I'm good to go. No, it's too painful to try

1052
00:59:58,760 --> 01:00:02,079
to adapt to Breft trying for sure.

1053
01:00:03,840 --> 01:00:07,159
Speaker 1: Agreed. Agreed. Now that's that was a cool book if

1054
01:00:08,119 --> 01:00:10,159
even if you're not interested in running. It's just a

1055
01:00:10,199 --> 01:00:16,519
really cool story because it talks about you know, humans

1056
01:00:16,960 --> 01:00:20,079
historically and and how we how we survived up until

1057
01:00:20,119 --> 01:00:23,719
this point. And then there's just the educational takeaways as well.

1058
01:00:24,440 --> 01:00:24,960
Cool pick.

1059
01:00:26,079 --> 01:00:28,320
Speaker 4: Thank you, m Warren.

1060
01:00:28,360 --> 01:00:29,719
Speaker 1: What'd you bring for a pick this week?

1061
01:00:30,280 --> 01:00:34,119
Speaker 3: My pick is I didn't have something relevant, so it's

1062
01:00:34,320 --> 01:00:38,280
it's gonna be uh, definitely separate. It's a book again,

1063
01:00:38,320 --> 01:00:40,440
because you know I I go through my whole book

1064
01:00:40,480 --> 01:00:44,639
lest and it's never split The Difference by Chris Boss Yeah,

1065
01:00:45,440 --> 01:00:48,239
uh yeah. I mean it sounds like it's a book

1066
01:00:48,239 --> 01:00:53,280
about negotiation. Uh and I don't think that's accurate. I

1067
01:00:53,320 --> 01:00:57,039
really like it as a mindset shift for when you

1068
01:00:57,199 --> 01:01:02,199
think there are only two computating outcomes for a situation.

1069
01:01:03,559 --> 01:01:08,440
Speaker 2: I like this salary negotiation as an example. It's like if.

1070
01:01:08,280 --> 01:01:09,840
Speaker 3: You say, oh, you know this, I want this much

1071
01:01:09,840 --> 01:01:11,800
money and someone else says no, like you know, we

1072
01:01:11,800 --> 01:01:14,840
can only pay you that much. It's sort of a

1073
01:01:15,039 --> 01:01:18,639
not a smart way to approach the conversation. Instead, you

1074
01:01:18,719 --> 01:01:23,159
want to attach every extra dollar, for instance, in a

1075
01:01:23,199 --> 01:01:27,000
salary negotiation, to something concrete, like I'm worth this much

1076
01:01:27,039 --> 01:01:30,400
more because of my experience. You know this money. Number

1077
01:01:30,440 --> 01:01:32,519
of years of experience is worth this much. This many

1078
01:01:32,760 --> 01:01:35,400
more years is worth that much, And then you're sort

1079
01:01:35,400 --> 01:01:39,519
of agreeing or disagreeing about the relationship between something concrete

1080
01:01:39,840 --> 01:01:43,639
and the money in a salary negotiation rather than arbitrary like, oh,

1081
01:01:43,679 --> 01:01:46,519
you know, let's just throw out arbitrary numbers. I think

1082
01:01:46,559 --> 01:01:49,519
that's really important because it's really gotten me to shift

1083
01:01:49,519 --> 01:01:51,880
my focus when I feel like I may be in

1084
01:01:51,920 --> 01:01:55,719
a negotiation situation about what we're actually talking about and

1085
01:01:55,760 --> 01:01:58,920
where my value is personally or where the value.

1086
01:01:58,719 --> 01:01:59,639
Speaker 2: Doing something is.

1087
01:02:00,239 --> 01:02:04,199
Speaker 3: Especially like evaluating software products comes up a lot. It

1088
01:02:04,360 --> 01:02:06,199
can be very difficult to evaluate, you know, which ones

1089
01:02:06,239 --> 01:02:09,840
we want to use, which ones are good, And if

1090
01:02:09,880 --> 01:02:11,639
people just get into a conversation of like, oh this

1091
01:02:11,679 --> 01:02:13,400
one's better, you know, do this and not do that,

1092
01:02:13,599 --> 01:02:15,480
it doesn't really come out that well. But if you're

1093
01:02:15,519 --> 01:02:18,599
able to evaluate, okay, we will do that, if this

1094
01:02:18,880 --> 01:02:22,119
or if we need that, it really has the extra mindset,

1095
01:02:22,239 --> 01:02:24,239
and I think this book really helped me get there.

1096
01:02:26,000 --> 01:02:29,599
Speaker 1: And that's another one of those books where Chris Voss,

1097
01:02:29,639 --> 01:02:36,280
the author, his background, he was a former FBI hostage negotiator. Yeah,

1098
01:02:36,320 --> 01:02:38,920
and so the book format is very similar to Born

1099
01:02:38,960 --> 01:02:41,840
to Run, where he'll tell you this cool story about

1100
01:02:41,840 --> 01:02:46,239
this hostage negotiation scenario he was in, and then he

1101
01:02:46,360 --> 01:02:52,000
breaks down the specific technical components of negotiation that he

1102
01:02:52,159 --> 01:02:55,039
used in that scenario. So it's that two part thing,

1103
01:02:55,079 --> 01:02:57,599
you know, where here's a really entertaining story, here's the

1104
01:02:57,719 --> 01:03:01,679
educational component. Here's another entertaining story. Here's the educational component.

1105
01:03:01,880 --> 01:03:03,320
Just that format is so cool to me.

1106
01:03:04,000 --> 01:03:06,199
Speaker 2: I bet you really like The Martian.

1107
01:03:07,960 --> 01:03:09,159
Speaker 1: I don't think I've read that.

1108
01:03:09,719 --> 01:03:14,519
Speaker 2: Oh no, like see the movie though.

1109
01:03:15,199 --> 01:03:19,400
Speaker 3: Oh okay, So there is this cult favorite story out

1110
01:03:19,440 --> 01:03:22,079
there that's been out there for so long, So andy,

1111
01:03:22,119 --> 01:03:26,199
where is the author? And it's called The Egg, I think,

1112
01:03:26,800 --> 01:03:32,480
and it's it's like a philosophy on like what life is,

1113
01:03:33,000 --> 01:03:35,480
and it's so old. And then I read The Martian

1114
01:03:35,480 --> 01:03:37,199
and I'm like, this is great. And then I found

1115
01:03:37,239 --> 01:03:40,159
out that I had actually read The Egg, which is

1116
01:03:40,239 --> 01:03:43,639
just it's like translated into like thirty languages by people.

1117
01:03:43,679 --> 01:03:47,119
It's a very short short story, but it definitely goes

1118
01:03:47,159 --> 01:03:49,920
into it like it's it's very science based, but there's

1119
01:03:49,920 --> 01:03:52,320
some story and then the main character is telling about

1120
01:03:52,320 --> 01:03:55,199
the science of why they're able to do what they're doing.

1121
01:03:55,239 --> 01:03:57,320
And so in the Martian he's stuck on Mars and

1122
01:03:57,360 --> 01:04:00,920
he's in a precarious situation, and there's a second there

1123
01:04:00,960 --> 01:04:03,559
where it's like, oh, I need to grow potatoes. It's like, okay,

1124
01:04:03,920 --> 01:04:05,800
let me tell you about the science of growing potatoes.

1125
01:04:06,000 --> 01:04:07,320
Speaker 4: And then I did read this book.

1126
01:04:07,400 --> 01:04:10,079
Speaker 1: Yeah, I did read it.

1127
01:04:10,119 --> 01:04:10,280
Speaker 4: Yeah.

1128
01:04:10,280 --> 01:04:12,239
Speaker 1: I didn't recognize the name because that was the movie

1129
01:04:12,320 --> 01:04:17,960
with Mark Wahlberg, right, No, made Damon. I think Matt Damon,

1130
01:04:18,440 --> 01:04:22,000
Marky Mark and the Funky Bunch or whatever his name

1131
01:04:22,039 --> 01:04:22,480
really is.

1132
01:04:24,079 --> 01:04:28,199
Speaker 3: Yeah, yeah, yeah, for sure. So I think it's really

1133
01:04:28,199 --> 01:04:30,760
well done from that regard. Yeah, but my pick officially

1134
01:04:30,840 --> 01:04:32,079
is going to be Never Spoke the Difference.

1135
01:04:32,599 --> 01:04:37,719
Speaker 1: Yeah cool. Both of those are great books though, Yeah,

1136
01:04:37,840 --> 01:04:42,199
super cool. All right, So my pick, I'm going with

1137
01:04:42,400 --> 01:04:47,239
a video slash music pick this week because the YouTube

1138
01:04:47,320 --> 01:04:53,840
algorithm has figured out that I can't resist watching reaction

1139
01:04:54,039 --> 01:04:58,800
videos to musical performances, and there's a YouTuber called the

1140
01:04:58,920 --> 01:05:05,360
Charismatic Voice and the specific video I watched, I've watched

1141
01:05:05,360 --> 01:05:07,000
a couple of them. The one that I most recently

1142
01:05:07,039 --> 01:05:11,159
watched was her reaction to the Iron Maidens song The Trooper.

1143
01:05:12,239 --> 01:05:17,039
And so she's a classically trained vocalist and she's watching

1144
01:05:17,079 --> 01:05:20,119
this heavy metal video. You know, Iron Maiden is straight

1145
01:05:20,159 --> 01:05:22,599
up heavy metal if you're not familiar with them, and

1146
01:05:22,639 --> 01:05:24,239
reacting to it. But the cool the part that makes

1147
01:05:24,320 --> 01:05:28,800
us cool is she just gets so into it because

1148
01:05:28,800 --> 01:05:31,599
you can just see her passion and her enthusiasm, which

1149
01:05:31,639 --> 01:05:36,000
makes watching the or listening to the song that much

1150
01:05:36,039 --> 01:05:39,679
more enjoyable. So she just has a great personality. And

1151
01:05:39,719 --> 01:05:42,079
then also same thing, you know, to watch part of

1152
01:05:42,079 --> 01:05:43,639
the video and then stop and then give you the

1153
01:05:43,800 --> 01:05:47,599
educational or the technical breakdown of that specific piece of it.

1154
01:05:48,000 --> 01:05:50,199
I think I'm picking up on a pattern here of

1155
01:05:50,400 --> 01:05:55,719
things that I like. But anyway, so YouTube the Chromatic Voice,

1156
01:05:56,000 --> 01:05:59,800
the reaction to Iron Maidens The Trooper was really good.

1157
01:06:00,960 --> 01:06:04,760
Or she did a reaction to the led Zeppelin song.

1158
01:06:06,159 --> 01:06:08,599
Um shoot, I'm drawing a blank on the name of

1159
01:06:08,639 --> 01:06:10,480
the song, but there was a she did a led

1160
01:06:10,559 --> 01:06:14,559
Zeppelin song and she just lost her shit in that.

1161
01:06:14,639 --> 01:06:17,079
I mean, she couldn't stop giggling. She was enjoying it

1162
01:06:17,119 --> 01:06:18,639
so much so it was really cool to watch.

1163
01:06:19,119 --> 01:06:21,119
Speaker 3: I think you actually did the led Zeppelin song as

1164
01:06:21,159 --> 01:06:23,360
a previous pick because of her.

1165
01:06:23,920 --> 01:06:28,079
Speaker 1: Could be yeah, very well, could be cool. All right,

1166
01:06:28,519 --> 01:06:30,039
Well that's going to bring us to the end of

1167
01:06:30,039 --> 01:06:32,760
our episode. To all of the listeners, thank you so

1168
01:06:32,840 --> 01:06:35,679
much for listening. Be sure and let us know on

1169
01:06:35,800 --> 01:06:40,760
LinkedIn X or whatever your social media platform of choice is,

1170
01:06:41,039 --> 01:06:45,320
or if you Google for I don't know, probably forty

1171
01:06:45,320 --> 01:06:48,079
five fifty seconds, she will find my email address. Feel

1172
01:06:48,079 --> 01:06:51,440
free to shoot me an email as well. Like if

1173
01:06:51,880 --> 01:06:54,239
if every scammer on Earth can find my email address

1174
01:06:54,239 --> 01:07:00,760
and you can't, I don't want to hear from you anyway.

1175
01:07:01,239 --> 01:07:04,000
I'm kidding. I am totally kidding. But thank you for listening.

1176
01:07:04,360 --> 01:07:06,320
Hey all, thank you for joining us on the show.

1177
01:07:06,360 --> 01:07:08,840
This has been a cool conversation. Appreciate having me on

1178
01:07:08,880 --> 01:07:10,960
the show. Thank you so much for having me.

1179
01:07:10,960 --> 01:07:12,960
Speaker 4: It was awesome cool.

1180
01:07:12,880 --> 01:07:15,920
Speaker 1: Larren, as always, thank you for being here. Appreciate your

1181
01:07:16,159 --> 01:07:19,239
added input and helping me out on the show. Yeah,

1182
01:07:19,280 --> 01:07:22,199
of course, all right, and we will see y'all next week.