1
00:00:01,080 --> 00:00:03,000
Speaker 1: How'd you like to listen to dot net rocks with

2
00:00:03,040 --> 00:00:07,879
no ads? Easy? Become a patron for just five dollars

3
00:00:07,919 --> 00:00:10,800
a month. You get access to a private RSS feed

4
00:00:10,839 --> 00:00:14,279
where all the shows have no ads. Twenty dollars a month,

5
00:00:14,279 --> 00:00:17,679
we'll get you that and a special dot NetRocks patron mug.

6
00:00:18,160 --> 00:00:33,600
Sign up now at Patreon dot dot NetRocks dot com.

7
00:00:34,079 --> 00:00:37,240
Welcome back to dot net rocks. We're from Build.

8
00:00:37,520 --> 00:00:40,399
Speaker 2: Yeah, Richard, I like being a build Well, Seattle, it's raining.

9
00:00:40,479 --> 00:00:42,039
Welcome to my neck of the woods.

10
00:00:42,119 --> 00:00:45,560
Speaker 1: Right, I'm Carl Franklin. That's Richard Campbell, and it's gonna

11
00:00:45,600 --> 00:00:47,840
be a good show. This is the first show that

12
00:00:47,880 --> 00:00:51,159
we published from the list of shows that we're doing.

13
00:00:51,039 --> 00:00:52,600
Speaker 2: It well, got us to be busy.

14
00:00:52,920 --> 00:00:56,399
Speaker 1: Yes, however, this is the second show we recorded. Okay,

15
00:00:56,520 --> 00:01:01,240
so the keynote uh Hawk that we do with Scott

16
00:01:01,320 --> 00:01:03,560
Hunters next week. Yeah, yeah, all right, it's a couple

17
00:01:03,600 --> 00:01:05,719
hours ago, a couple hours ago, a lot of good stuff.

18
00:01:06,680 --> 00:01:08,599
Ken Exner is here. We're gonna be talking to him

19
00:01:08,599 --> 00:01:11,120
in just a minute. But first let's roll the music

20
00:01:11,200 --> 00:01:12,359
for better know a framework.

21
00:01:20,400 --> 00:01:20,959
Speaker 2: Man, what do you got?

22
00:01:21,159 --> 00:01:23,640
Speaker 1: Well? I haven't seen this one before. But it's trending

23
00:01:23,640 --> 00:01:30,159
on githubs. This is public dash APIs GitHub. It's the

24
00:01:30,200 --> 00:01:34,560
public API repository, manually curated by community members like you

25
00:01:34,719 --> 00:01:38,239
and folks working at API Layer. It's an extensive list

26
00:01:38,280 --> 00:01:40,879
of public APIs for many domains you can use for

27
00:01:40,920 --> 00:01:44,319
your own products. Consider it a treasure trove of api

28
00:01:44,439 --> 00:01:47,480
is well managed by the community over the years. That's cool,

29
00:01:47,519 --> 00:01:51,200
you know, so putting on my career criminal advice hat.

30
00:01:51,239 --> 00:01:53,879
If you want to do a denial of service attack

31
00:01:53,920 --> 00:01:56,159
to test out your new tools, pick one of these

32
00:01:56,200 --> 00:01:57,359
APIs and let it rip.

33
00:01:57,799 --> 00:02:01,760
Speaker 2: Jeezus, that's dark. It's a very dark way to think

34
00:02:01,760 --> 00:02:02,200
about it.

35
00:02:02,239 --> 00:02:04,599
Speaker 1: But yeah, I know, of course, you know you want

36
00:02:04,640 --> 00:02:08,000
to test out your your new harness for calling APIs

37
00:02:08,000 --> 00:02:10,199
and see if they were There's some really good stuff here.

38
00:02:10,879 --> 00:02:14,199
Locate and identify website visitors by IP address. That's a

39
00:02:14,199 --> 00:02:17,879
fun one market stack, free, easy to use rest API

40
00:02:17,919 --> 00:02:21,080
interface delivering worldwide stock market data and Jason format because

41
00:02:21,120 --> 00:02:25,199
you know CNN doesn't work well enough. Weather Stack retrieve

42
00:02:25,240 --> 00:02:29,639
incedant accurate weather information, numb verify, global phone number validation,

43
00:02:29,800 --> 00:02:33,719
look up Jason API and Fixer. A simple and lightweight

44
00:02:33,759 --> 00:02:39,039
API for current and historical foreign exchange rates, some good stuff,

45
00:02:39,240 --> 00:02:42,039
and there's more to it, of course, but that's it awesome.

46
00:02:42,120 --> 00:02:44,719
That's what I got. Who's talking to us today, Richard grab.

47
00:02:44,719 --> 00:02:46,960
Speaker 2: Your comment of the show ten sixteen seven, which is

48
00:02:47,000 --> 00:02:48,919
a while ago. Let's tart twenty fourteen. We were talking

49
00:02:48,919 --> 00:02:53,240
about to edemar a bit about different search strategies and technologies,

50
00:02:53,280 --> 00:02:54,840
and one of the comments in the show came from

51
00:02:54,840 --> 00:02:58,280
Sean mccartall, who was talking about how he pitched a

52
00:02:58,360 --> 00:03:01,719
last search to his organization. And admittedly he's twenty fourteen,

53
00:03:01,800 --> 00:03:05,840
so think about the challenges back then, right, But he said,

54
00:03:06,680 --> 00:03:08,159
only after the second time I had to tell my

55
00:03:08,199 --> 00:03:09,680
boss I don't know why it broke. We don't have

56
00:03:09,800 --> 00:03:12,840
enough information I sought out to solve the problem. Yeah,

57
00:03:12,919 --> 00:03:15,759
so this is this is an EMEN type thinking, he said,

58
00:03:16,080 --> 00:03:18,919
And the problem this is an architecture that spans SharePoint, SAP,

59
00:03:19,280 --> 00:03:22,240
some Tomcat hosted solutions, so a little jab in there,

60
00:03:22,560 --> 00:03:24,520
along with a bunch of good dot net projects in too,

61
00:03:24,599 --> 00:03:28,680
and he worked with Python and power Show forty threw

62
00:03:28,719 --> 00:03:32,000
a Lodge staff receiver into a LASTI search cluster, which

63
00:03:32,080 --> 00:03:35,400
was the easiest part to set up. And then after

64
00:03:35,439 --> 00:03:38,319
by another week doing some tweaks and configurations, he was

65
00:03:38,360 --> 00:03:42,479
able to do an analysis of workflows through all of

66
00:03:42,479 --> 00:03:46,240
those different products in twenty fourteen. That's twenty fourteen. I

67
00:03:46,240 --> 00:03:48,280
mean today the tools are all different. You'd be in

68
00:03:48,280 --> 00:03:50,240
the cloud and doing that, but no, he was cracking

69
00:03:50,240 --> 00:03:52,479
it the hard way now. So now I appreciate that

70
00:03:52,560 --> 00:03:55,280
it's just a realization, like a last search bit in

71
00:03:55,319 --> 00:03:58,919
our lives a long time. Things are obviously different now.

72
00:03:59,280 --> 00:04:01,000
And as Sean, thank you so much for your comment,

73
00:04:01,039 --> 00:04:02,520
and a copy of music Coby is on its way

74
00:04:02,560 --> 00:04:04,000
to you. And if you'd like a copy of music Koba,

75
00:04:04,039 --> 00:04:05,599
I write a comment on the website at dot net

76
00:04:05,680 --> 00:04:07,879
rocks dot com or on the facebooks we've published every

77
00:04:07,919 --> 00:04:09,240
show there, and if you comment there and never real

78
00:04:09,240 --> 00:04:10,960
on the show, we'll send you copy of music Goby.

79
00:04:11,080 --> 00:04:14,240
Speaker 1: Music to Code by of course, the music that helps

80
00:04:14,240 --> 00:04:17,759
you focus, still going strong, twenty two tracks. You can

81
00:04:17,800 --> 00:04:20,959
get it at music toocodebuy dot net. You can get

82
00:04:20,959 --> 00:04:24,600
the collection in MP three wave or a flack format.

83
00:04:25,839 --> 00:04:28,879
Before we interview our guests and introduce him, let's talk

84
00:04:28,920 --> 00:04:32,519
about nineteen fifty two yep so significant events, because this

85
00:04:32,600 --> 00:04:35,439
is show nineteen fifty two kind of have been been

86
00:04:35,439 --> 00:04:39,319
doing this. What happened in that year significant events including

87
00:04:39,360 --> 00:04:42,560
the death of King George the sixth and the ascension

88
00:04:42,600 --> 00:04:47,199
of his daughter Elizabeth to the throne of the United Kingdom.

89
00:04:47,279 --> 00:04:50,959
The US successfully tested the first hydrogen bomb. Dwight D.

90
00:04:51,160 --> 00:04:55,319
Eisenhower was elected President of the United States, defeating Adale Stevenson.

91
00:04:55,759 --> 00:04:58,879
The Korean War continue with the US launching bombing attacks

92
00:04:58,920 --> 00:05:02,360
in Greece and Turkey joint NATO. Other key events include

93
00:05:02,360 --> 00:05:05,399
the beginning of the Mau Mau rebellion in Kenya and

94
00:05:05,480 --> 00:05:08,920
the Great Smog of London caused by industrial pollution and

95
00:05:09,000 --> 00:05:12,720
high pressure weather. The Great Smog not to be confused

96
00:05:12,759 --> 00:05:15,800
with the Great Stink. Do you remember that? I mean

97
00:05:15,839 --> 00:05:17,720
I don't remember it, but I remember hearing about it.

98
00:05:18,759 --> 00:05:21,040
Sewage backed up in the Thames. It was horrible.

99
00:05:21,160 --> 00:05:24,680
Speaker 2: Related to the presidential election nineteen fifty two, was one

100
00:05:24,680 --> 00:05:27,240
of the UNIVAC computers, which again these were all bespoke

101
00:05:27,319 --> 00:05:31,720
machines of the time, right, actually did the computational estimations

102
00:05:31,759 --> 00:05:33,600
to say that Eisenhower's going to win. So it's one

103
00:05:33,639 --> 00:05:36,720
of the first times the computer predicted the win based

104
00:05:36,720 --> 00:05:37,120
on poll.

105
00:05:37,439 --> 00:05:39,800
Speaker 1: Okay, so you know how many times did the computer

106
00:05:39,920 --> 00:05:40,879
not predict the win though?

107
00:05:40,920 --> 00:05:41,920
Speaker 2: Well before that?

108
00:05:42,680 --> 00:05:47,680
Speaker 1: Zero? Oh yeah, okay, yeah, right, okay, shall we get

109
00:05:47,680 --> 00:05:50,920
on with our show. Let's talk to Ken Xner. I'll

110
00:05:50,920 --> 00:05:55,319
introduce him here. Ken is chief product Officer, head of

111
00:05:55,319 --> 00:05:58,839
products and engineering for Elastic. Maybe you've heard of it.

112
00:05:58,879 --> 00:06:01,000
Speaker 3: Welcome Ken, Hey Carl, good to be here.

113
00:06:01,000 --> 00:06:03,959
Speaker 2: Hey Richard, thanks, good to have you. Yeah, thank you.

114
00:06:03,959 --> 00:06:07,319
Speaker 3: You mentioned uh Elastic search US in twenty fourteen. We

115
00:06:07,360 --> 00:06:09,759
actually just celebrated our fifteenth anniversary of.

116
00:06:09,680 --> 00:06:11,560
Speaker 2: The lasted search, so twenty ten.

117
00:06:11,680 --> 00:06:14,439
Speaker 3: Yeah, Elastic Search fifteen years as a couple of months ago.

118
00:06:14,720 --> 00:06:15,519
Speaker 1: That's fantastic.

119
00:06:16,600 --> 00:06:20,319
Speaker 3: H And it's a it's gone on to be downloaded

120
00:06:20,439 --> 00:06:22,759
four point six billion times.

121
00:06:22,639 --> 00:06:26,680
Speaker 1: Wait billion with a B, billion with a B, which.

122
00:06:26,480 --> 00:06:28,160
Speaker 3: Makes it I think one of the most popular open

123
00:06:28,160 --> 00:06:29,319
source projects of all time.

124
00:06:29,399 --> 00:06:32,000
Speaker 2: Yeah, no, without doubt, And I mean it comes up regularly.

125
00:06:32,040 --> 00:06:34,079
It's just one of the tools we've count on for

126
00:06:34,720 --> 00:06:38,240
fast search solving certain certain scopes of problems. Right, see

127
00:06:38,319 --> 00:06:41,600
the smart casing tool. Now, you guys have got a

128
00:06:41,680 --> 00:06:45,959
new relationship in Azure. You're just you're becoming a service

129
00:06:46,000 --> 00:06:47,160
like well, how you guy, what do you guys are

130
00:06:47,240 --> 00:06:47,439
up to?

131
00:06:47,560 --> 00:06:48,879
Speaker 1: But we've we've.

132
00:06:48,680 --> 00:06:51,279
Speaker 3: Been Our partnership with Azure has been fantastic. So over

133
00:06:51,319 --> 00:06:55,759
the last few years, Azure has been integrating US almost

134
00:06:55,759 --> 00:06:58,439
like a first party service within Azure, so you can

135
00:06:58,480 --> 00:07:02,120
go into the navigation and select US as part of

136
00:07:02,639 --> 00:07:05,000
the experience with an Azure So if you wanted to

137
00:07:05,079 --> 00:07:07,600
launch your own Elastic Search, you can do it very

138
00:07:07,600 --> 00:07:12,000
simply from within the Azure console. So yeah, it's been fantastic.

139
00:07:12,079 --> 00:07:13,759
Speaker 2: Yeah, and you guys been in cloud for ages.

140
00:07:14,959 --> 00:07:17,639
Speaker 3: We started going back to the cloud, started going to

141
00:07:17,680 --> 00:07:21,199
cloud about six seven years ago, where we first started

142
00:07:21,600 --> 00:07:26,639
letting customers spin up a VM, have US automatically installed,

143
00:07:27,120 --> 00:07:32,360
have US patching and maintaining their cluster. We've recently actually

144
00:07:32,399 --> 00:07:35,199
introduced a new serverless offering that is kind of a

145
00:07:35,240 --> 00:07:38,519
fully managed experience that you can think of it as

146
00:07:38,560 --> 00:07:41,720
SaaS like. So it is a SaaS like experience for

147
00:07:41,839 --> 00:07:45,720
using Elastic Search, which means that customers can use US

148
00:07:45,759 --> 00:07:48,399
an open source, they can get a self managed license,

149
00:07:48,439 --> 00:07:51,000
they can have a hosted version in cloud, and they

150
00:07:51,040 --> 00:07:53,759
can have this new serverless offering which is kind of

151
00:07:54,000 --> 00:07:55,120
a SaaS like experience.

152
00:07:55,120 --> 00:07:57,199
Speaker 2: So am I just paying by transaction at that point?

153
00:07:57,279 --> 00:08:00,120
Speaker 3: Yeah, you're just paying for data. So if you're if

154
00:08:00,120 --> 00:08:02,000
you're using US as like a logging solution, you're just

155
00:08:02,000 --> 00:08:03,639
paying for data in and data retained.

156
00:08:03,680 --> 00:08:04,000
Speaker 1: That's it.

157
00:08:04,240 --> 00:08:04,600
Speaker 2: That's fair.

158
00:08:04,839 --> 00:08:07,079
Speaker 3: And it scales to zero and it's uh yeah, it's

159
00:08:07,079 --> 00:08:07,480
a magical.

160
00:08:07,480 --> 00:08:09,079
Speaker 2: It doesn't cost you anything. You don't move any data

161
00:08:09,079 --> 00:08:11,680
around it exactly nice. You're if you're running a VM,

162
00:08:11,720 --> 00:08:13,519
you're paying for it. That's right, no way around that.

163
00:08:13,680 --> 00:08:16,600
Speaker 3: But yeah, it's it's been a challenge being able to

164
00:08:16,639 --> 00:08:19,720
deliver elastic search all these different ways that you know,

165
00:08:19,839 --> 00:08:22,160
it's hard to maintain software that many different ways, but

166
00:08:22,639 --> 00:08:23,639
it's what customers need.

167
00:08:23,759 --> 00:08:26,920
Speaker 1: So how does it fit into Azure's new AI focus

168
00:08:27,720 --> 00:08:33,960
that you probably, yeah, are the focus this I did.

169
00:08:34,159 --> 00:08:37,000
Speaker 2: The drinking game I decided on was not to say

170
00:08:37,039 --> 00:08:38,759
we need to take a drink, we say copa certainly

171
00:08:38,799 --> 00:08:41,679
not say drinks, we say AI, you'll be drunk when

172
00:08:41,679 --> 00:08:42,480
you say Windows.

173
00:08:42,679 --> 00:08:42,919
Speaker 1: Yeah.

174
00:08:43,360 --> 00:08:44,919
Speaker 2: I think I only had to take three drinks then.

175
00:08:46,480 --> 00:08:49,679
Speaker 3: Yeah. Well, I think it's really a question of how

176
00:08:49,919 --> 00:08:52,360
is search, you know, playing a role in the I

177
00:08:52,799 --> 00:08:54,799
right boom, And I think one of the things that

178
00:08:55,000 --> 00:08:57,559
you know, when generative the I first happened, everyone's kind

179
00:08:57,559 --> 00:09:01,120
of wondering what's the future of search, and people were saying, oh,

180
00:09:01,159 --> 00:09:03,440
you know, Google is dead, and I think one of.

181
00:09:03,360 --> 00:09:06,159
Speaker 1: The things that you even said, SAS is dead.

182
00:09:06,159 --> 00:09:07,120
Speaker 3: He said that last year.

183
00:09:07,159 --> 00:09:07,360
Speaker 2: Yeah.

184
00:09:07,919 --> 00:09:11,039
Speaker 4: Yeah, yeah, I'm saying for him to say, I think

185
00:09:11,279 --> 00:09:14,159
it seems unlikely, maybe a little premature, maybe a little

186
00:09:15,240 --> 00:09:18,559
we'll get into agentic architectures in the augentic future soon,

187
00:09:18,600 --> 00:09:19,000
but yeah, I.

188
00:09:18,960 --> 00:09:23,440
Speaker 3: Think SaaS is still here. But yeah, what we realized

189
00:09:23,519 --> 00:09:25,679
is that search had a huge role to play in

190
00:09:25,759 --> 00:09:29,039
AI because if you're building generative AI applications, you need

191
00:09:29,080 --> 00:09:31,159
to ground it on, you know, your own data so

192
00:09:31,200 --> 00:09:33,759
that you're not just basing on public information.

193
00:09:33,480 --> 00:09:34,320
Speaker 2: And constantly changing.

194
00:09:34,559 --> 00:09:37,639
Speaker 3: It's constantly changing. And if you, you know, want to

195
00:09:37,679 --> 00:09:40,519
make sure that you know the permissions reflect the user,

196
00:09:40,879 --> 00:09:43,159
you need to make sure that you know that whatever

197
00:09:43,200 --> 00:09:45,840
you're grounding on understands the user's permission to data.

198
00:09:46,000 --> 00:09:48,440
Speaker 2: You're not going to build a model for every permission level.

199
00:09:48,480 --> 00:09:50,080
That doesn't seem practical.

200
00:09:49,720 --> 00:09:51,840
Speaker 3: You know, fine tune or build a model for every

201
00:09:51,879 --> 00:09:54,440
single possible combination combination of permissions.

202
00:09:54,519 --> 00:09:56,759
Speaker 2: Yeah, yeah, it seems like a way, good way to

203
00:09:56,759 --> 00:09:57,759
waste a lot of space.

204
00:09:58,679 --> 00:10:01,320
Speaker 1: What else shouldn't you do let's talk about that.

205
00:10:01,440 --> 00:10:03,639
Speaker 3: Well maybe in video would like that feature, but.

206
00:10:04,080 --> 00:10:06,080
Speaker 2: Don't stick a fork at a toaster. That's a good one,

207
00:10:06,120 --> 00:10:06,360
I think.

208
00:10:07,000 --> 00:10:08,039
Speaker 1: Okay, then we have two.

209
00:10:08,879 --> 00:10:12,639
Speaker 3: Yeah, so search has this new found life in the

210
00:10:12,639 --> 00:10:14,799
age of generative AI. Wheople are using us to help

211
00:10:14,799 --> 00:10:18,519
build applications and doing retrieval mechanisms, and that's been sort

212
00:10:18,519 --> 00:10:20,519
of the source of our partnership with Azure, as well

213
00:10:20,559 --> 00:10:24,320
as helping them be a search engine or retrieval engine

214
00:10:24,320 --> 00:10:28,679
that helps their customers, our customers build these generative applications

215
00:10:28,720 --> 00:10:29,759
on top of their private data.

216
00:10:29,960 --> 00:10:32,399
Speaker 1: Right, Yeah, that's great. Well, I mean we saw the

217
00:10:32,960 --> 00:10:35,440
we just saw the keynote a couple hours ago, and

218
00:10:35,559 --> 00:10:38,080
we'll get into more of that next week with Scott.

219
00:10:38,080 --> 00:10:41,320
But what did you take away from it?

220
00:10:41,639 --> 00:10:44,960
Speaker 3: Well, one of the things in Scott's keynote he mentioned

221
00:10:45,200 --> 00:10:47,639
sort of the move towards conversational search, and this is

222
00:10:47,679 --> 00:10:52,200
one that we think is big within Elastic and we've

223
00:10:52,200 --> 00:10:54,799
seen the evolution of search. You know, started off as

224
00:10:54,840 --> 00:10:57,720
lexical search or text basse search, and then six seven

225
00:10:57,799 --> 00:11:00,960
years ago and moved to semantic search, where people started

226
00:11:01,000 --> 00:11:06,320
to expect their search box to understand natural language and

227
00:11:06,360 --> 00:11:09,159
respond to questions. And then I think with generative AI

228
00:11:09,440 --> 00:11:12,159
it became sort of an evolution further towards RAG where

229
00:11:12,279 --> 00:11:14,840
people wanted to build these applications. I think now it's

230
00:11:14,879 --> 00:11:18,799
moving towards conversational search, where you're expecting your search box

231
00:11:18,879 --> 00:11:22,799
to have a conversation with you and respond in natural

232
00:11:22,879 --> 00:11:25,960
language and carry the context and carry context, have memory

233
00:11:26,840 --> 00:11:29,360
be personalized. And I think one of the things that

234
00:11:29,360 --> 00:11:32,320
we've been working with Microsoft on is how do you

235
00:11:32,360 --> 00:11:37,440
build these conversational search experiences across the web. I'm excited

236
00:11:37,440 --> 00:11:37,879
about that.

237
00:11:38,000 --> 00:11:42,080
Speaker 2: Yeah, yeah, and again it's just it's part of the infrastructure.

238
00:11:42,120 --> 00:11:44,360
You just want you just expect that to work and

239
00:11:44,679 --> 00:11:46,279
to be fast, to be fast.

240
00:11:46,360 --> 00:11:49,200
Speaker 3: Yeah, you know, that's one of the things that elastic

241
00:11:49,240 --> 00:11:51,919
search is known for is blazing speed. I'm always you

242
00:11:51,960 --> 00:11:54,960
can you start typing keywords in a search box and

243
00:11:55,039 --> 00:11:58,240
auto completes. You expect that. So now combine that with

244
00:11:58,600 --> 00:12:00,840
like conversational search, you can.

245
00:12:00,799 --> 00:12:02,960
Speaker 2: Get over the speed of l about the typing in

246
00:12:03,000 --> 00:12:05,200
the box, yeah, yeah, if I have to finish typing

247
00:12:05,240 --> 00:12:07,759
and hit a box, so annoying. That's a broken search tool.

248
00:12:07,840 --> 00:12:11,519
Speaker 1: Yeah, so many of our listeners may not know about

249
00:12:11,879 --> 00:12:14,639
vector databases in general. Can you kind of give us

250
00:12:14,679 --> 00:12:18,960
an idea of how that changes the game sure data

251
00:12:19,120 --> 00:12:19,960
standard relationship.

252
00:12:20,000 --> 00:12:24,279
Speaker 3: Yah. So when we became a semantic search engine, we

253
00:12:24,279 --> 00:12:27,120
had to become a vector database as well. And this

254
00:12:27,159 --> 00:12:30,559
is back around twenty seventeen we started supporting the ability

255
00:12:30,559 --> 00:12:32,000
to store and query dence spectors.

256
00:12:32,279 --> 00:12:35,480
Speaker 2: It was cool before it was cool, five years before.

257
00:12:35,279 --> 00:12:36,200
Speaker 3: Before it was cool.

258
00:12:37,000 --> 00:12:40,720
Speaker 1: I don't know anything about that. It's like first podcast ever.

259
00:12:41,559 --> 00:12:43,759
Speaker 3: I'm there's some debate about it, but I'm gonna still

260
00:12:43,799 --> 00:12:45,600
argue that we were one of, if not the first

261
00:12:45,720 --> 00:12:47,879
vector database out there because we had to support it

262
00:12:47,919 --> 00:12:50,840
for product search like image search, and for semantic search.

263
00:12:50,960 --> 00:12:53,039
Speaker 1: So I kind of know what vectors are because I

264
00:12:53,039 --> 00:12:55,000
took high school physics. But tell us the.

265
00:12:55,120 --> 00:12:59,080
Speaker 3: Basic idea is, you're trying to plot vettings or vectors

266
00:12:59,080 --> 00:13:01,840
in sort of a multiensal space, and you're trying to

267
00:13:02,039 --> 00:13:06,879
look for similarities between vectors in this multidimensional space. So

268
00:13:07,159 --> 00:13:11,080
you're you're basically taking text or you're taking images, and

269
00:13:11,120 --> 00:13:14,080
you're you're vectorizing it, which is turning it into these, uh,

270
00:13:14,320 --> 00:13:18,120
these embeddings, these numbers that can be plotted in vector space,

271
00:13:18,279 --> 00:13:22,279
and then that allows you to find similar terms. So

272
00:13:22,440 --> 00:13:25,440
when you're doing something like semantic search, you're trying to

273
00:13:25,519 --> 00:13:29,360
use uh vector sort of this vector search to look

274
00:13:29,399 --> 00:13:34,399
for similar terms. So if I if I say glass

275
00:13:34,519 --> 00:13:37,080
and cup, I understand that those are similar terms, right,

276
00:13:37,639 --> 00:13:40,360
because they're they're close in this vectorized space.

277
00:13:40,919 --> 00:13:41,080
Speaker 1: Uh.

278
00:13:41,120 --> 00:13:43,200
Speaker 3: Same thing with images, same thing with video. Anything that

279
00:13:43,240 --> 00:13:47,000
can be vectorized and turned and turned into vector embeddings. Uh.

280
00:13:47,039 --> 00:13:49,879
So we started supporting the ability to store these dense

281
00:13:49,960 --> 00:13:53,200
vectors and query dence vectors and elastic search, and then

282
00:13:53,240 --> 00:13:56,039
five years later generative AI happened and we were like, wow,

283
00:13:56,279 --> 00:13:57,960
we have a vector database. That's pretty cool.

284
00:13:58,000 --> 00:13:58,159
Speaker 1: Yeah.

285
00:13:58,240 --> 00:14:00,799
Speaker 2: Right, and that kind of thing that language tookeganization just

286
00:14:00,960 --> 00:14:02,840
lends itself so well to vectorization.

287
00:14:02,960 --> 00:14:05,600
Speaker 1: That's right. Well, that's what makes possible, right like chat GPT,

288
00:14:05,759 --> 00:14:09,360
you type in a phrase or a question, the response,

289
00:14:09,679 --> 00:14:12,120
every single word is based on the probability of what

290
00:14:12,320 --> 00:14:14,120
is the next word based on the vector values.

291
00:14:14,240 --> 00:14:16,720
Speaker 3: That's right. Right, And well, so there's there's a couple

292
00:14:16,720 --> 00:14:18,600
of ways that vectors are used. One is inside the

293
00:14:18,600 --> 00:14:22,519
models themselves, but a vector database specifically is used for

294
00:14:22,879 --> 00:14:26,000
helping ground an l l M. So like an LM

295
00:14:26,039 --> 00:14:29,240
doesn't actually use a vector database, but it uses vectors

296
00:14:29,039 --> 00:14:34,080
in how it's how it stores the information models. But

297
00:14:34,600 --> 00:14:36,799
for a vector database, it's it's trying to get the

298
00:14:36,919 --> 00:14:41,879
l M to ground itself on third party data so

299
00:14:41,919 --> 00:14:43,840
that you know, if it's not been trained on a

300
00:14:43,840 --> 00:14:46,720
product catalog, for example, you can expose it to a

301
00:14:46,759 --> 00:14:49,600
product catalog, or if you needed to use some information

302
00:14:49,639 --> 00:14:51,559
that it has not been specifically trained on, you can

303
00:14:51,600 --> 00:14:55,080
ground it on that. And a vector database is one

304
00:14:55,120 --> 00:15:00,960
technique for helping produce highly similar, highly effective search results

305
00:15:01,000 --> 00:15:04,600
that help ground that LLLM. We actually found that the

306
00:15:04,600 --> 00:15:07,679
best techniques are actually not just using vector databases. You know,

307
00:15:07,679 --> 00:15:09,519
I'm a we're a vector database, and I'm gonna say

308
00:15:09,679 --> 00:15:12,039
the best techniques are not just using the best techniques

309
00:15:12,039 --> 00:15:16,120
are actually using combinations of technologies. Hybrid search. We're using

310
00:15:16,159 --> 00:15:20,720
combinations of lexical search UH and uh en vector search,

311
00:15:20,799 --> 00:15:24,240
or you're using sort of graph traversal together with vector

312
00:15:24,240 --> 00:15:26,840
search where you're you're modeling information and we're seeing the

313
00:15:26,919 --> 00:15:30,639
relationship between entities. But we support all these things. We

314
00:15:30,679 --> 00:15:34,600
support a combination of geospatial search together with vector search.

315
00:15:35,679 --> 00:15:39,840
So yeah, there's also other techniques like reranking. So once

316
00:15:39,879 --> 00:15:41,080
you all the reason.

317
00:15:41,039 --> 00:15:43,840
Speaker 2: You're talk about runing multiple searches and in those different

318
00:15:43,960 --> 00:15:47,399
forms and then somehow munging it together, so you're not

319
00:15:47,440 --> 00:15:50,039
repeating yourself to get a results at that's.

320
00:15:49,879 --> 00:15:52,360
Speaker 3: Right, or you're you're running post process like you might

321
00:15:52,440 --> 00:15:55,000
pull a bunch of results and then run reranking after

322
00:15:55,000 --> 00:15:57,679
the fact, right, and that get further refines the results.

323
00:15:57,679 --> 00:15:59,679
And then what you're doing is you're passing the right

324
00:15:59,720 --> 00:16:02,919
inform to an LM so that it can say, okay,

325
00:16:02,960 --> 00:16:05,200
you're using it. You're passing into the context window and

326
00:16:05,240 --> 00:16:08,320
saying this is the information you should build your response on.

327
00:16:08,639 --> 00:16:11,759
And all this happens blazing really really fast, and then

328
00:16:11,799 --> 00:16:15,200
the LM now has some information in its context window

329
00:16:15,240 --> 00:16:18,559
that it can use to to provide an accurate result.

330
00:16:18,879 --> 00:16:21,519
Speaker 1: So here's a scenario. Let's say I'm building an agent,

331
00:16:21,759 --> 00:16:26,039
and the agent I'm giving access to my database. On

332
00:16:26,039 --> 00:16:28,519
one side, I've got a SEQL server with a bunch

333
00:16:28,519 --> 00:16:31,000
of relational data in it. On the other side, I

334
00:16:31,000 --> 00:16:34,200
have a las to search vector database, and I give

335
00:16:34,399 --> 00:16:37,759
it access to both of those things. Is it going

336
00:16:37,799 --> 00:16:41,159
to be able to find things in the last to

337
00:16:41,399 --> 00:16:45,000
elast to search faster than it would in my relational

338
00:16:45,279 --> 00:16:47,600
data if they were both, if it was both trained

339
00:16:47,639 --> 00:16:48,799
on both data.

340
00:16:49,000 --> 00:16:52,200
Speaker 3: We would be It depends if so I'm assuming this

341
00:16:52,279 --> 00:16:54,840
scenario that we have a connector to that database and

342
00:16:54,879 --> 00:16:56,200
we can run into it will be faster.

343
00:16:57,000 --> 00:17:01,559
Speaker 1: Okay, so yeah, so why would I want to use

344
00:17:01,600 --> 00:17:05,079
the relational database? And my this is this is actually

345
00:17:05,119 --> 00:17:07,000
why one of the first that's why you're here, I

346
00:17:07,079 --> 00:17:09,680
get it. I see, actually one of the first.

347
00:17:10,519 --> 00:17:13,480
Speaker 2: It's the end of databasetase we know it.

348
00:17:13,880 --> 00:17:16,160
Speaker 3: One of the first use cases for elastic search was

349
00:17:16,160 --> 00:17:20,440
actually database offloading because it was the search function was

350
00:17:20,559 --> 00:17:23,680
creating contention in the database, so offloaded it to elastic

351
00:17:23,720 --> 00:17:25,839
search and we were blazing fast. Helped speed up the

352
00:17:25,880 --> 00:17:26,799
database at the same time.

353
00:17:26,839 --> 00:17:28,960
Speaker 1: You know, most people what they do is they have

354
00:17:29,119 --> 00:17:32,240
one database for their product data or whatever, and then

355
00:17:32,240 --> 00:17:35,039
they have another one that's optimized for searching. That's right, right,

356
00:17:35,480 --> 00:17:39,519
So the one optimized for searching doesn't have all the

357
00:17:39,519 --> 00:17:42,880
the joins and everything that's crazy about data.

358
00:17:43,240 --> 00:17:45,400
Speaker 2: Relational database cercually and we're not I don't want to

359
00:17:45,400 --> 00:17:47,279
be mean to relational databases, but they were from a

360
00:17:47,319 --> 00:17:49,359
time when DISPAS was at a premium, and so don't

361
00:17:49,440 --> 00:17:52,640
striplicate data, right, Like, that's why we organize data that way.

362
00:17:52,680 --> 00:17:56,279
It was space efficient. It's not particularly important now. Admittedly,

363
00:17:56,640 --> 00:17:58,920
now we have an infrastructure around it where we have

364
00:17:59,000 --> 00:18:01,200
so many querying tools and other bits and pieces that

365
00:18:01,279 --> 00:18:03,599
just work against it. That that's your instinct, and all

366
00:18:03,640 --> 00:18:06,039
our rms tend to point to. Okay, some ways are

367
00:18:06,039 --> 00:18:08,799
just in place from the momentum of what's been built

368
00:18:08,799 --> 00:18:11,599
on the facto standard, and they're highly integrated, like they

369
00:18:11,599 --> 00:18:13,960
have their advantages, but there are more ways to store

370
00:18:14,039 --> 00:18:16,440
data and we do. The trick is, you know, deciding

371
00:18:16,440 --> 00:18:19,200
on a source of truth and trying to keep everything,

372
00:18:19,240 --> 00:18:20,240
every copy in sync.

373
00:18:20,480 --> 00:18:23,640
Speaker 1: So a last search on Azure is kind of like

374
00:18:24,279 --> 00:18:27,680
the place to be. I think now that we've been

375
00:18:27,680 --> 00:18:30,599
talking about this, if you're going to be building you know,

376
00:18:30,720 --> 00:18:36,039
copilot and agents in Azure Foundry, I guess.

377
00:18:36,839 --> 00:18:40,759
Speaker 3: And we've actually integrated with AI Foundry. We're one of

378
00:18:40,880 --> 00:18:44,359
three launch partners. So if you're using AI Foundry, you

379
00:18:44,400 --> 00:18:47,519
can use us as a grounding engine as a way

380
00:18:47,559 --> 00:18:52,319
to build generative AI applications using our vector database. We've

381
00:18:52,319 --> 00:18:57,759
also been integrated with semantic kernel from the very beginning. Right,

382
00:18:58,559 --> 00:19:02,640
we first started supporting semantic kernel by offering vector search.

383
00:19:03,079 --> 00:19:06,079
Recently we actually extended that to do hybrid search. So

384
00:19:06,240 --> 00:19:08,000
what I was talking about before, being able to combine

385
00:19:08,039 --> 00:19:12,440
different search techniques, right, we're the first offering to do that.

386
00:19:12,599 --> 00:19:15,119
Speaker 1: Now, you know, we've been given SQL server a lot

387
00:19:15,160 --> 00:19:19,000
of crap here. But if somebody is listening and say, yeah,

388
00:19:19,039 --> 00:19:21,119
you know that rings, I think I'm going to try this.

389
00:19:21,359 --> 00:19:26,359
How easy is it to move our relational databases from

390
00:19:26,480 --> 00:19:29,480
let's say SQL azure to elastic search.

391
00:19:29,799 --> 00:19:32,480
Speaker 3: How easy it would it be to change the search

392
00:19:32,599 --> 00:19:35,680
to be using out using US as a search engine

393
00:19:35,880 --> 00:19:37,000
and plugging into.

394
00:19:37,279 --> 00:19:40,440
Speaker 1: Or data or just moving all the data, moving all

395
00:19:40,440 --> 00:19:42,799
the search. Is that something that you want to necessarily do?

396
00:19:44,319 --> 00:19:47,759
Speaker 3: Most people wouldn't use US as sort of a database

397
00:19:48,279 --> 00:19:51,000
alternative database. They would use US if they're using a

398
00:19:51,039 --> 00:19:57,000
relational database. They might use US as to offload search functions,

399
00:19:57,000 --> 00:19:59,319
so they would use it that way. But people do

400
00:19:59,440 --> 00:20:03,759
use US to store logs and other time series data

401
00:20:03,799 --> 00:20:07,160
as a primary data store. Sure you wouldn't store that.

402
00:20:07,160 --> 00:20:09,599
Speaker 1: In a relational database, so not real data.

403
00:20:09,599 --> 00:20:12,799
Speaker 3: It's not relational data. But people do, people do. I

404
00:20:12,799 --> 00:20:15,200
would not, I would not use this as an alternative

405
00:20:15,200 --> 00:20:17,640
to a relational data store. But I would absolutely use

406
00:20:17,720 --> 00:20:20,200
US as a time series database. I would absolutely use

407
00:20:20,279 --> 00:20:23,039
US as a vector datase. I would absolutely use US

408
00:20:23,079 --> 00:20:27,799
as a database offloading tool for SQL and other words speeding.

409
00:20:28,200 --> 00:20:31,480
Speaker 1: Yeah, that's right. Yeah, and so it has it has

410
00:20:31,519 --> 00:20:35,400
access to your SEQL server. It can figure out how

411
00:20:35,440 --> 00:20:37,880
to optimize those queries things that you would do in

412
00:20:37,920 --> 00:20:41,240
a store procedure where you're getting multiple data sets from

413
00:20:41,279 --> 00:20:44,160
multiple tables and things like that. That's the kind of

414
00:20:44,160 --> 00:20:45,440
stuff where you would be in a lasts.

415
00:20:45,480 --> 00:20:47,960
Speaker 3: Those are the kind of workloads that are perfect for us,

416
00:20:48,039 --> 00:20:50,599
Like we will help speed that up, take the take

417
00:20:50,599 --> 00:20:53,519
the workload off of SQL server so that they can

418
00:20:53,519 --> 00:20:55,480
handle the rest of its work without contention.

419
00:20:55,599 --> 00:20:58,720
Speaker 2: So I can also see the data, like I want

420
00:20:58,759 --> 00:21:01,680
to search the incoming data. I think you constantly current data,

421
00:21:01,680 --> 00:21:03,480
so I don't want to keep reprocessing models to include it.

422
00:21:03,480 --> 00:21:05,680
So I'm using these search mechanisms that data is coming

423
00:21:05,680 --> 00:21:08,240
into my relational database, then probably I have an asynchronous

424
00:21:08,319 --> 00:21:11,359
call from that calling out of it. And reorganizing it

425
00:21:11,400 --> 00:21:12,480
into the vector database.

426
00:21:13,680 --> 00:21:16,359
Speaker 3: Yeah, so there would be the connector would would basically

427
00:21:16,920 --> 00:21:19,960
be indexing a as is coming in, say, creating an

428
00:21:19,960 --> 00:21:22,759
index so that it can handle those queries and do

429
00:21:22,839 --> 00:21:26,039
that without bothering the primary database.

430
00:21:26,119 --> 00:21:28,359
Speaker 2: Right, yeah, yeah, so is that actually a hook I

431
00:21:28,400 --> 00:21:31,640
put into a lastic search into elastica just saying hey,

432
00:21:31,640 --> 00:21:34,599
watch this database when yous come in politic exactly now,

433
00:21:34,960 --> 00:21:36,839
I mean, because it's relation to database, I tend to

434
00:21:36,880 --> 00:21:40,359
decompose data, right, I've broken this order down into rows

435
00:21:40,400 --> 00:21:43,079
and columns and stuff. I don't imagine that's how you

436
00:21:43,079 --> 00:21:44,799
want to start in a vector database. You kind of

437
00:21:44,880 --> 00:21:45,119
in a.

438
00:21:45,160 --> 00:21:50,000
Speaker 3: Vectora less to search, everything is sort of document based.

439
00:21:50,359 --> 00:21:55,079
Everything's turned into a document. Uh but uh but yeah,

440
00:21:55,079 --> 00:21:58,000
we'd be able to map that back to the rows

441
00:21:58,039 --> 00:21:59,240
and tables in a in.

442
00:21:59,200 --> 00:22:02,720
Speaker 2: A in a Right. So I mean I started off

443
00:22:02,759 --> 00:22:04,759
with the whole order. Should I just stole the whole

444
00:22:04,880 --> 00:22:08,440
order in in elastic and then decompose it into rows

445
00:22:08,440 --> 00:22:10,400
and columns? Like, what's the right flow there?

446
00:22:10,759 --> 00:22:14,319
Speaker 1: Right? If you're do you have any actual to help me?

447
00:22:17,079 --> 00:22:19,960
Speaker 3: I'm not sure I think you you know, if you

448
00:22:20,119 --> 00:22:22,519
just use our connectors it'll handle this for you and

449
00:22:22,519 --> 00:22:25,559
you'll have to think about it. It doesn't like we

450
00:22:25,599 --> 00:22:29,839
have four hundred different connectors that have been built up

451
00:22:29,880 --> 00:22:32,000
over the years for all kinds of different data stores

452
00:22:32,079 --> 00:22:36,559
for everything from Snowflake to SQL server to you know

453
00:22:36,759 --> 00:22:39,559
other and it handles all of that for sure. And

454
00:22:39,599 --> 00:22:42,119
then these days everything is kind of getting replaced by

455
00:22:42,160 --> 00:22:45,680
mcps or we're starting to build mcps of board into

456
00:22:45,680 --> 00:22:46,240
that as well.

457
00:22:46,599 --> 00:22:49,160
Speaker 2: Yeah, the AI equation of this is flipping huge.

458
00:22:48,920 --> 00:22:51,480
Speaker 1: And we'll talk about that a little bit more when

459
00:22:51,480 --> 00:22:53,519
we come back, and also next week with Scott Hunter.

460
00:22:54,279 --> 00:22:55,920
We're going to take a break right now, though we'll

461
00:22:55,960 --> 00:22:58,880
be back after these very important messages. Don't go away.

462
00:23:01,240 --> 00:23:03,960
You know, dot net six has officially reached the end

463
00:23:04,000 --> 00:23:07,200
of support and now is the time to upgrade. Dot

464
00:23:07,279 --> 00:23:10,599
Net eight is well supported on a w S. Learn

465
00:23:10,640 --> 00:23:14,119
more at aws dot Amazon dot com, slash dot net.

466
00:23:18,000 --> 00:23:20,359
And we're back. It's dot net Rocks. I'm Carl Franklin

467
00:23:21,079 --> 00:23:25,599
Campbell and we're talking to Ken Exner from Elastic about

468
00:23:25,599 --> 00:23:29,599
elasti search and some really important information that we just

469
00:23:29,880 --> 00:23:33,319
discovered about you know, what it, what it is, where

470
00:23:33,359 --> 00:23:37,000
it fits in, and what it doesn't do. Uh, and

471
00:23:37,039 --> 00:23:40,759
how it fits in with with Azure, especially about how

472
00:23:40,799 --> 00:23:46,599
you can make searches stinky fast rights stinky fast?

473
00:23:46,680 --> 00:23:49,039
Speaker 3: Is that I'm not That's good.

474
00:23:49,119 --> 00:23:50,000
Speaker 1: No, that's really good.

475
00:23:50,480 --> 00:23:52,480
Speaker 2: So fast you can smell the burn and rubber.

476
00:23:53,039 --> 00:23:56,559
Speaker 3: That makes it better. I like that, all right?

477
00:23:56,920 --> 00:24:00,960
Speaker 1: So how do you get started with jam ai with

478
00:24:01,079 --> 00:24:04,920
elastic and Azure and the Elastic AI ecosystem through Azure

479
00:24:05,200 --> 00:24:06,559
Foundry AI Foundry.

480
00:24:06,599 --> 00:24:10,799
Speaker 3: Well, I guess if you're if you're uh using AI

481
00:24:10,920 --> 00:24:14,519
foundry or using semantic Kernel, we're there, Like if you're

482
00:24:14,599 --> 00:24:16,759
if you're choosing to use that, like if you're using

483
00:24:16,759 --> 00:24:19,759
semantic kernel as a way to build uh generative A

484
00:24:19,920 --> 00:24:23,319
applications into whatever you're doing. Uh, we are integrated there

485
00:24:23,359 --> 00:24:25,759
so you can use us as a vector of database

486
00:24:25,799 --> 00:24:26,240
within that.

487
00:24:27,240 --> 00:24:28,920
Speaker 2: It's just a feature. It's just a feature to.

488
00:24:28,839 --> 00:24:30,759
Speaker 3: Turn on, so you can go and like, can you

489
00:24:30,799 --> 00:24:32,799
pick which vector database you want? There's a drop down,

490
00:24:32,799 --> 00:24:34,599
there's a couple options there. We're one of those two.

491
00:24:34,799 --> 00:24:35,319
Speaker 1: It's great.

492
00:24:35,440 --> 00:24:37,519
Speaker 3: Uh. And then the same thing for AI Foundry. We're

493
00:24:37,599 --> 00:24:41,000
integrated into AI Foundry into your workflow so you don't

494
00:24:41,039 --> 00:24:44,440
have to think about it, so you can basically, uh,

495
00:24:44,640 --> 00:24:46,880
you know, start using AI foundry select us as a

496
00:24:46,920 --> 00:24:47,759
vector database.

497
00:24:48,279 --> 00:24:48,519
Speaker 1: Uh.

498
00:24:48,559 --> 00:24:51,720
Speaker 3: With our integration into Azure, it's automatically set up for you,

499
00:24:51,799 --> 00:24:54,319
so you don't have to think about any permissions anything.

500
00:24:54,359 --> 00:24:57,599
It's all integrated with the Azure as your client.

501
00:24:57,559 --> 00:25:00,000
Speaker 1: I hate to derail you, but this is the first

502
00:25:00,079 --> 00:25:03,119
time AI Foundry has been used on dot net rocks.

503
00:25:03,359 --> 00:25:06,240
I just learned about it today. Ah, so people probably

504
00:25:06,319 --> 00:25:07,599
won't know what this is.

505
00:25:07,880 --> 00:25:10,599
Speaker 3: It's you can think of it as the new studio

506
00:25:10,799 --> 00:25:12,000
for all things AI.

507
00:25:12,160 --> 00:25:12,759
Speaker 2: It's like the.

508
00:25:12,680 --> 00:25:15,599
Speaker 1: Azure AI portal section for AI.

509
00:25:15,799 --> 00:25:19,559
Speaker 3: Right, Yeah, it's yeah. There there were lots of lots

510
00:25:19,559 --> 00:25:23,279
of studios, lots of different tools for building AI applications

511
00:25:23,319 --> 00:25:29,720
within the Microsoft ecosystem, AI Studio, Open AI Studio, a

512
00:25:29,759 --> 00:25:31,880
bunch of them that kind of got co pilots do

513
00:25:32,000 --> 00:25:36,839
Copilot Studio, that's right. So, uh, the UH AI Foundry

514
00:25:36,920 --> 00:25:39,279
is sort of the the new integrated version of that.

515
00:25:39,680 --> 00:25:42,480
It gives dot net developers one place to go to

516
00:25:42,920 --> 00:25:45,039
if they're building these AI applications.

517
00:25:45,079 --> 00:25:47,079
Speaker 1: All right, so that's where you go on Azure if

518
00:25:47,119 --> 00:25:49,279
you want to get started, I guess you know, if

519
00:25:49,319 --> 00:25:53,160
you want to start building agents and and all of that.

520
00:25:53,519 --> 00:25:56,079
Speaker 2: So when you toggle the integration, is it how is

521
00:25:56,119 --> 00:25:58,680
it deploying elastic that point or are you using the

522
00:25:58,680 --> 00:26:01,119
server list version? Like, what's what's the actual impact?

523
00:26:01,519 --> 00:26:04,119
Speaker 3: You can if you've set it up already, you're just

524
00:26:04,440 --> 00:26:08,200
picking your pointing to a pointing to an existing cluster

525
00:26:08,400 --> 00:26:09,640
or an existing project.

526
00:26:09,720 --> 00:26:13,200
Speaker 2: In the serverless version, that might be your VM, or.

527
00:26:13,279 --> 00:26:14,880
Speaker 3: If you're wanting to create it from scratch, you can

528
00:26:14,920 --> 00:26:17,960
do that as well. Okay, so it's a seamless integration,

529
00:26:18,000 --> 00:26:21,359
which which is pretty amazing for you know, being a

530
00:26:21,400 --> 00:26:24,799
third party product. We're always pushing for these tight integrations

531
00:26:25,319 --> 00:26:26,519
and we've gotten that with Azure.

532
00:26:26,599 --> 00:26:28,799
Speaker 2: Now people like a checkbox and things just happen. It's

533
00:26:28,839 --> 00:26:32,039
just I'm putting my administrator's hat on. It's like the

534
00:26:32,079 --> 00:26:34,640
dev check that box and a VM appeared. In my world,

535
00:26:36,359 --> 00:26:38,240
I'd be more emotional about that. Where if it's the

536
00:26:38,279 --> 00:26:40,599
serverles offering, where it's just now we're just going to

537
00:26:40,640 --> 00:26:42,839
get a new bill. That's the cfo's problem. I don't

538
00:26:42,839 --> 00:26:43,480
mind that at all.

539
00:26:44,440 --> 00:26:44,920
Speaker 1: That's right.

540
00:26:46,079 --> 00:26:47,920
Speaker 2: So is it like do you get to pick the

541
00:26:48,440 --> 00:26:50,680
deploy mode or is it automatically.

542
00:26:50,519 --> 00:26:54,160
Speaker 3: The server This one is not enabled yet. Yeah, the servers,

543
00:26:54,160 --> 00:26:54,400
I mean.

544
00:26:54,359 --> 00:26:56,480
Speaker 2: We're talking the day you announced it, so that's fair.

545
00:26:57,240 --> 00:27:00,799
Speaker 3: But the the hosted version of our cloud offering is there,

546
00:27:00,880 --> 00:27:01,200
you can.

547
00:27:01,200 --> 00:27:02,920
Speaker 2: You can r so you could be hosted by you.

548
00:27:04,640 --> 00:27:05,400
Speaker 1: Yeah, we'll be.

549
00:27:05,400 --> 00:27:08,279
Speaker 3: Going ga with our server list offering in the coming

550
00:27:08,319 --> 00:27:10,880
weeks and then at that point you'd be able to

551
00:27:10,880 --> 00:27:12,319
just select that project as well.

552
00:27:12,839 --> 00:27:15,119
Speaker 2: And is that running in your infrastructure? Is it an Azure?

553
00:27:15,279 --> 00:27:16,200
Speaker 1: It's on Azure? Okay?

554
00:27:16,240 --> 00:27:17,640
Speaker 3: Yeah, yeah, it's all on Azure.

555
00:27:17,720 --> 00:27:19,880
Speaker 1: So can you give us an idea of how much

556
00:27:19,920 --> 00:27:25,079
it costs, I mean relative to other Azure resources?

557
00:27:25,119 --> 00:27:28,119
Speaker 3: Maybe, well if you're so. There's three different project types.

558
00:27:28,880 --> 00:27:32,640
There's the traditional search one, which you would handle use

559
00:27:32,720 --> 00:27:37,759
for typical search or vector search workloads. There's the observability one,

560
00:27:37,920 --> 00:27:41,839
which is sort of built around observability capabilities like log

561
00:27:41,880 --> 00:27:45,799
analytics and metrics. And then there's a security one because

562
00:27:45,839 --> 00:27:47,440
one of the things that happened along the way is

563
00:27:47,759 --> 00:27:51,519
people thread hunters started to use us as a security

564
00:27:51,559 --> 00:27:56,599
analytics platform, so we created entire product packaging of Elastic

565
00:27:57,200 --> 00:28:00,480
for security workloads. So for threat hunters, Wow, if you're

566
00:28:00,559 --> 00:28:06,599
using the observability or the security project, type. It's basically

567
00:28:07,000 --> 00:28:08,559
we just charge for the data going in and the

568
00:28:08,640 --> 00:28:11,119
data retained. If you're not using any data, you don't

569
00:28:11,119 --> 00:28:14,240
get charged to anything as simple as that. For the

570
00:28:14,319 --> 00:28:17,759
search one we charge. We call it a VCU. It's

571
00:28:17,759 --> 00:28:21,880
a virtual compute unit, and it scales to near zero.

572
00:28:22,079 --> 00:28:24,400
There's always a little bit of charge because we have

573
00:28:24,440 --> 00:28:26,559
to keep some cashes warm to handle any kind of

574
00:28:26,559 --> 00:28:28,920
incoming query. But it's like less than twenty bucks a

575
00:28:28,920 --> 00:28:33,279
month at the start, so pretty, you know, scales down

576
00:28:33,319 --> 00:28:33,960
to near zero.

577
00:28:34,039 --> 00:28:36,119
Speaker 1: That's really cool. Yeah, good to know. All right, So

578
00:28:37,160 --> 00:28:41,720
just a selfish question. Maybe the other listeners are thinking

579
00:28:41,759 --> 00:28:44,519
this too. All right, I'm committed to using Elasti search.

580
00:28:44,640 --> 00:28:46,880
I've got a relational database that has on my Goo

581
00:28:46,920 --> 00:28:48,880
in it. I got a lot of store procedures, and

582
00:28:48,880 --> 00:28:51,400
I got some views and stuff. How do I take

583
00:28:51,559 --> 00:28:55,880
all that t SQL in a big store procedure that

584
00:28:55,920 --> 00:28:59,319
returns multiple record sets from multiple places and turn that

585
00:28:59,400 --> 00:29:03,319
into a lab to search. Is there a language I do?

586
00:29:03,519 --> 00:29:08,440
Speaker 3: Is there a good migration into it? Yeah? Well, I'm

587
00:29:08,519 --> 00:29:10,599
I'm hoping we can build something with l MS that

588
00:29:10,599 --> 00:29:11,000
could do that.

589
00:29:11,079 --> 00:29:11,279
Speaker 1: Migra.

590
00:29:11,519 --> 00:29:13,359
Speaker 2: Yeah I do too, actually.

591
00:29:13,119 --> 00:29:14,319
Speaker 1: Because I don't want to do it.

592
00:29:13,960 --> 00:29:18,559
Speaker 3: It's so the there is. So we actually have our

593
00:29:18,599 --> 00:29:21,880
own uh sort of query language. It's called e s

594
00:29:21,960 --> 00:29:23,880
q O and it's a piped query language. So we

595
00:29:23,960 --> 00:29:28,640
use pipes and you can very power, very very linux

596
00:29:28,720 --> 00:29:31,559
very powers. Yeah, so you use pipes to pass uh,

597
00:29:31,680 --> 00:29:34,519
since you one query into another and it's a way

598
00:29:34,519 --> 00:29:38,680
of combining and uh, it's a very powerful query language.

599
00:29:39,000 --> 00:29:42,079
We introduced joins recently. Uh, so it can do a

600
00:29:42,119 --> 00:29:44,079
lot of the things that you can with with the

601
00:29:44,119 --> 00:29:47,920
traditional sequel language, but that's becoming our default language to

602
00:29:48,000 --> 00:29:51,920
that thing, and at least for analytical workloads. So if youre

603
00:29:51,960 --> 00:29:53,799
using this for search, you would just use the search API,

604
00:29:53,920 --> 00:29:57,960
but for analytical workloads, uh, you'd use this new query language.

605
00:29:58,119 --> 00:30:01,759
Speaker 1: So these conversions seem like a perfect job for an AI.

606
00:30:02,000 --> 00:30:04,440
Speaker 3: H oh yeah, yeah, so like this is this is

607
00:30:04,440 --> 00:30:08,519
actually something we do right now. People might use other

608
00:30:09,160 --> 00:30:12,359
solutions like Spunk, they have their own query language. People

609
00:30:12,480 --> 00:30:14,720
have used l o ms to the conversion of one

610
00:30:14,799 --> 00:30:19,400
query language into another. They're surprisingly accurate. So yeah, there's

611
00:30:19,440 --> 00:30:22,599
no reason. You know, once we get to sort of

612
00:30:22,640 --> 00:30:26,599
the functionality parody that you need for for SQL, that

613
00:30:26,680 --> 00:30:27,440
you couldn't.

614
00:30:27,079 --> 00:30:28,359
Speaker 1: Just use an l O And when'd you say your

615
00:30:28,440 --> 00:30:29,240
language is called.

616
00:30:29,079 --> 00:30:31,960
Speaker 3: Again e SQL query language.

617
00:30:32,000 --> 00:30:33,960
Speaker 1: Yeah, all right, so there's a good time kids to

618
00:30:34,000 --> 00:30:36,599
go out and learn the SQL, at least a little

619
00:30:36,599 --> 00:30:39,519
bit to know what you're going to be doing next

620
00:30:39,559 --> 00:30:43,119
year or maybe in a few months, who knows, or

621
00:30:43,920 --> 00:30:47,000
this afternoon or this afternoon really ambitious.

622
00:30:47,000 --> 00:30:50,680
Speaker 2: Generally, my experience when you're moving to non relational databases

623
00:30:50,839 --> 00:30:54,799
is you're calling APIs. It's basically just a coding exercise.

624
00:30:54,839 --> 00:30:57,359
You're different kind of data fetch and start, start effects

625
00:30:57,359 --> 00:30:59,640
and things like that. It's a different way thinking about it.

626
00:30:59,640 --> 00:31:02,799
And part of that to me is you're now handling

627
00:31:02,839 --> 00:31:05,839
the data differently like the query. The old query doesn't

628
00:31:05,920 --> 00:31:07,759
make sense if the data is stored in a different way.

629
00:31:07,759 --> 00:31:10,599
There there are no joins or not joins the way

630
00:31:10,640 --> 00:31:11,440
you're thinking of them.

631
00:31:11,440 --> 00:31:13,839
Speaker 3: No, it's not a join like it is a relation

632
00:31:14,519 --> 00:31:18,119
creating a join on sort of a no sequel data

633
00:31:18,119 --> 00:31:20,640
sert where we use it's a document based data system.

634
00:31:20,960 --> 00:31:22,359
Was challenging. How do you do that?

635
00:31:22,519 --> 00:31:22,720
Speaker 2: Yeah?

636
00:31:23,920 --> 00:31:26,119
Speaker 3: Uh yeah, it's a different way of interacting with data.

637
00:31:26,480 --> 00:31:27,880
It's a document based orientation.

638
00:31:28,039 --> 00:31:30,920
Speaker 2: Yeah, so you know the document the experience you've had

639
00:31:30,960 --> 00:31:33,160
to working with document databases is the right sort of

640
00:31:33,200 --> 00:31:38,039
approach to organizing things like I would be hesitant to

641
00:31:38,240 --> 00:31:41,359
just move a relational database to a vector database or

642
00:31:41,480 --> 00:31:44,400
area a document store of any kind just because the

643
00:31:44,599 --> 00:31:45,720
data is organized differently.

644
00:31:45,880 --> 00:31:50,240
Speaker 3: Which organized differently you're going to augment it with ectory base.

645
00:31:50,359 --> 00:31:51,720
Speaker 2: But now I like this idea of yeah, my order

646
00:31:51,759 --> 00:31:53,759
is still decomposed in the relational database. We have all

647
00:31:53,759 --> 00:31:55,039
the reporting and so f on that, but I also

648
00:31:55,119 --> 00:31:57,160
keep a copy and in the document start that's the

649
00:31:57,279 --> 00:32:00,400
entire order, and still got all those elements senate that

650
00:32:00,440 --> 00:32:02,799
are searchable and findable and so forth. That's right, but

651
00:32:03,200 --> 00:32:04,880
when you find any element of it, you find the

652
00:32:04,880 --> 00:32:05,240
whole thing.

653
00:32:05,359 --> 00:32:07,319
Speaker 1: So would you just call Kim Trip and Paul Randall

654
00:32:07,319 --> 00:32:08,799
and say, hey, optimize my indexes?

655
00:32:08,960 --> 00:32:09,359
Speaker 3: Pretty sure?

656
00:32:09,480 --> 00:32:12,960
Speaker 1: No, No, get kind of retired. Actually yeah, there's that,

657
00:32:12,599 --> 00:32:15,839
but I mean optimize the indexes. I mean, that's that's

658
00:32:16,119 --> 00:32:19,039
kind of where people go when they have search problem

659
00:32:19,319 --> 00:32:23,519
performance on SQL server. Yeah, well, in the.

660
00:32:23,559 --> 00:32:26,440
Speaker 3: Lastic search, that's completely everything is indexed. You don't you

661
00:32:26,480 --> 00:32:28,599
don't you don't pick you know what you want to index.

662
00:32:28,640 --> 00:32:30,440
Everything is index so that's not the.

663
00:32:30,480 --> 00:32:32,559
Speaker 1: End, and the next you're created on the fly?

664
00:32:32,640 --> 00:32:35,359
Speaker 3: Are they created as you're ingesting? Yeah, so it's all

665
00:32:35,440 --> 00:32:36,640
automatically created for you.

666
00:32:37,480 --> 00:32:39,880
Speaker 1: Any good document database, that's right. Yeah.

667
00:32:39,640 --> 00:32:41,680
Speaker 2: So, and I find it interesting to have the sort

668
00:32:41,720 --> 00:32:44,599
of three species there, like this security makes sense, that's

669
00:32:44,599 --> 00:32:47,960
a special thing. But the observability and this is the

670
00:32:48,119 --> 00:32:50,119
This is why I pulled that comment from the listener,

671
00:32:50,319 --> 00:32:53,519
was that guy was doing observability before it was a product.

672
00:32:53,599 --> 00:32:54,359
Speaker 1: Yeah.

673
00:32:54,480 --> 00:32:56,880
Speaker 3: So the interesting thing about search, One of the things

674
00:32:56,920 --> 00:33:00,160
that we've learned over the years is that search which

675
00:33:00,160 --> 00:33:02,599
is kind of everywhere, Like people start using search to

676
00:33:02,640 --> 00:33:07,440
build applications. It's not just about Initially when plastic search

677
00:33:08,359 --> 00:33:10,359
came out, it was about adding search to a website

678
00:33:10,440 --> 00:33:13,079
or adding it to a product search. That's right, So

679
00:33:13,279 --> 00:33:15,839
you know, you see what e commerce sites starting to

680
00:33:15,839 --> 00:33:20,039
integrate US. But people started building applications on top of US.

681
00:33:20,079 --> 00:33:24,759
They started building like matchmaking sites, or signal intelligence systems

682
00:33:24,799 --> 00:33:27,720
or fraud detection systems. It became sort of a platform

683
00:33:27,759 --> 00:33:30,480
for building things. But one of the most popular was

684
00:33:30,519 --> 00:33:33,680
people using US as a log analytics solution, right, using

685
00:33:33,759 --> 00:33:37,200
US to store and query logs. So rather than you know,

686
00:33:37,279 --> 00:33:39,720
do and doing grap They would use us as a solution,

687
00:33:39,920 --> 00:33:43,559
ship blogs to us and then run run fast queries

688
00:33:43,559 --> 00:33:46,359
on it. From there, people said, hey, if I'm going

689
00:33:46,400 --> 00:33:48,640
to use you for logs, can I use you for metrics?

690
00:33:48,640 --> 00:33:50,200
Can I use you for tracing? Can I use you

691
00:33:50,240 --> 00:33:54,960
for other things? Right, we started providing a complete observability platform.

692
00:33:54,799 --> 00:33:56,440
Speaker 2: And then that's the whole thing. Is like part of

693
00:33:56,440 --> 00:33:59,599
the challenge of doing this is all the different sources.

694
00:33:59,599 --> 00:34:01,240
So the fact that you have a place to drop

695
00:34:01,279 --> 00:34:03,799
all those sources routinely, so it's already in one spot

696
00:34:03,920 --> 00:34:04,599
and it's.

697
00:34:04,519 --> 00:34:05,920
Speaker 3: All in one one data story.

698
00:34:06,000 --> 00:34:08,599
Speaker 2: Yeah, and a quick one that can do a joint

699
00:34:08,639 --> 00:34:10,639
between those different rest laces when you need to.

700
00:34:10,800 --> 00:34:12,679
Speaker 3: Well, this is actually one of the one of the

701
00:34:12,719 --> 00:34:15,079
things I love to show about ESQL is being able

702
00:34:15,119 --> 00:34:19,599
to do a query across metrics and logs and traces

703
00:34:19,639 --> 00:34:22,079
and kind of blows people's minds, like, I'm going to

704
00:34:22,639 --> 00:34:26,320
do a query that joins data and creates this, show

705
00:34:26,400 --> 00:34:30,440
me all the all the hosts that have you know,

706
00:34:30,519 --> 00:34:33,639
ninety percent CPU and that have had a log in

707
00:34:33,679 --> 00:34:36,840
failure over the last hour, and that have had and

708
00:34:36,920 --> 00:34:40,079
you can combine different types of queries across different signal types,

709
00:34:40,119 --> 00:34:41,719
and it's kind of magical.

710
00:34:41,360 --> 00:34:42,400
Speaker 2: And it's powerful.

711
00:34:42,480 --> 00:34:45,960
Speaker 1: So I know that our listeners probably know more about

712
00:34:46,000 --> 00:34:50,440
Azure than they do about Elastic, and your audience probably

713
00:34:50,480 --> 00:34:54,000
knows more about Elastic than about Azure. Is there? Is

714
00:34:54,039 --> 00:34:55,159
that a fair statement?

715
00:34:55,199 --> 00:34:55,960
Speaker 3: I think that's fair.

716
00:34:56,079 --> 00:34:59,440
Speaker 1: Yeah, that's fair. Yeah, And so what can we tell

717
00:34:59,480 --> 00:35:02,039
these people about Azure if there if this is a

718
00:35:02,159 --> 00:35:06,159
new concept, do you know? I guess I have a

719
00:35:06,159 --> 00:35:09,480
customer right now that's all on prem and was picking

720
00:35:09,480 --> 00:35:12,440
my brain about moving to Azure, you know, and my

721
00:35:12,800 --> 00:35:15,599
response was, well, why aren't you there? Now?

722
00:35:15,719 --> 00:35:15,920
Speaker 3: You know?

723
00:35:16,000 --> 00:35:20,800
Speaker 1: It's like, because there's an inherent fear. This is my

724
00:35:21,079 --> 00:35:24,800
this is my word, it's the word of the week. Yeah,

725
00:35:24,800 --> 00:35:27,199
there's a fear by people that I think they don't

726
00:35:27,239 --> 00:35:30,519
trust moving their data somewhere else where they can't keep

727
00:35:30,519 --> 00:35:33,440
a watch on it. And my my response is, all right,

728
00:35:33,559 --> 00:35:36,880
so you have how many guys in your I T department? Two? Three? Okay?

729
00:35:37,039 --> 00:35:39,599
Do they all sleep at the same time? Yeah? Okay,

730
00:35:39,639 --> 00:35:42,840
So you know, in Azure, you've got hundreds probably of

731
00:35:42,960 --> 00:35:46,679
people all around the world that are watching over your

732
00:35:46,760 --> 00:35:50,119
data while you sleep, while you're awake, and who do

733
00:35:50,119 --> 00:35:54,599
you trust more Joe in It, who's a sleep eight

734
00:35:54,639 --> 00:35:57,440
hours of the day, or you know, the the Azure

735
00:35:57,480 --> 00:36:00,960
team that is watching over your fate at twenty four

736
00:36:01,000 --> 00:36:03,440
to seven. So that's my pitch. What do you what

737
00:36:03,480 --> 00:36:06,920
would you say to your your customers.

738
00:36:06,440 --> 00:36:10,239
Speaker 3: About why they should move to Azure or yeah, yeah,

739
00:36:10,320 --> 00:36:13,800
if you're on prem. Uh, you know, every every company

740
00:36:13,840 --> 00:36:16,159
that's started on prem is starting to think about the cloud.

741
00:36:16,159 --> 00:36:20,119
They've had this conversation for ten fifteen years. At this point,

742
00:36:20,159 --> 00:36:21,519
you're kind of feeling.

743
00:36:21,239 --> 00:36:24,960
Speaker 1: Like a late to the game. Yeah, but they're still

744
00:36:25,000 --> 00:36:28,639
out there obviously, Yeah, just having a conversation. Yeah.

745
00:36:28,679 --> 00:36:32,039
Speaker 3: So but yeah, I think most customers should be thinking

746
00:36:32,039 --> 00:36:36,039
about it. If they aren't already, you're not going to

747
00:36:36,039 --> 00:36:40,320
get the efficiencies of doing it yourself. There was there

748
00:36:40,400 --> 00:36:42,679
was this movement a few years ago where people started

749
00:36:42,719 --> 00:36:46,719
going back to their own data centers because they thought

750
00:36:46,719 --> 00:36:49,480
they could do it cheaper. And you can't, Like, you can't.

751
00:36:49,840 --> 00:36:53,400
You don't get the efficiencies at the scale that the

752
00:36:53,679 --> 00:36:56,360
cloud providers get like Azure. You don't get the like

753
00:36:56,400 --> 00:36:59,480
the ability to buy bandwidth in huge amounts. If you're

754
00:36:59,480 --> 00:37:01,679
trying to buy bandwidth by yourself. You're trying to buy

755
00:37:01,719 --> 00:37:03,920
servers by yourself, you're gonna pay a lot more. Sure,

756
00:37:04,400 --> 00:37:07,000
so any any savings that you think you can get

757
00:37:07,400 --> 00:37:08,880
is just going to be wiped away by.

758
00:37:08,840 --> 00:37:11,239
Speaker 1: Especially if you're paying by the transaction. That's right.

759
00:37:11,639 --> 00:37:14,159
Speaker 2: Yeah, but yeah, we did this whole series on run

760
00:37:14,199 --> 00:37:16,400
Ass Radio where a whole bunch of folks list lifted

761
00:37:16,400 --> 00:37:18,239
and shifted their vms into the cloud. Then we're shocked

762
00:37:18,239 --> 00:37:20,679
when the bill was big, Yeah, not recognizing you've run

763
00:37:20,719 --> 00:37:22,559
those vms twenty four hours a day, like you're paying

764
00:37:22,559 --> 00:37:24,679
twenty four hours a day for them. Yeah, and then

765
00:37:24,800 --> 00:37:27,760
moving up to the platform pieces was more efficient, but

766
00:37:28,039 --> 00:37:30,639
then they haul them back and they're just ignoring a

767
00:37:30,679 --> 00:37:32,800
bunch of the numbers. You know, you pay for the

768
00:37:32,800 --> 00:37:35,639
hardware once, so you forget about advertising across the period

769
00:37:36,119 --> 00:37:38,639
much less the replacement costs, and you know, all those

770
00:37:38,679 --> 00:37:39,840
other pieces to go into it.

771
00:37:39,800 --> 00:37:42,079
Speaker 1: And the difficulty of servicing them twenty four to seven.

772
00:37:42,239 --> 00:37:44,639
Speaker 2: Yeah, and then what a twenty four seven knock actually costs?

773
00:37:44,719 --> 00:37:50,480
Speaker 3: Yeah, it's expensive and it the minimum the minimum number

774
00:37:50,480 --> 00:37:52,360
of people you need to employ to do it properly

775
00:37:52,679 --> 00:37:56,280
is high. Yeah. Yeah, and you just can't get the

776
00:37:56,280 --> 00:37:57,760
scale like that, that's the biggest thing.

777
00:37:57,800 --> 00:38:00,800
Speaker 2: Like, yeah, if you're big enough in this debate, and

778
00:38:00,880 --> 00:38:03,000
it is still a debate because now we get into

779
00:38:03,079 --> 00:38:07,159
elastic utilization. Right when I had to build out websites,

780
00:38:07,199 --> 00:38:10,199
we built for peak. You know, you had to have

781
00:38:10,320 --> 00:38:12,719
enough gear to handle the peak load and then it

782
00:38:12,840 --> 00:38:15,920
ran its sixty percent utilization if you were lucky and

783
00:38:16,079 --> 00:38:18,440
you don't deal with that with the cloud, your peak

784
00:38:18,440 --> 00:38:21,239
can move around and you you scale dynamically. You only

785
00:38:21,239 --> 00:38:21,960
pay for what you use.

786
00:38:21,960 --> 00:38:24,039
Speaker 3: If you're a retailer and you're having to build for

787
00:38:24,719 --> 00:38:27,639
Black Friday or peak, that's yeah, it's crazy.

788
00:38:27,719 --> 00:38:30,480
Speaker 1: Once you rather just moving on or let it do that,

789
00:38:30,880 --> 00:38:31,360
not moving.

790
00:38:31,400 --> 00:38:33,199
Speaker 2: The knob moves by itself.

791
00:38:34,199 --> 00:38:39,599
Speaker 1: I can see it. It's moving. Yeah, it's not.

792
00:38:39,480 --> 00:38:42,719
Speaker 2: The same at all anymore. But yeah, it's been years

793
00:38:42,760 --> 00:38:44,440
since I've said, you know, if you haven't already moved

794
00:38:44,480 --> 00:38:45,920
the cloud, your CFO is looking at you're like, what

795
00:38:45,960 --> 00:38:46,559
are we doing?

796
00:38:46,840 --> 00:38:47,079
Speaker 1: Well?

797
00:38:47,119 --> 00:38:49,320
Speaker 3: I think yeah, I think that's a conversation most people

798
00:38:49,360 --> 00:38:51,559
had ten to fifteen years ago. Though, the conversation over

799
00:38:51,559 --> 00:38:54,559
the last couple of years is what's your AI strategy?

800
00:38:54,639 --> 00:38:54,800
Speaker 1: Yeah?

801
00:38:54,880 --> 00:38:59,079
Speaker 3: Right, Yeah, every every boardroom is asking their your exact team, like,

802
00:38:59,079 --> 00:39:01,320
what what's your ais ATEU? What are we doing to

803
00:39:01,920 --> 00:39:06,079
uh automate everything through AI? And that's a much harder

804
00:39:06,159 --> 00:39:08,280
question if you're not already on cloud. So if you,

805
00:39:08,400 --> 00:39:13,039
if you're, if you, if you skipped that way, you're

806
00:39:13,039 --> 00:39:16,400
already behind because the next thing is going to be like,

807
00:39:16,639 --> 00:39:18,880
you know, what are we doing to automate things with AI?

808
00:39:19,000 --> 00:39:20,679
What do we doing to automate sales? What are we

809
00:39:20,679 --> 00:39:23,880
doing to automate marketing? You know, are the engineers and

810
00:39:23,920 --> 00:39:25,400
our company using AI tools?

811
00:39:25,559 --> 00:39:27,920
Speaker 2: Most these tools are dependent on cloud. They dependent on

812
00:39:28,280 --> 00:39:30,000
You need to have your data there already if you're

813
00:39:30,039 --> 00:39:31,280
going to take advantage of That's right.

814
00:39:31,239 --> 00:39:35,239
Speaker 1: All right, good, we've beaten that horse. Is there anything

815
00:39:35,280 --> 00:39:37,360
that we haven't talked about that you would like to mention?

816
00:39:37,960 --> 00:39:42,079
Speaker 3: Mostly just uh that you know, we love the fact

817
00:39:42,079 --> 00:39:44,599
that Azure has been such a great partner with us

818
00:39:44,639 --> 00:39:47,679
and integrating us into you know, in such a tight way,

819
00:39:47,760 --> 00:39:51,199
into the experience, uh for customers who want to use

820
00:39:51,320 --> 00:39:53,559
you know, the best vector database out there. We are

821
00:39:53,599 --> 00:39:57,400
integrated already into Azures. So it's a phenomenal experience. I've

822
00:39:57,400 --> 00:39:59,800
said that already, But like you're the number one.

823
00:40:00,320 --> 00:40:01,840
Speaker 1: Yeah, yeah, I love.

824
00:40:02,000 --> 00:40:04,159
Speaker 3: I love that we have such a tight partnership and

825
00:40:04,800 --> 00:40:06,639
it creates a great experience for our customers and I

826
00:40:06,639 --> 00:40:09,119
will keep make sure that people go out and try it.

827
00:40:09,119 --> 00:40:09,639
Speaker 2: It's awesome.

828
00:40:09,719 --> 00:40:11,679
Speaker 1: Well that sounds like the end of the show, So

829
00:40:11,760 --> 00:40:14,159
thanks very much, Ken, Yeah, thank you for the pleasure

830
00:40:14,239 --> 00:40:16,159
having you and talking to you. I learned a whole

831
00:40:16,159 --> 00:40:18,840
lot and I'm sure listeners to too, And we'll talk

832
00:40:18,880 --> 00:40:42,639
to you next time on dot net rock. Dot Net

833
00:40:42,719 --> 00:40:45,639
Rocks is brought to you by Franklin's Net and produced

834
00:40:45,679 --> 00:40:49,519
by Pop Studios, a full service audio, video and post

835
00:40:49,519 --> 00:40:53,679
production facility located physically in New London, Connecticut, and of

836
00:40:53,719 --> 00:40:58,639
course in the cloud online at pwop dot com. Visit

837
00:40:58,679 --> 00:41:00,800
our website at d O T N E t R

838
00:41:00,840 --> 00:41:04,800
O c k S dot com for RSS feeds, downloads,

839
00:41:04,920 --> 00:41:08,599
mobile apps, comments, and access to the full archives going

840
00:41:08,639 --> 00:41:12,039
back to show number one, recorded in September two thousand

841
00:41:12,079 --> 00:41:14,719
and two. And make sure you check out our sponsors.

842
00:41:14,880 --> 00:41:17,880
They keep us in business. Now go write some code,

843
00:41:18,239 --> 00:41:19,000
see you next time.

844
00:41:19,920 --> 00:41:21,719
Speaker 2: You got Jamtle Vans