1
00:00:00,076 --> 00:00:03,800
Bret: Welcome to DevOps and Docker
Talk, and I am your host, Bret Fisher.

2
00:00:04,329 --> 00:00:07,699
Technically, the full name of
this is Cloud Native DevOps and

3
00:00:07,709 --> 00:00:10,149
Docker Talk with host Bret Fisher.

4
00:00:10,359 --> 00:00:13,439
But, you know, DDT is what
we call it inside the team.

5
00:00:13,859 --> 00:00:17,839
So DDT, we're now in our seventh year
of podcasting, and if you include

6
00:00:17,859 --> 00:00:21,240
the livestreams I was doing before
we started the podcast, I think

7
00:00:21,240 --> 00:00:25,039
it's over eight, maybe even nine at
this point, which is pretty amazing.

8
00:00:25,079 --> 00:00:28,079
Uh, not a lot of podcasts get to
last a decade, so I'm anxious to

9
00:00:28,079 --> 00:00:31,866
get there, and still have it called
DevOps and Docker Talk, which DevOps

10
00:00:31,896 --> 00:00:33,666
never died, Docker never died.

11
00:00:33,676 --> 00:00:35,306
Like, we didn't have to change the name

12
00:00:35,509 --> 00:00:39,919
But on here, we talk about all cloud
native things, and another Kubernetes

13
00:00:40,019 --> 00:00:45,079
project has begun and has now
showed up as a CNCF sandbox project

14
00:00:45,089 --> 00:00:46,609
this year, and that is OpenChoreo.

15
00:00:46,609 --> 00:00:46,969
Hence, open…

16
00:00:47,717 --> 00:00:51,027
Which stands for Open Choreography,
and that's where Choreo… I was

17
00:00:51,027 --> 00:00:54,527
actually mispronouncing it as choreo or
something with a hard H, but it's choreo.

18
00:00:54,957 --> 00:01:03,087
And this project is all about adding on AI
agents and essentially a new abstraction

19
00:01:03,187 --> 00:01:08,597
on Kubernetes itself that interfaces
between what we're all now using as our

20
00:01:08,597 --> 00:01:14,347
primary interface to everything software,
which is agent harnesses, and what the

21
00:01:14,347 --> 00:01:19,377
Kubernetes API and other APIs provide
that are typically on Kubernetes, like

22
00:01:19,377 --> 00:01:23,377
your monitoring or your observability or
whatever else you might need in there.

23
00:01:23,377 --> 00:01:24,347
There's a lot that goes on.

24
00:01:24,357 --> 00:01:28,417
But this project is adding a new
abstraction layer, I'm calling it an

25
00:01:28,417 --> 00:01:34,717
abstraction layer,  because it provides
API, MCP,  CLI, and web UI all to

26
00:01:34,737 --> 00:01:39,237
front end everything else you typically
deal with, whether that's your GitOps

27
00:01:39,747 --> 00:01:41,217
tools like Argo, your orchestration

28
00:01:42,645 --> 00:01:46,265
Your storage, your observability,
Kubernetes itself, your

29
00:01:46,265 --> 00:01:47,785
authentication, like all that stuff.

30
00:01:48,105 --> 00:01:53,595
And we are now in the world where we're
all playing around with agent SDKs and

31
00:01:53,595 --> 00:01:57,475
maybe trying to figure out what can we
automate in our infrastructure safely

32
00:01:57,785 --> 00:02:00,945
with reliable LLM prompts like this.

33
00:02:00,975 --> 00:02:02,845
These are all things we're
probably thinking about, right?

34
00:02:02,845 --> 00:02:04,955
If you're not doing it, you're thinking
about it, you're waiting for someone

35
00:02:04,955 --> 00:02:06,135
to tell you how to get it done.

36
00:02:06,535 --> 00:02:12,515
And OpenChoreo is a new project that
came out of WSO2, the company, and

37
00:02:12,525 --> 00:02:16,345
they were running it on their own SaaS
infrastructure and realized that it might

38
00:02:16,345 --> 00:02:20,465
be useful to others, which by the way, was
also how the Docker project got started

39
00:02:20,465 --> 00:02:24,145
by a SaaS company or a cloud company
realizing that their infrastructure

40
00:02:24,145 --> 00:02:28,425
tooling was maybe the most useful part of
their product, and released it for free.

41
00:02:28,479 --> 00:02:32,349
So OpenChoreo came out of a
business hosting a legitimate

42
00:02:32,399 --> 00:02:37,159
tool for Kubernetes users and felt
like it needed to be open source.

43
00:02:37,169 --> 00:02:39,789
So now they're gonna be running
that on their own platform

44
00:02:39,829 --> 00:02:40,949
for customers eventually.

45
00:02:40,949 --> 00:02:43,269
But for now, they're just focused
on getting it open source.

46
00:02:43,279 --> 00:02:46,959
And now that it's officially a CNCF
sandbox project, that means they've met

47
00:02:46,959 --> 00:02:53,719
the minimum level of sort of maturity
to explore whether this could succeed in

48
00:02:53,719 --> 00:02:58,059
the marketplace, explore whether or not
those of us that are building open source

49
00:02:58,069 --> 00:03:02,249
tools or running open source tools on
top of Kubernetes would be interested in

50
00:03:02,249 --> 00:03:05,739
an agent platform on top of Kubernetes.

51
00:03:05,769 --> 00:03:11,319
And specifically what this is about is
about us administrating and managing

52
00:03:11,349 --> 00:03:16,379
these environments with agent harnesses
through the OpenChoreo abstraction,

53
00:03:16,409 --> 00:03:18,919
so through their MCP API CLI.

54
00:03:19,169 --> 00:03:22,809
This is not about running inference
or building custom models.

55
00:03:22,989 --> 00:03:26,719
This isn't about being an AIOps
or MLOps person, and this isn't

56
00:03:26,719 --> 00:03:32,299
about running custom agents that we
built in pods inside of a cluster,

57
00:03:32,299 --> 00:03:33,589
although that's certainly possible.

58
00:03:33,589 --> 00:03:34,099
You can do that.

59
00:03:34,099 --> 00:03:39,559
But the main focus here is on exactly
what I talk about on this show, as well

60
00:03:39,559 --> 00:03:41,539
as my other podcast, Agentic DevOps.

61
00:03:41,559 --> 00:03:44,189
And quite frankly, this podcast
could probably be on both.

62
00:03:44,380 --> 00:03:46,860
I'm trying to prevent that from
happening because they're, you

63
00:03:46,860 --> 00:03:48,190
know, we've all got podcast players.

64
00:03:48,190 --> 00:03:50,430
You can add both of my podcasts
to the, your player, right?

65
00:03:50,430 --> 00:03:52,200
So you know that that's a thing.

66
00:03:52,260 --> 00:03:56,860
Um, and this one I'm trying to keep
focused on CNCF projects, Kubernetes and

67
00:03:56,860 --> 00:04:01,510
Docker projects, and the Agentics DevOps
podcast is really about the patterns,

68
00:04:01,510 --> 00:04:07,210
behaviors, and tools for just being
a DevOps or platform engineer or SRE

69
00:04:07,420 --> 00:04:09,260
who's using AI to get their job done.

70
00:04:09,310 --> 00:04:10,750
That's what that podcast is about.

71
00:04:10,790 --> 00:04:12,460
Technically, this could be on both.

72
00:04:12,910 --> 00:04:16,769
But, uh, anyway, On the show this
time, I have Lakmal and Sameera from

73
00:04:16,769 --> 00:04:20,989
the project team over at wso2 talking
about this, getting into the details

74
00:04:20,989 --> 00:04:25,049
of what it does and doesn't do, and
also explaining to me how it's not

75
00:04:25,049 --> 00:04:27,459
what I actually thought it was when
we first started talking about it.

76
00:04:27,759 --> 00:04:31,219
And we even on the livestream, which
you can link in the show notes, there's

77
00:04:31,229 --> 00:04:35,769
links to the actual demos that we tend to
cut out of the podcast version of this,

78
00:04:35,769 --> 00:04:37,319
but the demos are from the livestream.

79
00:04:37,329 --> 00:04:40,729
You can see how the product works, how
you can use agents to interface with

80
00:04:40,749 --> 00:04:44,763
Kubernetes, which we, could use agents
before, but we didn't necessarily

81
00:04:44,773 --> 00:04:49,223
have all of that infrastructure
in place besides just a raw API.

82
00:04:49,223 --> 00:04:54,413
So this helps solve a lot of that
with a new level of abstraction

83
00:04:54,413 --> 00:04:55,993
that we get into through this show.

84
00:04:56,114 --> 00:04:58,823
So let's get into it Welcome to the show.

85
00:04:58,963 --> 00:05:04,343
in the middle there, we got Lakmal, and
on the right, Samira, both from WSO2.

86
00:05:04,793 --> 00:05:06,083
Lakmal, tell us about yourself.

87
00:05:06,083 --> 00:05:06,873
Who are you?

88
00:05:07,093 --> 00:05:07,723
Why are you here?

89
00:05:08,223 --> 00:05:12,313
Lakmal: Yeah, I'm, working as a VP
and distinguished engineer at WS02,

90
00:05:12,603 --> 00:05:15,283
also a Choreo, DM before Choreo BU.

91
00:05:15,783 --> 00:05:19,463
yeah, I started my career as a
system engineer, in 2000, one,

92
00:05:19,923 --> 00:05:24,183
and last 25 years, I engaging
with building many, many platform.

93
00:05:24,453 --> 00:05:25,643
Yeah, here we are today.

94
00:05:26,903 --> 00:05:27,353
Bret: Nice.

95
00:05:27,863 --> 00:05:29,123
Sameera, how about you?

96
00:05:29,623 --> 00:05:30,253
Sameera: Hey, Bret.

97
00:05:30,513 --> 00:05:30,973
I'm good.

98
00:05:31,103 --> 00:05:31,813
I'm Sameera Jaswal.

99
00:05:31,813 --> 00:05:34,333
I'm one of the core maintainers
of OpenChoreo at WSO2, too.

100
00:05:34,833 --> 00:05:38,823
I started my career in the middle as a,
you know, you can think of programming

101
00:05:38,823 --> 00:05:42,643
language design, compile engineer,
platform architect, and then you'll

102
00:05:42,643 --> 00:05:46,193
hear more about how abstractions and
compilation throughout this talk.

103
00:05:47,093 --> 00:05:47,323
me.

104
00:05:48,685 --> 00:05:50,825
Bret: a gist by the end of
what you really are into.

105
00:05:50,875 --> 00:05:51,355
I'll get it.

106
00:05:51,385 --> 00:05:51,765
Okay.

107
00:05:52,165 --> 00:05:52,515
all right.

108
00:05:52,525 --> 00:05:54,035
So y- you all reached out.

109
00:05:54,035 --> 00:05:55,515
This is a new project.

110
00:05:55,595 --> 00:05:59,315
I'm always excited about new CNCF
projects because it kind of… It--

111
00:05:59,435 --> 00:06:02,945
Once they've accepted into the sandbox
process, we kind of get an idea.

112
00:06:02,945 --> 00:06:04,765
I feel like it's reading
the tea leaves a little bit.

113
00:06:04,765 --> 00:06:08,355
Not everything is a winner, not every
project makes it to graduation, but it's

114
00:06:08,355 --> 00:06:12,995
an interesting way, I think, to, like,
separate sort of the hobby projects or

115
00:06:12,995 --> 00:06:15,995
the experimentations from things that
teams are taking seriously, 'cause

116
00:06:16,005 --> 00:06:19,375
you don't really go for sandbox status
unless you're taking things seriously.

117
00:06:19,425 --> 00:06:21,835
That's where I sort of like wake
up and start paying attention to

118
00:06:21,835 --> 00:06:24,935
the new projects, and I'm excited
to talk about this today because

119
00:06:24,935 --> 00:06:27,425
I'm obsessed with AI agents.

120
00:06:27,425 --> 00:06:32,935
I'm obsessed with, like, how we manage
infrastructure with agents involved.

121
00:06:32,945 --> 00:06:35,425
How do we put MCP in our clusters safely?

122
00:06:35,495 --> 00:06:39,605
how do we sit on our harness as our
primary mechanism for interacting

123
00:06:39,605 --> 00:06:44,785
with, I don't know, 20 to 40 years of
complexity that we've all built up?

124
00:06:45,255 --> 00:06:48,905
Like, the number of abstractions we
all have to deal with today is insane,

125
00:06:48,905 --> 00:06:51,885
and it's amazing that anyone can
actually go to a conference and have

126
00:06:51,885 --> 00:06:54,575
a common conversation, 'cause there's
a thousand tools we're all using.

127
00:06:55,045 --> 00:06:56,535
So I'm excited to get into this.

128
00:06:56,595 --> 00:06:58,305
how did the project get started?

129
00:06:58,355 --> 00:06:59,525
who's gonna pick the first question?

130
00:06:59,525 --> 00:07:02,195
Like, how did this project
come out of the company?

131
00:07:02,265 --> 00:07:04,755
Lakmal: Yeah, we started
this, software offering called

132
00:07:04,755 --> 00:07:06,855
Choreo SaaS, five years back.

133
00:07:06,905 --> 00:07:12,755
it's, it start as a, the IPaaS initially,
like a integration platform as a service.

134
00:07:12,945 --> 00:07:16,735
Then it evolved into the…
You can run all other services

135
00:07:16,805 --> 00:07:17,705
within the platform itself.

136
00:07:17,985 --> 00:07:21,795
So it's, it evolved into the internal
developer platform, couple of years later.

137
00:07:22,225 --> 00:07:24,295
Name is also coming as a choreography.

138
00:07:24,315 --> 00:07:25,815
It's, we shorten it to the Choreo.

139
00:07:25,825 --> 00:07:29,465
It's like a choreography your
microservices in a certain way, like a

140
00:07:29,635 --> 00:07:33,595
Kubernetes do the orchestration, we do
choreography for all your microservices.

141
00:07:33,625 --> 00:07:35,495
That, that how the name also came.

142
00:07:35,995 --> 00:07:39,715
so we were offering this SaaS offering
to our customers, enterprise customers.

143
00:07:39,745 --> 00:07:41,605
It's fully managed by WS02.

144
00:07:42,525 --> 00:07:45,975
we were running Choreo version
2, and two years back we started

145
00:07:46,025 --> 00:07:47,695
Choreo version 3, project.

146
00:07:47,815 --> 00:07:49,865
So next version of the,
our current offering.

147
00:07:50,365 --> 00:07:56,255
Then eventually it's become the OpenChoreo
and in WS02, all our software open source.

148
00:07:56,665 --> 00:07:59,945
So we thought of, "Okay, why not we
are running… we having this software

149
00:08:00,115 --> 00:08:05,395
running as our SaaS. Why not open source
it?" That's how this OpenChoreo, started.

150
00:08:05,505 --> 00:08:09,855
Then, this year, January, we have
donated into the CNCf, Foundation.

151
00:08:09,865 --> 00:08:10,915
Now we are a sandbox project.

152
00:08:11,415 --> 00:08:11,745
Bret: Yeah.

153
00:08:12,245 --> 00:08:13,435
All happening so fast.

154
00:08:13,980 --> 00:08:17,530
that's a similar path, by the way,
to how Docker was invented, 'cause it

155
00:08:17,530 --> 00:08:21,160
was a platform company saying, "Hey,
this piece of our platform is pretty

156
00:08:21,160 --> 00:08:24,930
interesting, but it's also c- at this
point maybe a utility. let's just give

157
00:08:24,930 --> 00:08:26,760
it away." Turned out that that worked.

158
00:08:26,820 --> 00:08:28,920
so it's not a bad idea to do this.

159
00:08:29,355 --> 00:08:32,355
what was the unique problem we
were trying to solve with this?

160
00:08:32,375 --> 00:08:33,495
Like, I say we.

161
00:08:33,495 --> 00:08:34,475
I'm, I'm a part of the team now.

162
00:08:34,595 --> 00:08:39,735
how is it, how does the team look
at it from, like, this is a unique

163
00:08:39,745 --> 00:08:42,345
thing in a world where we've got
dozens of Kubernetes distros?

164
00:08:42,885 --> 00:08:45,245
In fact, first off, I should say,
do you even call, do you call

165
00:08:45,245 --> 00:08:48,065
this a, do you think of this as
like a distribution of Kubernetes?

166
00:08:48,565 --> 00:08:49,535
Sameera: N-not really.

167
00:08:49,935 --> 00:08:50,265
Bret: No?

168
00:08:50,765 --> 00:08:56,115
Like, do you see it as like a vanilla
Kubernetes with some things bolted on?

169
00:08:56,145 --> 00:08:59,075
Or like how is this different
from like a Rancher?

170
00:08:59,575 --> 00:09:01,035
Sameera: okay, I'll,
I'll take that question.

171
00:09:01,165 --> 00:09:04,595
in my opinion, so OpenChoreo
is something you, something we

172
00:09:04,605 --> 00:09:06,075
have built on top of Kubernetes.

173
00:09:06,489 --> 00:09:06,819
Bret: Mm-hmm.

174
00:09:06,965 --> 00:09:11,485
Sameera: So you can use any of
Kubernetes distro, Rancher, EKS, AKS,

175
00:09:11,505 --> 00:09:15,405
like any Kubernetes, and then you can
just install OpenChoreo on top of it.

176
00:09:15,905 --> 00:09:19,145
So the idea behind is that, so
you have Kubernetes and all the

177
00:09:19,145 --> 00:09:22,615
other tools, and then, so you have
a developer platform, I think.

178
00:09:23,115 --> 00:09:26,385
what we have seen in the industry is,
so you ca- you have this developer

179
00:09:26,385 --> 00:09:30,795
platform with Kubernetes and Argo
CD and all the things, glued on,

180
00:09:31,185 --> 00:09:35,135
and then you expose that layer to
developers, and you build a developer

181
00:09:35,135 --> 00:09:37,285
experience around it, portals, MCPs.

182
00:09:37,785 --> 00:09:41,315
then we have figured out that,
that way you expose the platform

183
00:09:41,315 --> 00:09:43,015
complexity to your developers.

184
00:09:43,515 --> 00:09:46,585
So they'll have to learn Kubernetes,
they'll have to learn all the tools.

185
00:09:47,085 --> 00:09:51,355
I think what's unique about here is, I
don't know whether this will work out, we

186
00:09:51,355 --> 00:09:55,245
build a middle layer, abstraction layer
on top of Kubernetes and other tools.

187
00:09:55,745 --> 00:09:57,785
And that's what Lakshman said earlier.

188
00:09:58,165 --> 00:10:01,015
Through like six years, we have
figured out the abstraction layer.

189
00:10:01,035 --> 00:10:02,695
That took some time for us to build.

190
00:10:03,195 --> 00:10:08,245
And then that abstraction layer helps for
us to build a developer experience layer.

191
00:10:08,375 --> 00:10:12,225
So developers, they're like kind of
abstracted away from Kubernetes, per se.

192
00:10:12,565 --> 00:10:17,465
They can still see what's going on, but
they may not to learn a lot of things

193
00:10:17,465 --> 00:10:18,575
about Kubernetes and other tools.

194
00:10:19,075 --> 00:10:19,535
Bret: Yeah

195
00:10:19,627 --> 00:10:22,937
Sameera: so that's about one of
the unique layers in the platform.

196
00:10:23,437 --> 00:10:25,197
Bret: So when we talk specifically
about Open- OpenChoreo,

197
00:10:27,250 --> 00:10:29,440
is it installing all the parts of this?

198
00:10:29,450 --> 00:10:31,300
Okay, so we're looking at it
for the, for the audio audience.

199
00:10:31,300 --> 00:10:32,720
We're looking at a visualization.

200
00:10:33,020 --> 00:10:36,920
I love diagrams 'cause they really help
me I l- the conceptual-ness of like what a

201
00:10:36,920 --> 00:10:40,700
thing is, is sometimes instead of a bullet
list, I love these, so, I brought that

202
00:10:40,710 --> 00:10:43,000
up, and there's all sorts of com- It's…

203
00:10:43,080 --> 00:10:47,620
To me, it looks like a full-fledged,
fully built out Kubernetes cluster

204
00:10:47,620 --> 00:10:48,930
with all the extras, right?

205
00:10:48,930 --> 00:10:52,080
Like, all the necessary things that a
sort of an enterprise cluster would have.

206
00:10:52,390 --> 00:10:54,550
it's got these data components.

207
00:10:54,550 --> 00:10:56,640
You know, you're mentioning
Keda for scaling.

208
00:10:56,640 --> 00:10:58,250
You've got Cilium in the networking.

209
00:10:58,250 --> 00:11:01,490
You've, you've got, you know, API
gateways in there, and then you

210
00:11:01,490 --> 00:11:05,370
showed part of the diagram, there's
the workflow part where it's Argo

211
00:11:05,370 --> 00:11:07,070
workflows and build packs in there.

212
00:11:07,070 --> 00:11:10,470
And then you've got observability layers
where you've got probably , I don't

213
00:11:10,470 --> 00:11:13,990
see Loki in there, but like Prometheus
and all the OpenTels, OTel stuff.

214
00:11:14,380 --> 00:11:17,870
And then over to the side, there's
OpenChoreo as this control plane.

215
00:11:17,870 --> 00:11:20,390
So it's almost like to me it's like the
control plane on top of the control plane.

216
00:11:20,780 --> 00:11:23,940
so is this really just focused about those
things on the left and you're showing how

217
00:11:23,940 --> 00:11:28,780
it interacts, or is this actually helping
us implement the rest of this puzzle?

218
00:11:28,920 --> 00:11:30,640
I was a little confused by that.

219
00:11:31,140 --> 00:11:31,380
Lakmal: Yeah.

220
00:11:31,380 --> 00:11:35,560
I think the main idea behind the,
having the unified control plane

221
00:11:35,760 --> 00:11:37,670
across all these, capabilities.

222
00:11:38,160 --> 00:11:41,880
p-platform engineers or developers or
even now AI agents can interact with

223
00:11:41,900 --> 00:11:44,230
control plane via our different protocols.

224
00:11:44,730 --> 00:11:48,540
And then control plane do the, all the
orchestration across all these other

225
00:11:48,540 --> 00:11:52,820
planes, like you, you mentioned the data
plane with the Cilium network policy,

226
00:11:52,850 --> 00:11:55,560
with the S-Scale Zero, with the Keda.

227
00:11:55,930 --> 00:12:00,560
All these thing can orchestrate using
a, a control plane with the governance

228
00:12:00,670 --> 00:12:02,750
enforce through the control plane.

229
00:12:02,950 --> 00:12:04,270
That's the main idea behind.

230
00:12:04,480 --> 00:12:09,950
So what, what have seen as a problem,
even we expose all these services to

231
00:12:09,950 --> 00:12:14,000
the end user, it can be a platform
engineer, it can developer, then

232
00:12:14,000 --> 00:12:15,380
you can't enforce the governance.

233
00:12:15,500 --> 00:12:20,060
But having this single control
layer, we can have the guardrails,

234
00:12:20,130 --> 00:12:24,360
policy enforcement, and y-
single, pane of glass, we can see

235
00:12:24,360 --> 00:12:25,860
everything within the control plane.

236
00:12:25,890 --> 00:12:30,260
So that help to orchestrate
across entire different pl-planes.

237
00:12:30,600 --> 00:12:34,910
That planes, built b- using the
modular architect in OpenChoreo.

238
00:12:35,340 --> 00:12:40,460
So for example, i-if you take a API
gateway, it can be come from the, WSO2

239
00:12:40,500 --> 00:12:43,460
gateway, K gateway, so, Co-Kong gateway.

240
00:12:43,520 --> 00:12:45,750
It doesn't tie to a single vendor.

241
00:12:46,230 --> 00:12:48,560
So it, it's building an
entire ecosystem around it.

242
00:12:48,660 --> 00:12:50,750
it's not only the platform itself.

243
00:12:51,250 --> 00:12:55,330
Users can pick and choose what they
want to use in their data plane.

244
00:12:55,830 --> 00:12:59,840
so that, the abstraction layer
help to, os- orchestrate all these

245
00:12:59,900 --> 00:13:03,610
different, vendor tooling that they
want to use in the, their planes

246
00:13:04,160 --> 00:13:08,270
Bret: so, so is it-- If I'm a platform
engineer, I-- and I'm listening

247
00:13:08,270 --> 00:13:10,160
to this show, that probably means
I have platforms today, right?

248
00:13:10,160 --> 00:13:11,790
Like I've already got
Kubernetes in production.

249
00:13:11,820 --> 00:13:13,350
I've already got a lot
of these components.

250
00:13:13,640 --> 00:13:19,570
So is the idea h-here that this particular
project is for implementing the left

251
00:13:19,570 --> 00:13:23,820
side of my screen of the specific
OpenChoreo control plane components,

252
00:13:23,840 --> 00:13:27,510
and then including those system
components that would link or integrate

253
00:13:27,510 --> 00:13:29,080
me with the APIs of those other things?

254
00:13:29,080 --> 00:13:31,720
Is that how-- Is that sort of
where you're drawing your boundary

255
00:13:31,720 --> 00:13:32,920
of where your project ends?

256
00:13:33,420 --> 00:13:33,780
Sameera: Yeah.

257
00:13:33,840 --> 00:13:36,380
yeah, I think that- that's
a good way to put it, Bret.

258
00:13:36,390 --> 00:13:40,650
So our main component would
be the control plane, that you

259
00:13:40,650 --> 00:13:42,650
see on the left of the screen.

260
00:13:43,020 --> 00:13:46,740
And then at the same time, there
are certain system components

261
00:13:46,740 --> 00:13:49,990
that are running in all the other
planes as well, data planes,

262
00:13:50,490 --> 00:13:52,450
observability plane, workflow planes.

263
00:13:52,950 --> 00:13:55,800
So if you're already running these
projects, then it's just a matter

264
00:13:56,570 --> 00:14:00,580
of like installing our system
components and organizing your sys-

265
00:14:00,730 --> 00:14:02,170
platform architecture in this way,

266
00:14:02,670 --> 00:14:03,060
Bret: Yeah

267
00:14:03,280 --> 00:14:03,660
Sameera: right?

268
00:14:04,050 --> 00:14:08,160
and then I think what Lakmal said
about abstractions is that the…

269
00:14:08,360 --> 00:14:12,310
When you think about these developer
platforms, primary users are platform

270
00:14:12,310 --> 00:14:16,560
engineers, as you said, and then,
primary consumers are developers,

271
00:14:17,060 --> 00:14:17,420
Bret: Right

272
00:14:17,524 --> 00:14:21,744
Sameera: So, so they will perhaps,
they will use the experience plane,

273
00:14:22,134 --> 00:14:23,944
UI, MCP server and things like that.

274
00:14:23,944 --> 00:14:27,714
They will say, "I, I want a project, I
want a component. I want component to

275
00:14:27,714 --> 00:14:29,614
de- deploy on dev environment," right?

276
00:14:30,024 --> 00:14:34,674
And the control plane understands that
and executes and compile that into

277
00:14:34,754 --> 00:14:38,954
Kubernetes and other projects, so in a
way that other projects understand, right?

278
00:14:39,454 --> 00:14:43,014
So that's how these arrows and everything,
that's the idea behind these arrows.

279
00:14:43,448 --> 00:14:43,970
Bret: Yeah.

280
00:14:44,480 --> 00:14:48,720
And when I'm looking at this diagram,
I mean, from s- from sort of a

281
00:14:49,070 --> 00:14:53,320
platform team perspective, I mean,
I recognize all the names, right?

282
00:14:53,320 --> 00:14:56,020
It's a lot of terminology,
from different, CNCF projects.

283
00:14:56,440 --> 00:15:02,820
But, are you thinking of this as AI
is the sort of main interaction point?

284
00:15:02,820 --> 00:15:06,000
I see here that we've got, like there's,
I think there's a, a web console or

285
00:15:06,000 --> 00:15:09,960
something, So, do you think about
this from the perspective of like AI

286
00:15:09,960 --> 00:15:13,930
is going to probably be increasingly
the way we interact with Kubernetes?

287
00:15:13,940 --> 00:15:18,360
So this thing, you know, we've got
these arrows in here of how things are

288
00:15:18,380 --> 00:15:22,590
interacting with the Kubernetes cluster,
and it feels like it's all going through

289
00:15:22,590 --> 00:15:25,350
the OpenChoreo control plane to get there.

290
00:15:25,350 --> 00:15:28,690
'Cause you've got this list of like,
we could use the U- Backstage UI,

291
00:15:28,700 --> 00:15:30,400
presumably that would be for humans only.

292
00:15:30,680 --> 00:15:32,950
unless maybe there's some pretty
graphs for the AI to look at.

293
00:15:32,950 --> 00:15:33,930
I'm not sure why it would use that.

294
00:15:34,150 --> 00:15:38,930
But then you've got MCP, CLI, and API as
these other interaction endpoints, and

295
00:15:38,930 --> 00:15:43,570
they're not… When I think, when I see
this diagram, I think, "Oh, this allows me

296
00:15:43,570 --> 00:15:48,040
to put another layer of abstraction for my
AI to work through, and so I'm not running

297
00:15:48,040 --> 00:15:52,720
my AI directly against a kubectl API,
or, you know, the Kubernetes native API."

298
00:15:52,750 --> 00:15:57,670
I've sort of got this enhanced layer,
with additional functionality, presumably

299
00:15:57,690 --> 00:16:00,640
maybe some… Yeah, I see you have
authorization and access control,

300
00:16:00,640 --> 00:16:01,860
which is a big thing for me lately.

301
00:16:01,860 --> 00:16:05,930
Like how do we minimize the blast radius
of giving agents access to different

302
00:16:06,350 --> 00:16:11,030
tokens and like not giving them root, you
know, God rights to the cluster every day?

303
00:16:11,330 --> 00:16:14,670
which I see a lot of people doing by just
giving them the kubectl admin abilities.

304
00:16:14,970 --> 00:16:19,600
is that kind of the, the goal
of, of where you see agents being

305
00:16:19,830 --> 00:16:21,370
responsible for all these clusters?

306
00:16:21,870 --> 00:16:22,130
Lakmal: Yeah.

307
00:16:22,140 --> 00:16:24,690
E-exactly that, you
describe is correctly, Bret.

308
00:16:24,930 --> 00:16:29,310
So, what we want to have is, now in
the developer platform, we give the

309
00:16:29,400 --> 00:16:33,550
golden path, the guardrails, the
policies to our human developer.

310
00:16:33,910 --> 00:16:37,840
The same way we want to expose
this golden path to the AI agents

311
00:16:37,880 --> 00:16:39,310
that interact within the platform.

312
00:16:39,850 --> 00:16:43,250
So in, in OpenChoreo, the agents
are in first class citizens, so

313
00:16:43,260 --> 00:16:46,830
they can, at the moment, current,
release, we exposing two MCP servers.

314
00:16:47,330 --> 00:16:50,780
One is the OpenChoreo control
pane MCP server, other one is the

315
00:16:50,780 --> 00:16:52,560
OpenChoreo observability MCP server.

316
00:16:52,970 --> 00:16:57,260
So even external agents can
interact with this MCP as well

317
00:16:57,260 --> 00:17:00,710
as internal agent, inbuilt agents
can interact with MCP C- servers.

318
00:17:01,140 --> 00:17:06,210
Now, when they interact with MCP
servers, they have the permissions

319
00:17:06,210 --> 00:17:10,220
and all the guardrails will apply same
as the developer, using the platform.

320
00:17:10,680 --> 00:17:16,150
It's a unified experience, whether it's
a human developer, human SRE, or a agent,

321
00:17:16,390 --> 00:17:18,780
working with the, SRE a- or as a developer

322
00:17:19,633 --> 00:17:20,153
Bret: Very cool.

323
00:17:20,653 --> 00:17:25,663
All right, so this shows up as a
whole bunch of MCP tools that I

324
00:17:25,663 --> 00:17:29,333
could plug in locally to my local…
So if I've got Claude Code running,

325
00:17:29,813 --> 00:17:31,973
I plug the MCP endpoints in.

326
00:17:32,473 --> 00:17:34,303
do you know, like, the
estimated tool count?

327
00:17:34,313 --> 00:17:35,323
Like, what are we dealing with here?

328
00:17:35,333 --> 00:17:36,313
100, 100 tools?

329
00:17:36,373 --> 00:17:37,043
20 tools?

330
00:17:38,425 --> 00:17:38,725
Lakmal: yeah.

331
00:17:38,725 --> 00:17:42,105
we have, depending on the user
persona interact with MCP.

332
00:17:42,105 --> 00:17:45,885
So we have the developer
persona, we have the SRE persona.

333
00:17:46,025 --> 00:17:49,335
They give different, tooling
based on the, what their role.

334
00:17:49,835 --> 00:17:53,415
Yeah, so based on that they can
do different, different, activity.

335
00:17:53,561 --> 00:17:55,220
Sameera: roughly 100.

336
00:17:55,720 --> 00:17:56,120
Bret: Okay.

337
00:17:56,250 --> 00:17:56,640
Okay.

338
00:17:56,658 --> 00:17:58,208
Sameera: say 100 tools altogether

339
00:17:58,440 --> 00:18:01,680
Bret: a not insignificant amount
of tools, but that's a good point.

340
00:18:01,680 --> 00:18:06,030
So what you're saying is based on who I'm
au- authing as, which role I'm authing

341
00:18:06,030 --> 00:18:10,180
as, I, I get a scoped set of MCP tools
based on my permissions essentially?

342
00:18:10,830 --> 00:18:11,150
Yeah.

343
00:18:11,434 --> 00:18:11,864
Sameera: exactly

344
00:18:12,364 --> 00:18:13,824
Bret: So, all right.

345
00:18:14,324 --> 00:18:17,844
so these agents are coming, you're
listing AI agent modules here.

346
00:18:17,844 --> 00:18:20,024
You got SRE, FinOps, and architect.

347
00:18:20,304 --> 00:18:22,194
are these things that are,
that are coming defined?

348
00:18:22,204 --> 00:18:24,624
Like, and what does that agent mean to me?

349
00:18:24,624 --> 00:18:28,244
Like, if I'm on my local harness, does
this mean that those are long-running

350
00:18:28,264 --> 00:18:29,994
agents that are sitting in the cluster?

351
00:18:29,994 --> 00:18:31,694
Like, how do I interact with those agents?

352
00:18:32,194 --> 00:18:35,714
Sameera: like Lakmal said earlier, we
have internal agents and external agents.

353
00:18:36,214 --> 00:18:39,914
They both use the same experience,
plain MCP servers, tools.

354
00:18:40,414 --> 00:18:41,704
Claude Code is the external agent.

355
00:18:41,884 --> 00:18:45,114
these FinOps, SRE, and architecture
agent, they're like platform

356
00:18:45,114 --> 00:18:47,034
agents running in the cluster,

357
00:18:47,508 --> 00:18:47,838
Bret: Yeah

358
00:18:48,084 --> 00:18:50,194
Sameera: and they are reacting
to certain events in a way.

359
00:18:50,694 --> 00:18:55,744
For example, if you, if there's an
alert, like lot of i00, errors are

360
00:18:55,744 --> 00:19:01,074
going on, then our SRE agent will react,
and then it'll give you some report on

361
00:19:01,074 --> 00:19:03,204
what's going on, why this is happening.

362
00:19:03,504 --> 00:19:04,594
So you can configure that way.

363
00:19:04,594 --> 00:19:07,684
You can configure the agent with
certain alerts, types of alerts,

364
00:19:07,764 --> 00:19:12,054
memory, memory, like if you are
consuming high memory, certain limit

365
00:19:12,104 --> 00:19:14,014
that SRE agent will again react.

366
00:19:14,514 --> 00:19:14,864
Bret: Sure

367
00:19:15,156 --> 00:19:17,556
Sameera: FinOps agent is
also similar in that way.

368
00:19:18,056 --> 00:19:18,226
Yeah.

369
00:19:18,538 --> 00:19:18,928
Bret: I see.

370
00:19:18,998 --> 00:19:23,038
So each of those agents comes sort
of predefined, it sounds like.

371
00:19:23,038 --> 00:19:24,128
Like, they have a scope to them.

372
00:19:24,488 --> 00:19:28,378
And then presumably, I guess I'm
somehow through the control plane, I'm

373
00:19:28,388 --> 00:19:32,268
plugging those into, like, my messaging
apps or other… Like, into Slack or

374
00:19:32,268 --> 00:19:36,528
whatever, and that those are how those
agents reach out to me is through…

375
00:19:36,828 --> 00:19:39,338
Or do they go through a middle
layer of, like, an alerting system

376
00:19:39,338 --> 00:19:40,898
like Prometheus has for alerts?

377
00:19:40,908 --> 00:19:44,908
Like, how does that path
look for the agents letting

378
00:19:44,908 --> 00:19:46,048
us all know of the problems?

379
00:19:46,956 --> 00:19:47,286
Lakmal: Yeah.

380
00:19:47,336 --> 00:19:50,466
at the moment it's going a middle
layer, the alerting system.

381
00:19:50,516 --> 00:19:53,906
we have the log-based alerting,
with the OpenSearch and other layer,

382
00:19:54,186 --> 00:19:55,736
and the Prometheus for the metrics.

383
00:19:55,736 --> 00:19:58,776
So agents also ke-going the same layer.

384
00:19:59,226 --> 00:20:02,426
this alerting system can be,
configured with the PagerDuty or

385
00:20:02,426 --> 00:20:04,596
Slack channel or the other channels.

386
00:20:04,766 --> 00:20:06,366
That how the architecture
currently working.

387
00:20:06,366 --> 00:20:06,566
Yeah

388
00:20:07,026 --> 00:20:07,486
Bret: Yeah.

389
00:20:07,796 --> 00:20:12,616
And so this feels like it's designed to be
sort of, I mean, we, I think the website

390
00:20:12,616 --> 00:20:13,956
or something said batteries included.

391
00:20:14,226 --> 00:20:15,926
I think I included that
in the, in the thumbnail.

392
00:20:16,186 --> 00:20:19,786
It, 'cause it, a lot of the,
the conversations that I have,

393
00:20:19,826 --> 00:20:23,486
I mean, I'm lucky to be in this,
this DevOps, Agentic DevOps guild

394
00:20:23,486 --> 00:20:24,726
that I run, and we meet weekly.

395
00:20:24,726 --> 00:20:28,536
So I get to talk with dozens of teams
around, like, what they're trying to

396
00:20:28,536 --> 00:20:33,836
do right now in terms of everything
agents related to infrastructure

397
00:20:33,836 --> 00:20:35,686
and this exact stuff, right?

398
00:20:35,976 --> 00:20:38,986
So people are sort of in that
middle mode right now where

399
00:20:38,986 --> 00:20:42,776
we've-- the local agent harness has
kind of become common knowledge.

400
00:20:42,776 --> 00:20:46,786
Like, we've all experimented with
GUIs and TUIs and multi-agent

401
00:20:46,796 --> 00:20:48,876
management and sessions and skills.

402
00:20:48,876 --> 00:20:51,556
Like, we're all, you know, this is
the year of s- playing with skills.

403
00:20:51,956 --> 00:20:56,306
And, but then the minute that I have
to start running agents, I'm, I just

404
00:20:56,306 --> 00:20:59,356
call these things server agents b-
to try to define the difference.

405
00:20:59,706 --> 00:21:04,446
These 20, these long-running, always
looping agents that are sitting there

406
00:21:04,656 --> 00:21:08,136
checking something or, continually
polling for something or waiting for a

407
00:21:08,136 --> 00:21:09,666
webhook, maybe if they're event-driven.

408
00:21:09,966 --> 00:21:11,646
Like, these things are
probably gonna be everywhere.

409
00:21:11,656 --> 00:21:12,966
We're gonna have them all over the place.

410
00:21:13,366 --> 00:21:18,886
And y- you're providing th- a few of those
that are sort of out of the box defined

411
00:21:18,896 --> 00:21:24,446
to do specific things, so I don't have to
go find an agent SDK and make up my ideas

412
00:21:24,446 --> 00:21:26,306
of what an agent might do in my cluster.

413
00:21:26,306 --> 00:21:28,246
'Cause that kind of feels like what
a lot of us are doing right now,

414
00:21:28,246 --> 00:21:32,046
is we're sort of making up, we're
writing little a- agents everywhere.

415
00:21:32,046 --> 00:21:34,206
We're making it up as we go along
'cause we don't really know what

416
00:21:34,206 --> 00:21:37,166
parts that they, we would automate
or which parts they would be good at.

417
00:21:37,186 --> 00:21:40,746
You know, what parts of summarization
and human judgment do they do well,

418
00:21:40,746 --> 00:21:42,336
and what context do they need?

419
00:21:42,346 --> 00:21:45,836
And that's… So, but it feels
like the rest of this system, is

420
00:21:45,836 --> 00:21:48,306
the rest of this system to help
them with the context problem?

421
00:21:48,306 --> 00:21:51,506
'Cause that always feels like a
really hard problem right now around

422
00:21:51,516 --> 00:21:55,346
how, what context do I need to give
my agent to make it useful and not

423
00:21:55,346 --> 00:21:58,346
hallucinate, and how do I get at
that stuff at the time it needs it?

424
00:21:58,846 --> 00:21:59,856
Lakmal: Yeah, exactly.

425
00:22:00,026 --> 00:22:03,406
So I think the main idea behind
we have this ecosystem, within

426
00:22:03,406 --> 00:22:04,716
the ecosystem we have the agents.

427
00:22:04,786 --> 00:22:09,656
So, in community or even, we, OpenChoreo
maintainers will release a agent, then

428
00:22:09,706 --> 00:22:14,016
our users can pick and choose this
agent run in their OpenChoreo system.

429
00:22:14,406 --> 00:22:19,036
So for example, for SRE agent, the
intention behind that, okay, when I say

430
00:22:19,136 --> 00:22:24,936
when something happen, SRE agent can,
triggered and we feeding, all the logs,

431
00:22:24,936 --> 00:22:29,426
matrices, config changes, code changes
to the SRE agent within that window.

432
00:22:29,816 --> 00:22:34,846
Then, what happen, so it can generate the
RCA report, root cause analysis report,

433
00:22:35,256 --> 00:22:38,606
and also alerting to the SRE, human SRE.

434
00:22:38,616 --> 00:22:41,666
When they come into the system,
they already have the root cause

435
00:22:41,666 --> 00:22:45,216
analysis report there, that
is providing to the SRE agent.

436
00:22:45,656 --> 00:22:47,196
And also we are not stopping there.

437
00:22:47,196 --> 00:22:50,106
this agent can provide the
re-remediation action as well.

438
00:22:50,506 --> 00:22:54,026
Okay, this is a quick fix if
you want to, fix this issue.

439
00:22:54,466 --> 00:22:58,276
So then at the moment it's a
human in the loop, SRE, human

440
00:22:58,276 --> 00:23:00,176
SRE can apply these fixes.

441
00:23:00,556 --> 00:23:06,336
But, I mean, we have the permission
model where we can give some of the,

442
00:23:06,636 --> 00:23:11,566
this agent to automatically apply these
fixes, themself, rather waiting to SRE.

443
00:23:11,566 --> 00:23:15,906
We can say, "Okay, is it only config
change? I will allow my SRE agent to

444
00:23:16,086 --> 00:23:21,216
apply that change and fix the issue."
So eventually it can take the more,

445
00:23:21,246 --> 00:23:26,306
more like activity, but it's again,
it's had the human control, in the loop.

446
00:23:26,666 --> 00:23:28,416
So that's how the, we have designed it.

447
00:23:28,736 --> 00:23:34,086
Like you said, the main i- intention
behind it, so we running a system

448
00:23:34,086 --> 00:23:36,566
agent, you can, you say, survey agent.

449
00:23:36,846 --> 00:23:40,526
We know what are the context we
need, feed into this agent to

450
00:23:40,526 --> 00:23:42,086
provide a better, better result.

451
00:23:42,086 --> 00:23:44,676
So that's how these
inbuilt agents are, acting.

452
00:23:45,176 --> 00:23:47,926
Sameera: Yeah, and I also think,
like, if you're running something,

453
00:23:48,266 --> 00:23:51,436
this is, these agents are a good
starting point for you to come up

454
00:23:51,496 --> 00:23:53,506
with your own agents as well using.

455
00:23:54,006 --> 00:23:57,626
And then you can replicate with, you can,
come up with your own agents because the

456
00:23:57,626 --> 00:24:02,906
context problem is kinda solved i- in,
within the platform, what Lakmal said.

457
00:24:03,366 --> 00:24:08,826
So you can… Because these are all
about not exposing Kubernetes details

458
00:24:09,006 --> 00:24:12,916
into the agent, but exposing the
OpenChoreo abstraction layer, so that

459
00:24:12,946 --> 00:24:14,936
way it's what we have figured out.

460
00:24:14,996 --> 00:24:16,906
I mean, not sure whether it'll work.

461
00:24:17,236 --> 00:24:17,906
Bret: that's the hard part.

462
00:24:17,936 --> 00:24:18,156
Yeah.

463
00:24:18,816 --> 00:24:19,226
Sameera: Yeah.

464
00:24:19,286 --> 00:24:24,206
Figure out is this abstraction field
helped us to give the right context also

465
00:24:24,706 --> 00:24:25,046
Bret: Yeah.

466
00:24:25,086 --> 00:24:26,256
all right.

467
00:24:26,301 --> 00:24:29,891
so I was writing this article over
the last week around what does an

468
00:24:29,901 --> 00:24:31,841
AI Kubernetes platform even mean?

469
00:24:31,941 --> 00:24:35,561
And what we're really talking about
here is something that I had to define

470
00:24:35,731 --> 00:24:40,871
in this newsletter as what I'm calling
type three AI on Kubernetes . It sounds

471
00:24:40,871 --> 00:24:44,611
really nerdy, but if you've been going
to KubeCons since the invention of

472
00:24:44,611 --> 00:24:51,221
ChatGPT, for most of the history of
what we now call gen AI or whatever-- we

473
00:24:51,221 --> 00:24:53,551
are not talking about AIOps and MLOps.

474
00:24:53,561 --> 00:24:57,881
I mean, technically you could use this
thing to manage that too, but for those of

475
00:24:57,881 --> 00:25:01,181
us that go to KubeCon, there's been-- I've
been ranting a little bit for a couple

476
00:25:01,181 --> 00:25:05,851
of years now that there's been this weird
disconnect where when a lot of people

477
00:25:05,881 --> 00:25:09,391
in the industry talk about Kubernetes
and AI, they're actually talking about

478
00:25:09,391 --> 00:25:14,601
running AI or making AI, building
models, reinforcement, learning, running

479
00:25:14,611 --> 00:25:18,061
inference, and that, that is not my world.

480
00:25:18,101 --> 00:25:19,781
Like, I am not that person, right?

481
00:25:19,781 --> 00:25:22,281
It's interesting from an architecture
and engineering perspective, but

482
00:25:22,281 --> 00:25:25,791
I don't think I'll ever… that to
me, that's a speci-specialty and it

483
00:25:25,791 --> 00:25:28,351
might get easier to do, and some of
us might have to have that new role.

484
00:25:28,611 --> 00:25:31,311
But I feel like there's still a
significant, maybe even majority

485
00:25:31,311 --> 00:25:33,221
of us that won't be doing that.

486
00:25:33,311 --> 00:25:38,341
our new job is to build out these
agents and understand where the, you

487
00:25:38,341 --> 00:25:43,071
know, the features and the edges of
models can be implemented so that

488
00:25:43,081 --> 00:25:44,961
we can automate and build more.

489
00:25:45,001 --> 00:25:49,891
Because I see this whole thing as just
like VMs, the cloud, the invention

490
00:25:49,891 --> 00:25:54,861
of the PC, you… I-over my 30-year
career, we've had major pivoting points

491
00:25:54,861 --> 00:25:59,001
in technology that essentially allowed
us to scale ourselves as a human.

492
00:25:59,041 --> 00:26:02,651
We went from managing 10 servers in
the '90s to 100 servers with VMs to

493
00:26:02,651 --> 00:26:04,531
a, a thousand servers with the cloud.

494
00:26:04,941 --> 00:26:10,461
Maybe containers allowed us to run
10,000 pods per, per admin, and

495
00:26:10,461 --> 00:26:12,651
then now this is the next level.

496
00:26:12,651 --> 00:26:17,311
And to me, what you all are building is
exactly that layer of abstraction, which

497
00:26:17,321 --> 00:26:22,661
is the agents and their context management
and permission management essentially.

498
00:26:23,001 --> 00:26:27,421
that layer is now this new
level of abstraction that will

499
00:26:27,921 --> 00:26:29,851
hide some of the complexity.

500
00:26:30,351 --> 00:26:33,061
Like, we don't have to know every
kubectl command in the world anymore.

501
00:26:33,061 --> 00:26:35,871
In fact, I don't even know how we all
get Kubernetes certified because if

502
00:26:35,871 --> 00:26:39,591
we're not gonna be running kubectl
and have to know every option, what

503
00:26:39,591 --> 00:26:42,631
is a Kubernetes admin test other
than just understanding architecture?

504
00:26:43,101 --> 00:26:46,601
But my rant here is that like I had to
go through… This post took me a re-week

505
00:26:46,601 --> 00:26:50,911
to write because I was trying to theorize
around we're really talking about agentic

506
00:26:50,931 --> 00:26:54,781
operations, and that's where I'm--
that's the reason I have the new podcast.

507
00:26:54,811 --> 00:26:59,181
That's the reason this project is
exciting, is this is that new layer.

508
00:26:59,181 --> 00:27:01,941
This is the abstraction that
we're all kind of searching for

509
00:27:01,941 --> 00:27:05,401
because I think we've understood
the local harness now after having

510
00:27:05,401 --> 00:27:06,581
those for a little over a year.

511
00:27:06,701 --> 00:27:10,261
I think a lot of us are like, "Yeah, I,
I get this." We have all sorts of neat

512
00:27:10,261 --> 00:27:15,701
ways of managing these little local
agents, but this new nebulous layer that's

513
00:27:15,701 --> 00:27:19,771
sitting in front of our infrastructure
is still not fully realized.

514
00:27:19,771 --> 00:27:23,901
So I feel like you all are pretty early in
the game in terms of saying, we can help.

515
00:27:24,131 --> 00:27:29,091
We have this defined component, and we can
shove it in there." And, I'm even trying

516
00:27:29,091 --> 00:27:36,781
to draw out a diagram of what- If we're
all on a maturity path to, we started

517
00:27:36,781 --> 00:27:42,341
with the agent harness locally, and the
end goal is we've maximized the agent

518
00:27:42,841 --> 00:27:44,171
assistance that we're all gonna have.

519
00:27:44,171 --> 00:27:47,611
Like the dozen agents we're gonna
have, two dozen agents, we've maximized

520
00:27:47,621 --> 00:27:52,391
all the functions and features of
what models can do for us as DevOps

521
00:27:52,441 --> 00:27:54,531
platform engineers, SREs, right?

522
00:27:54,811 --> 00:28:01,171
all of us are managing this infrastructure
and there's a dozen tools and f- the

523
00:28:01,171 --> 00:28:04,261
thousand features we all now need
to learn, and we're learning skills

524
00:28:04,261 --> 00:28:08,701
and agent files and MCPs and where
all that can go awry and go crazy.

525
00:28:08,911 --> 00:28:12,621
But eventually the idea is we're improving
our productivity, we're improving our

526
00:28:12,621 --> 00:28:16,151
management, we're hopefully making
things more secure and reducing,

527
00:28:16,501 --> 00:28:18,471
outages and everything's getting better.

528
00:28:18,971 --> 00:28:21,681
But at the end of it, what are we doing?

529
00:28:21,721 --> 00:28:26,631
And I think a year ago we were all kind
of nervous like, are our jobs going away?

530
00:28:26,631 --> 00:28:27,911
that's been a big conversation.

531
00:28:27,921 --> 00:28:30,551
are we-- Is there only gonna be
one DevOps person in the company?

532
00:28:31,051 --> 00:28:34,731
But to me, this is the job, like
this is the new job, is you all built

533
00:28:34,731 --> 00:28:36,261
this, now we've got to implement it.

534
00:28:36,281 --> 00:28:39,041
Now we've got to understand it, we
got to understand the components.

535
00:28:39,461 --> 00:28:40,611
Where do the agents help?

536
00:28:40,621 --> 00:28:41,601
where do they not help?

537
00:28:41,861 --> 00:28:43,931
where do we still need the human
in the loop, like you said?

538
00:28:44,291 --> 00:28:47,751
and I just wondered if that's, if any
of that is anything that you would

539
00:28:47,751 --> 00:28:49,881
agree with or that I'm… Am I crazy?

540
00:28:49,901 --> 00:28:52,061
Does this all sound like
a good idea to talk about?

541
00:28:52,399 --> 00:28:53,999
Lakmal: No, I think, this is great, Bret.

542
00:28:54,019 --> 00:28:54,939
I think you're, you are correct.

543
00:28:54,939 --> 00:29:00,299
So yeah, it's evolved last one year,
within the one year, we can run agent in

544
00:29:00,299 --> 00:29:04,169
production, like helping to the different
personas engaging within the platform.

545
00:29:04,619 --> 00:29:09,419
I believe the generating code problem
is almost solved now with the Claude

546
00:29:09,419 --> 00:29:11,759
Code or other Cursor or Codex, right?

547
00:29:12,099 --> 00:29:15,979
So people can generate code, write
application within minutes So we

548
00:29:15,979 --> 00:29:17,299
call it as vibe coding, right?

549
00:29:17,599 --> 00:29:18,869
Everyone call it as vibe coding.

550
00:29:19,369 --> 00:29:23,699
When the moment they hit the
deployment, their vibe is ending.

551
00:29:24,119 --> 00:29:29,609
Because now with vibe coded, application
has to be promoted into the production.

552
00:29:30,049 --> 00:29:34,919
But still, the platform doesn't support--
they have to m- go away from their agent.

553
00:29:35,209 --> 00:29:37,979
They have to either create a ticket
or like, go to the self-service

554
00:29:37,989 --> 00:29:40,489
portal, and deploy the application.

555
00:29:40,849 --> 00:29:45,709
But what we have seen, within
the, our, skills and MCP servers,

556
00:29:45,969 --> 00:29:49,609
they can use the same, agent they
are using to develop, their code.

557
00:29:49,939 --> 00:29:54,049
They can say, "Okay," I can say, "I
want to deploy, the, my application

558
00:29:54,049 --> 00:29:55,769
into the development environment.

559
00:29:56,009 --> 00:30:00,809
Just you figure it out how to do it."
So now it's, we call it vibe deployment.

560
00:30:00,959 --> 00:30:05,339
So OpenChoreo try to fix, fill
the gap, vibe deployment part,

561
00:30:05,369 --> 00:30:07,159
how the operations side of it.

562
00:30:07,349 --> 00:30:10,859
So you can write, agent, you
can write your code using agent.

563
00:30:10,899 --> 00:30:14,919
Now you use, you can use the same agent
to deploy your application into the

564
00:30:14,919 --> 00:30:19,309
production and operation, with support
of OpenChoreo, section as well as the

565
00:30:19,349 --> 00:30:21,749
tools supporting to the MCP servers.

566
00:30:22,249 --> 00:30:25,029
that's, where we are, we want
to play, around this, platform

567
00:30:25,039 --> 00:30:25,619
engineering side of it.

568
00:30:26,119 --> 00:30:26,529
Sameera: Yeah.

569
00:30:27,029 --> 00:30:30,249
And Bret, I think you mentioned,
some-something about how

570
00:30:30,249 --> 00:30:32,459
abstractions help agents, right?

571
00:30:32,959 --> 00:30:36,499
I think the way I think about that
is more abstractions, fewer tokens,

572
00:30:36,999 --> 00:30:37,249
Bret: Hmm.

573
00:30:37,447 --> 00:30:41,437
Sameera: so they don't have to learn
Kubernetes deep YAMLs and kubectl.

574
00:30:41,937 --> 00:30:44,947
like, I think the same applies to
programming languages in a way,

575
00:30:45,357 --> 00:30:49,127
writing assembly versus writing
in Java or C# or Go, right?

576
00:30:49,627 --> 00:30:50,927
fewer tokens in that way.

577
00:30:51,317 --> 00:30:54,987
So they, they have more
context with less tokens.

578
00:30:55,127 --> 00:30:58,467
I think that is also, that's what
I'm, working on these days, see

579
00:30:58,467 --> 00:30:59,477
whether we can establish that.

580
00:31:01,099 --> 00:31:04,279
Bret: Yeah, that's a, I think we're all
very quickly, especially these last three

581
00:31:04,279 --> 00:31:08,369
months when it comes to tokens, we're very
quickly understanding that this is finite,

582
00:31:08,709 --> 00:31:13,816
and that, just kind of like Kubernetes
itself, we've all had that moment where,

583
00:31:14,316 --> 00:31:18,796
early in our Kubernetes journey, we
would realize how much infrastructure

584
00:31:18,796 --> 00:31:22,016
we actually need to just run the apps.

585
00:31:22,016 --> 00:31:25,506
Like we, you know, the, when you
build out a full-scale Kubernetes

586
00:31:25,546 --> 00:31:29,376
cluster, th- there's a s- there's a
non-insignificant amount of infrastructure

587
00:31:29,376 --> 00:31:30,696
to manage the infrastructure.

588
00:31:31,086 --> 00:31:34,826
And that, back when we first started
the journey on Kubernetes, I don't

589
00:31:34,826 --> 00:31:38,876
think we all really understood, the
eventuality of dozens of different

590
00:31:39,116 --> 00:31:43,336
controllers and dedicated nodes in the
control plane that we were gonna have

591
00:31:43,336 --> 00:31:47,226
to have just to organize and Uh, to,
to herd the cats, as, they might say.

592
00:31:47,606 --> 00:31:50,756
And, I feel like now the
same thing is with tokens.

593
00:31:50,756 --> 00:31:53,836
It's like we got all excited, and we're
like, "We're gonna put it everywhere."

594
00:31:54,246 --> 00:31:58,766
And now we're gonna very quickly end
up in a world where we've got budgets,

595
00:31:58,816 --> 00:32:01,726
and now we've got to optimize our
agents, and we have to care about the

596
00:32:01,726 --> 00:32:03,576
model, and we have to, we have to…

597
00:32:03,596 --> 00:32:06,676
One of the conversations we're having
in the Agentic DevOps Guild is around

598
00:32:06,706 --> 00:32:12,216
evals and how can we use evals, to
sort of figure out which model, if

599
00:32:12,216 --> 00:32:15,616
I can apply a bunch of skills, if my
agents are really just behaving with a

600
00:32:15,616 --> 00:32:20,106
bunch of skills and context management
stuff, how can I, sort of evaluate or

601
00:32:20,106 --> 00:32:25,586
programmatically determine or test that
maybe I could use Kimi or, MiniMax or

602
00:32:25,596 --> 00:32:30,656
Qwen or some, sort of open weight model
that's super cheap for my very specific

603
00:32:30,696 --> 00:32:32,826
little, you know, FinOps niche agent.

604
00:32:33,326 --> 00:32:36,196
Whereas it maybe doesn't need Opus
because maybe that's the one that

605
00:32:36,196 --> 00:32:38,776
I need because I have dumb prompts
and I s- I type dumb things.

606
00:32:39,126 --> 00:32:43,386
And maybe my agent in the cluster can
be running really cheap because none

607
00:32:43,386 --> 00:32:47,276
of us wanna put these in production and
then find out a month later that it's

608
00:32:47,276 --> 00:32:50,426
too expensive to run, and now I have
to shut it down and make the humans

609
00:32:50,426 --> 00:32:53,776
do it again because I don't think
that's a world I, I wanna go back to.

610
00:32:54,276 --> 00:32:54,806
Lakmal: That's true

611
00:32:55,356 --> 00:32:57,946
Bret: I know a couple of companies
that are playing in this space.

612
00:32:57,946 --> 00:33:01,406
We've had Anyshift on the show,
we've had, Mendral on the show,

613
00:33:01,406 --> 00:33:06,146
and these are both AI startups that
are building agents to help with

614
00:33:06,166 --> 00:33:10,666
infrastructure, CI/CD, sort of helping,
helping you with fault remediation.

615
00:33:10,716 --> 00:33:13,916
and the pro- approach that I've
been seeing everybody take is,

616
00:33:13,916 --> 00:33:17,496
like, it's just sort of the normal
pattern of engineering approach.

617
00:33:17,646 --> 00:33:22,516
We walk before we run, you know, we r-
we run before we sprint, and that means

618
00:33:22,516 --> 00:33:24,316
on day one, you might be read-only.

619
00:33:24,356 --> 00:33:28,466
agents can't do things, they can
just go look up things, and that

620
00:33:28,476 --> 00:33:31,216
they're just a little helper
assistant, and they're not gonna…

621
00:33:31,326 --> 00:33:32,806
They have no control over anything.

622
00:33:32,816 --> 00:33:35,516
They're just here to help you
find information in the sea of,

623
00:33:35,866 --> 00:33:38,246
of infinite information that we
have about our infrastructure.

624
00:33:38,606 --> 00:33:41,266
And then, then, like, with Mendral,
the team with Mendral that's been on

625
00:33:41,266 --> 00:33:44,836
the show, they're now to the point
where, very specific use cases, they're

626
00:33:44,836 --> 00:33:48,446
letting the agent have a tiny bit
of control because it's predictable.

627
00:33:48,446 --> 00:33:51,336
They can test and make sure that
it's, that it works, that it-

628
00:33:51,336 --> 00:33:55,196
it's as declarative as possible
so that it is predictable, and

629
00:33:55,196 --> 00:33:56,996
they start to, to let that happen.

630
00:33:57,296 --> 00:34:00,056
is that something we
can do with OpenChoreo?

631
00:34:00,186 --> 00:34:03,936
Like, does this have sort of a default
stance of, "I'm only gonna be read-only"?

632
00:34:04,276 --> 00:34:06,246
how does, how do the
permissions work that way?

633
00:34:06,746 --> 00:34:09,736
Lakmal: Yeah, it's not only the read-only
at the moment, but you can control it.

634
00:34:10,026 --> 00:34:12,866
we have the permission model
where, you can give the, different

635
00:34:12,876 --> 00:34:14,066
tool to the UI, your agents.

636
00:34:14,151 --> 00:34:17,751
It can be read-only tools, it can
be write operational tools as well.

637
00:34:18,151 --> 00:34:21,971
Based on the, what we want to do, you
can allow this permission, because agent

638
00:34:21,991 --> 00:34:25,491
have their own identity, and they, within
the identity they have the permission.

639
00:34:25,971 --> 00:34:28,501
So based on the permission,
they can use different tools.

640
00:34:28,661 --> 00:34:33,451
if you are confident enough that your
agent is acting, performing well, you

641
00:34:33,451 --> 00:34:37,391
can give the right permission to some
s- some level of factory, for example.

642
00:34:37,581 --> 00:34:41,661
you can give like, okay, if there are
configuration issue, agent can go and

643
00:34:41,661 --> 00:34:44,051
fix it itself, the configuration, fixes.

644
00:34:44,361 --> 00:34:47,831
So you can fine-tune how you, your
agent can interact with your platform

645
00:34:48,331 --> 00:34:48,721
Bret: Yeah.

646
00:34:49,271 --> 00:34:54,091
I've been wondering about a lot
of this around, like, how is per-

647
00:34:54,191 --> 00:34:55,781
how are permissions gonna work?

648
00:34:55,831 --> 00:35:00,461
so much of our permissions models today
feel like they're not designed for an

649
00:35:00,461 --> 00:35:04,981
agentic world, and, how are we gonna
track the actions of these things?

650
00:35:04,981 --> 00:35:08,671
Like, every little step they take,
is hopefully gonna be put into some

651
00:35:08,671 --> 00:35:10,301
sort of observability platform.

652
00:35:10,671 --> 00:35:13,681
So I'm, I am very curious to see
how, what your all's vision is.

653
00:35:13,681 --> 00:35:14,081
Okay.

654
00:35:14,581 --> 00:35:18,991
Yeah, I'm trying to envision, what ends
up… Like, how to correlate this to

655
00:35:18,991 --> 00:35:24,671
the things we know today, like GitOps
repos with Argo CD definition files

656
00:35:24,671 --> 00:35:29,541
in them that, that get, you know,
pulled in because Argo's watching

657
00:35:29,541 --> 00:35:33,271
or Flux is watching a different repo
and it's looking for YAML changes.

658
00:35:33,571 --> 00:35:37,291
And, I'm assuming, does
this change that workflow?

659
00:35:37,341 --> 00:35:40,531
Does… I remember seeing GitOps on
the diagram, so I'm kinda thinking,

660
00:35:40,531 --> 00:35:44,201
like, how does this correlate to
sort of that, that GitOps loop that

661
00:35:44,201 --> 00:35:45,711
we've seen so many teams adopt?

662
00:35:46,211 --> 00:35:48,101
Sameera: Yeah, I think
these, the CRDs, right?

663
00:35:48,201 --> 00:35:52,531
so they, you can put all of these in
your, in your GitHub repo, and then you

664
00:35:52,531 --> 00:35:54,661
can configure Argo CD, configure Flux.

665
00:35:55,141 --> 00:35:58,731
the normal workflow will
work as it is, right?

666
00:35:59,191 --> 00:35:59,601
Bret: Okay

667
00:35:59,931 --> 00:36:01,521
Sameera: And so there
are two modes, right?

668
00:36:01,531 --> 00:36:06,571
Here, I think we are using more ClickOps,
ClickOps approach, but you can configure

669
00:36:06,601 --> 00:36:08,631
the same thing with, your GitOps.

670
00:36:09,413 --> 00:36:09,503
Bret: Oh,

671
00:36:09,711 --> 00:36:11,171
Sameera: will talk to… Yeah

672
00:36:11,703 --> 00:36:11,733
Bret: I see.

673
00:36:11,733 --> 00:36:14,513
S- so yeah, so in this case, what
we're saying is like, I mean, yeah,

674
00:36:14,513 --> 00:36:17,233
we're looking at a web dashboard,
but we're not really… We're j-

675
00:36:17,233 --> 00:36:20,153
I mean, for the audio listeners,
we're, we're looking at a dashboard.

676
00:36:20,153 --> 00:36:22,723
We're not really, we're
vibe opsing, I guess.

677
00:36:22,723 --> 00:36:23,793
Not ClickOpsing, 'cause
we're not clicking on the

678
00:36:23,867 --> 00:36:24,257
Lakmal: Yeah

679
00:36:24,863 --> 00:36:25,093
Bret: dashboard.

680
00:36:25,243 --> 00:36:27,963
we're using the agent, but the
agent is causing… Just to be

681
00:36:27,963 --> 00:36:29,143
clear, this is actually a question.

682
00:36:29,313 --> 00:36:34,393
So the agent is causing OpenChoreo
to create new resources inside the

683
00:36:34,393 --> 00:36:38,883
cluster for deploying this inf-
this, the Google, microservice demo.

684
00:36:39,243 --> 00:36:45,213
And I, that is an alternative to having an
agent that I just say, "Hey, we're gonna

685
00:36:45,213 --> 00:36:49,243
make a new PR in YAML, and you're gonna
push that to GitHub, and then Argo or Flux

686
00:36:49,243 --> 00:36:53,283
is gonna pick that up later." because I
guess I could, I could tell these agents,

687
00:36:53,283 --> 00:36:57,163
or I could give them skills or change
the skills somehow so that it knows that

688
00:36:57,183 --> 00:37:01,703
that's my workflow, and that I'm just
using it as sort of a read-only partner.

689
00:37:01,703 --> 00:37:05,483
But kind of just like we're not
supposed to go into the AWS console

690
00:37:05,483 --> 00:37:11,293
and ClickOps away there, like, I don't
necessarily want OpenChoreo changing my

691
00:37:11,293 --> 00:37:14,463
infrastructure outside of my GitOps loop.

692
00:37:14,683 --> 00:37:18,983
I'm actually just curious, do you
think that the GitOps approach is less

693
00:37:18,983 --> 00:37:24,123
important if we have this sort of chain
of events and… or do you, like, do

694
00:37:24,123 --> 00:37:28,063
you see enterprise teams possibly mo-
shifting to more of this vibe approach

695
00:37:28,063 --> 00:37:29,143
since we have something in the middle?

696
00:37:29,143 --> 00:37:31,623
Or do you think that, you think
that GitOps is, like, here to

697
00:37:31,623 --> 00:37:34,563
stay and that's still the s- sort
of more mature, safe approach?

698
00:37:35,047 --> 00:37:35,237
Lakmal: Yeah.

699
00:37:35,447 --> 00:37:39,437
I would say, when you come to the
lower environment, this a-agentic

700
00:37:39,937 --> 00:37:43,737
directly creating this re-custom
resources will play a big role.

701
00:37:44,237 --> 00:37:48,407
because, but maybe in, in production, when
you promote in the production, people will

702
00:37:48,417 --> 00:37:52,567
use, GitOps or declarative way of defining
these things, in-into the production.

703
00:37:53,047 --> 00:37:57,177
but eventually if the human will
confident enough with your agents

704
00:37:57,557 --> 00:38:02,587
a-and, trust your, agent, eventually
I would say, people agent can directly

705
00:38:02,587 --> 00:38:07,387
call to the MCPs and create the,
like, the create custom resources

706
00:38:07,427 --> 00:38:08,987
directly within the class itself.

707
00:38:09,487 --> 00:38:09,947
Bret: Yeah

708
00:38:10,085 --> 00:38:11,165
Sameera: way I think, exactly.

709
00:38:11,221 --> 00:38:13,111
Lakmal: in the this year,
but maybe in future.

710
00:38:13,611 --> 00:38:16,601
Sameera: I mean, one, one adv-
the way I think about that is, I

711
00:38:16,601 --> 00:38:20,001
don't know, one advantage of GitOps
is you have the tracing, right?

712
00:38:20,011 --> 00:38:23,081
you know what, what happened
exactly over the years.

713
00:38:23,581 --> 00:38:28,311
Probably, yeah, dev environment
probably you don't need GitOps,

714
00:38:28,321 --> 00:38:32,481
like you can give developers full
capability, do whatever you want.

715
00:38:32,801 --> 00:38:37,281
But for other environments, I don't know,
my view, like you would be… I would

716
00:38:37,281 --> 00:38:39,561
still use GitOps to control the workflow.

717
00:38:40,451 --> 00:38:40,701
Yeah

718
00:38:41,093 --> 00:38:45,473
Bret: Yeah, I've started to wonder if,
if the agents will eventually sort of

719
00:38:45,473 --> 00:38:49,881
like- We're interacting with the local
agent on our Claude Code, and we're using

720
00:38:49,881 --> 00:38:53,391
these skills and, I think everyone's
already writing the YAML with agents.

721
00:38:53,391 --> 00:38:56,221
Like, we're already at the point
where teams that have u- are using

722
00:38:56,221 --> 00:38:58,711
Claude Code, they're not handwriting
Kubernetes YAML anymore, right?

723
00:38:58,711 --> 00:38:59,471
they have the agent do that.

724
00:38:59,471 --> 00:39:00,761
Why would, why would I
wanna do that anymore?

725
00:39:01,201 --> 00:39:05,321
And, I wondered if there was m- 'cause
there is a mode in Argo where, like,

726
00:39:05,331 --> 00:39:09,641
you can sorta do things retroactively,
where maybe you make changes,

727
00:39:09,641 --> 00:39:12,411
but then you document them after
you're, after you're, you're done.

728
00:39:12,411 --> 00:39:18,021
And I wondered if agents possibly created
a future where GitOps was more re- m-maybe

729
00:39:18,071 --> 00:39:21,591
not the first thing we did, but maybe
more of a, a system of record, but done

730
00:39:21,611 --> 00:39:26,401
after and if agents sort of were pushing
us into a faster evolution of this.

731
00:39:26,581 --> 00:39:30,131
a constant conversation we're all
having is around sandboxing and,

732
00:39:30,241 --> 00:39:31,931
specifically, our local agents.

733
00:39:32,331 --> 00:39:35,421
one of the challenges is, I'm just
doing stuff on my local machine all

734
00:39:35,421 --> 00:39:38,441
day, and I don't necessarily… And
every AI that I open up by default, even

735
00:39:38,441 --> 00:39:42,031
if I use, like, Claude Code built-in
sandboxing, chances are it has access

736
00:39:42,031 --> 00:39:46,401
to my AWS, my, my Docker CLI, my kubectl
CLI, my Terraform, all these things,

737
00:39:46,411 --> 00:39:51,271
and those keys are all already authed,
and it could just deploy to things.

738
00:39:51,651 --> 00:39:55,501
And so one of the, one of the things
that I'm trying to work on with

739
00:39:55,501 --> 00:39:58,501
some friends is, where could we
draw a boundary around sandboxes?

740
00:39:58,501 --> 00:40:02,971
And this almost feels like a very
perfect scenario of these MCP tools and

741
00:40:02,981 --> 00:40:07,891
these skills are maybe all in a Docker
sandbox, which is more of like a VM with

742
00:40:07,891 --> 00:40:10,061
a, with the harness running inside it.

743
00:40:10,321 --> 00:40:14,611
And I only use that particular harness
because it has these particular,

744
00:40:14,971 --> 00:40:18,731
permissions, and I only spin that
one up when I want to… It's almost

745
00:40:18,731 --> 00:40:22,921
like per environment, configuration,
and each Docker sandbox tends

746
00:40:22,921 --> 00:40:24,251
to have its own configuration.

747
00:40:24,301 --> 00:40:27,531
the, it's… The way at least it works now
is it's very, things are very isolated,

748
00:40:27,531 --> 00:40:29,271
including all your keys and everything.

749
00:40:29,271 --> 00:40:33,381
It, it doesn't really bring a lot
into it, so you're sort of isolating

750
00:40:33,381 --> 00:40:34,591
everything into different harnesses.

751
00:40:34,601 --> 00:40:38,791
So I'd have, like, my prod harness, my,
my staging harness, and I can interact

752
00:40:38,791 --> 00:40:43,471
with those environments, and keep them
safe away from, like, my normal day-to-day

753
00:40:43,471 --> 00:40:48,421
harness that kind of has maybe too
many… a lot of small teams, too many

754
00:40:48,421 --> 00:40:49,801
keys are on their local machines, right?

755
00:40:49,851 --> 00:40:50,331
they know it.

756
00:40:50,341 --> 00:40:50,921
They're out there.

757
00:40:51,091 --> 00:40:55,281
if you're a team of three, chances are you
probably got the production Terraform key

758
00:40:55,281 --> 00:40:59,751
on your machine, and you're just like, you
know not to type the Terraform commands.

759
00:40:59,751 --> 00:41:00,831
you know that's the human thing.

760
00:41:00,831 --> 00:41:02,641
But now that we have the agents, I
think people are getting, starting

761
00:41:02,641 --> 00:41:03,581
to get a little more concerned.

762
00:41:03,581 --> 00:41:06,131
They're like: What if it accidentally
picks the wrong environment?

763
00:41:06,131 --> 00:41:08,701
Or if it-- I accidentally have the
wrong key and it just starts going?

764
00:41:09,081 --> 00:41:13,061
so this feels like a very, very
interesting approach of Each environment,

765
00:41:13,061 --> 00:41:16,091
or, I'm assuming this thing manages,
can manage multiple clusters in one

766
00:41:16,101 --> 00:41:18,751
OpenChoreo, or is it a per cluster thing?

767
00:41:18,963 --> 00:41:21,533
Lakmal: It's one multiple clusters
you can manage within OpenChoreo.

768
00:41:21,703 --> 00:41:22,033
Bret: Yeah.

769
00:41:22,363 --> 00:41:26,373
so yeah, so I, I almost treat it like an
environmental gateway t- for my agents

770
00:41:26,373 --> 00:41:30,823
where I'm like, I call this production and
I have this special Docker sandbox or what

771
00:41:30,823 --> 00:41:35,483
other sandbox I wanna apply, and the keys
to production, even if it's read-only,

772
00:41:35,513 --> 00:41:38,153
are only accessible from that thing.

773
00:41:38,163 --> 00:41:42,923
And maybe also I'm gonna have some GitHub
keys in there so that my agents i- in that

774
00:41:42,923 --> 00:41:45,023
sandbox can also write to the GitOps repo.

775
00:41:45,023 --> 00:41:46,493
Maybe they can make the PRs for me.

776
00:41:46,913 --> 00:41:49,603
but I'm now realizing how these things
are coming together, where I can have

777
00:41:49,603 --> 00:41:53,483
the one local agent that can see the
infrastructure through OpenChoreo,

778
00:41:53,863 --> 00:41:57,673
but can also implement GitOps changes
based on the information that it's

779
00:41:57,683 --> 00:41:58,893
getting out of the infrastructure.

780
00:41:58,893 --> 00:42:04,823
So if the pods and, you know, a
pull back off loop, I can see that

781
00:42:04,883 --> 00:42:08,353
the agent can determine that, write
me the GitOps in the same session.

782
00:42:08,363 --> 00:42:09,873
It writes the GitOps b- diff.

783
00:42:10,373 --> 00:42:14,733
We're pushing that to a PR, and that's how
I'm gonna be iterating on my cluster now.

784
00:42:14,733 --> 00:42:17,263
Or maybe I'm doing it in Slack while I'm
at lunch, and it's all just through a

785
00:42:17,263 --> 00:42:22,553
Slack bot, and I'm not even… I'll ask
you these questions to make sure that we

786
00:42:22,553 --> 00:42:24,143
have them, have them at top of mind here.

787
00:42:24,353 --> 00:42:26,833
"I like it's Claude Code that
can interpret or understand,

788
00:42:26,843 --> 00:42:30,463
promote into staging. Can we use
a private LLM to interact with

789
00:42:30,463 --> 00:42:32,143
OpenChoreo instead of Claude Code?"

790
00:42:32,643 --> 00:42:35,033
Lakmal: yeah, so it's, it's
totally, in Claude Code, it's,

791
00:42:35,063 --> 00:42:36,323
it's your, your model, right?

792
00:42:36,323 --> 00:42:37,603
So it's a, Anthropic model.

793
00:42:37,823 --> 00:42:40,163
You can use any Codex or any other agent.

794
00:42:40,223 --> 00:42:42,953
It's just MCP servers
you are interacting with.

795
00:42:43,253 --> 00:42:45,413
You can use any LLM, in your local agent.

796
00:42:45,603 --> 00:42:49,523
And also in the inbuilt agent
also, you can configure your LLM.

797
00:42:49,953 --> 00:42:54,393
you can either OpenAI or whatever
model you can configure it.

798
00:42:54,693 --> 00:42:56,113
it's a configuration, for us

799
00:42:56,613 --> 00:42:56,933
Bret: Right.

800
00:42:57,433 --> 00:43:02,113
Yeah, picking the model for the agents,
is, is a good thing 'cause we're gonna,

801
00:43:02,143 --> 00:43:04,993
we're, we're-- I got a feeling we're gonna
need to get cheaper models for the, for

802
00:43:04,993 --> 00:43:07,423
the cluster, for the always-on activities.

803
00:43:07,923 --> 00:43:08,243
yeah.

804
00:43:08,473 --> 00:43:12,833
and then, does the agent have visibility
into inter-cell dependency traffic, or

805
00:43:12,833 --> 00:43:18,343
is it context window completely blinded
to anything outside its assigned project?

806
00:43:18,843 --> 00:43:22,913
Lakmal: i-it's depending on the different
agent interact with, different contexts.

807
00:43:22,913 --> 00:43:28,633
So for example, say, in this case, SRE
agent, when that troubleshooting, it

808
00:43:28,803 --> 00:43:33,423
can, go beyond the one project, because
some component will interact with the

809
00:43:33,423 --> 00:43:34,923
other component within other project.

810
00:43:35,283 --> 00:43:39,083
So, so if there are interaction,
this agent can look at, what

811
00:43:39,093 --> 00:43:41,763
happening in the other, other
component, in the other project.

812
00:43:42,203 --> 00:43:47,283
So it's b-based on the context that agent
are interacting with, they can go beyond

813
00:43:47,293 --> 00:43:49,153
the single project or multiple project

814
00:43:49,653 --> 00:43:49,833
Bret: Right.

815
00:43:49,933 --> 00:43:50,333
Okay.

816
00:43:50,833 --> 00:43:54,733
And just to be clear on, the scope of
this thing, it doesn't appear like you're

817
00:43:54,733 --> 00:44:00,203
trying to boil the ocean here, where
OpenChoreo is the single control plane

818
00:44:00,213 --> 00:44:04,343
for AWS, for GCP, for all the other
things that we might have to manage.

819
00:44:04,403 --> 00:44:07,123
it, it's trying to remain
Kubernetes focused, right?

820
00:44:07,123 --> 00:44:11,373
So, like, the lowest layer in our
infrastructure stack is, I guess m-

821
00:44:11,693 --> 00:44:15,753
maybe it could possibly get some of the
technically OS level stuff underneath

822
00:44:15,753 --> 00:44:18,863
Kubernetes, but that's, that feels like
that's the s- the dropping off point,

823
00:44:18,863 --> 00:44:20,733
'cause I don't see, clouds listed in here.

824
00:44:21,233 --> 00:44:21,643
Lakmal: Yeah.

825
00:44:21,693 --> 00:44:23,703
we have, we are running
on top of Kubernetes.

826
00:44:23,723 --> 00:44:25,713
We are not even managing the
Kubernetes with OpenChoreo.

827
00:44:26,743 --> 00:44:30,843
we, or we build on top of the
Kubernetes, so you can run

828
00:44:30,853 --> 00:44:35,513
OpenChoreo on E- EKS or EKS, but
we are not managing the EKS or EKS.

829
00:44:35,523 --> 00:44:37,323
So that how we architect.

830
00:44:37,733 --> 00:44:42,523
But, OpenChoreo has this resource
abstraction where you can manage the

831
00:44:42,543 --> 00:44:44,473
cloud resources, within the OpenChoreo.

832
00:44:45,363 --> 00:44:48,023
So we have integrated with,
Crossplane at the moment.

833
00:44:48,253 --> 00:44:52,563
So OpenChoreo control plane can in-
talk with the Crossplane integration

834
00:44:52,933 --> 00:44:57,983
and via the Crossplane, it can create
a, say, S3 bucket in AWS, and it can,

835
00:44:58,073 --> 00:44:59,983
do the lifecycle manager for S3 bucket.

836
00:45:00,033 --> 00:45:05,743
So it provide a single, unified
control plane to manage it, but,

837
00:45:05,913 --> 00:45:09,443
it's up to the users if they want
to, use, manage in different way.

838
00:45:09,473 --> 00:45:10,533
That's totally up to the users

839
00:45:10,773 --> 00:45:11,083
Sameera: Yeah.

840
00:45:11,573 --> 00:45:15,153
Just to add to that and then, Bret
you saw like multiple planes, right?

841
00:45:15,163 --> 00:45:17,383
Control plane, data plane,
observability plane.

842
00:45:17,883 --> 00:45:21,663
And you can run each plane in its
own Kubernetes cluster, or you

843
00:45:21,663 --> 00:45:23,473
can run all planes in one cluster.

844
00:45:23,903 --> 00:45:28,263
And you can run your control plane
locally, you can run data plane in AWS.

845
00:45:28,263 --> 00:45:32,903
So it's, as Lakmal said, it's, the
way it's architected is so it's,

846
00:45:32,963 --> 00:45:35,113
you can configure, the way you want.

847
00:45:35,613 --> 00:45:40,223
And then like, like for example, if the
data plane is in AWS and control plane is

848
00:45:40,233 --> 00:45:44,853
somewhere else, you don't have to expose
the Kubernetes API server to the internet.

849
00:45:45,353 --> 00:45:49,583
There, there's a certain agent running
in the, in the data plane that creates an

850
00:45:49,593 --> 00:45:51,783
outbound connection to the control plane.

851
00:45:52,283 --> 00:45:54,403
that's sort of the standard these days

852
00:45:54,845 --> 00:45:55,175
Bret: Right.

853
00:45:55,395 --> 00:45:59,005
So yeah, basically, if you're gonna use
this to help manage something, it needs

854
00:45:59,005 --> 00:46:02,125
to be something running in Kubernetes,
and it needs to be probably like a s-

855
00:46:02,535 --> 00:46:06,015
something around the CNCF ecosystem
of tooling or something like that.

856
00:46:06,015 --> 00:46:10,035
So this isn't trying to replace
Terraform or, you know, control my

857
00:46:10,035 --> 00:46:11,935
cloud formation, and stuff like that.

858
00:46:11,935 --> 00:46:14,835
Yeah, yeah, or run my, my,
my other infrastructure like

859
00:46:14,995 --> 00:46:15,955
Vercel or something like that.

860
00:46:15,955 --> 00:46:16,135
Yeah.

861
00:46:16,185 --> 00:46:19,265
that gives me a nice boundary because
like when we talk about the future of

862
00:46:19,265 --> 00:46:23,375
what it's m- means to be an SRE, DevOps
platform engineer, whatever, like where

863
00:46:23,375 --> 00:46:25,025
do the edges of these tools exist?

864
00:46:25,045 --> 00:46:29,265
Because, sure, I can manage everything
from Claude Code in theory at this point,

865
00:46:29,265 --> 00:46:33,355
but, it probably, I probably need very
scoped things in order to keep it in line.

866
00:46:33,685 --> 00:46:36,945
And having this thing w- well
defined is like it runs on top of

867
00:46:36,945 --> 00:46:39,635
Kubernetes, so things that you can
do in Kubernetes, it can help with.

868
00:46:39,655 --> 00:46:43,895
But don't-- you maybe can shoehorn
in a bunch of things like, for AWS or

869
00:46:43,895 --> 00:46:47,305
whatever, but maybe it's not the right
tool to do everything all in one place.

870
00:46:47,305 --> 00:46:50,105
'Cause obviously there's a ton of
context outside of Kubernetes that

871
00:46:50,105 --> 00:46:51,805
it would probably need and, yeah.

872
00:46:51,885 --> 00:46:53,385
So there's probably other tools for that.

873
00:46:53,385 --> 00:46:55,795
At the end of the day, we're gonna have
dozens of agents, I feel like, and we're

874
00:46:55,795 --> 00:46:58,715
just gonna, we're gonna have an agent
management plane where we're all just

875
00:46:58,715 --> 00:47:00,835
staring at agent configs and skill files.

876
00:47:00,885 --> 00:47:02,475
And that's like, that's our new job.

877
00:47:02,775 --> 00:47:03,495
More markdown.

878
00:47:03,965 --> 00:47:05,375
So how can people get started?

879
00:47:05,415 --> 00:47:11,575
They go to openChoreo.dev
and or is this a Helm chart?

880
00:47:11,625 --> 00:47:13,375
Like how do we get started
with implementing this?

881
00:47:13,375 --> 00:47:16,835
We, well, step one, you gotta have
Kubernetes some- running somewhere, right?

882
00:47:16,835 --> 00:47:20,215
Sameera: So yeah, if you, if you
go to OpenChoreo dev, documentation

883
00:47:20,215 --> 00:47:23,535
page, there are m- couple of
ways for you to get started.

884
00:47:23,605 --> 00:47:27,285
First thing, if you wanna just try
out OpenChoreo, so we have this quick

885
00:47:27,285 --> 00:47:32,365
start guide that'll basically… The
quick start guide that'll basically…

886
00:47:32,415 --> 00:47:33,625
You just need Docker for that.

887
00:47:34,125 --> 00:47:36,075
So Docker and Kubernetes,
we will do the, we will…

888
00:47:36,395 --> 00:47:40,185
There's one command that'll
install Kubernetes in Docker, and

889
00:47:40,185 --> 00:47:41,545
then that'll install OpenChoreo.

890
00:47:41,545 --> 00:47:47,245
So you get a… Once it is done, you
get a UI, you get MCP access, all that.

891
00:47:47,325 --> 00:47:48,665
That's just 10 minutes.

892
00:47:49,165 --> 00:47:52,145
won't, pollute your local
environment in that way.

893
00:47:52,145 --> 00:47:54,085
You can just destroy
it after that is done.

894
00:47:54,505 --> 00:47:57,795
The other option is you need to
have Kubernetes cluster on your

895
00:47:57,795 --> 00:48:00,025
local machine, install OpenChoreo.

896
00:48:00,055 --> 00:48:04,755
There are, then the third option is
install OpenChoreo in cloud environment.

897
00:48:05,255 --> 00:48:09,195
That's so, that's sort of the way how
we have structured getting started.

898
00:48:09,695 --> 00:48:11,505
Bret: Okay, so it's got
some persistence to it.

899
00:48:11,505 --> 00:48:14,065
I'm assuming this thing, does
this thing have, like, databases

900
00:48:14,065 --> 00:48:16,205
as a part of its deployment?

901
00:48:16,225 --> 00:48:19,175
Does it have, like, a Redis or,
like, what-- When we talk about the

902
00:48:19,175 --> 00:48:23,885
infrastructure inside of OpenChoreo,
I mean, we've got a web portal, we've

903
00:48:23,885 --> 00:48:27,905
got some, obviously some MCP endpoints,
we've got some system components based

904
00:48:27,905 --> 00:48:29,275
on other things you're installing.

905
00:48:29,595 --> 00:48:32,145
what's that persistence layer look
like for us that are gonna have

906
00:48:32,145 --> 00:48:33,895
to deploy this on our clusters?

907
00:48:34,395 --> 00:48:37,675
Sameera: for the, I think for the whole
OpenChoreo control plan, I would say

908
00:48:37,875 --> 00:48:42,475
right now the main persistent layer
is ETCD, whatever the Kubernetes use.

909
00:48:42,975 --> 00:48:46,845
For Backstage, you can configure,
Postgres or any other database

910
00:48:46,845 --> 00:48:48,715
that Backstage, recommends.

911
00:48:49,215 --> 00:48:50,665
Right now it uses… Yeah.

912
00:48:50,665 --> 00:48:51,285
Yeah.

913
00:48:51,285 --> 00:48:54,645
I think apart from that,
there's no persistent,

914
00:48:54,839 --> 00:48:59,679
Lakmal: Also, for a, like a, the
SRE agent, you can configure, it's

915
00:48:59,679 --> 00:49:02,989
coming with SQLite, for the saving
the incident and providing the

916
00:49:02,989 --> 00:49:05,069
context in the future incidents.

917
00:49:05,359 --> 00:49:08,669
But you can configure a Post- a
Postgres or any other database.

918
00:49:09,169 --> 00:49:09,469
Bret: Yeah.

919
00:49:09,669 --> 00:49:13,099
I was actually wondering too, I was
trying to imagine, this thing is doing

920
00:49:13,109 --> 00:49:16,319
things, these agents are doing things,
and we probably want a history of that.

921
00:49:16,339 --> 00:49:20,033
Is this thing able to, log into
your existing… Like, is it logging

922
00:49:20,033 --> 00:49:22,843
through Kubernetes to your existing…
So it's essentially creating more

923
00:49:23,203 --> 00:49:27,593
m- monitoring and logging data in
your infrastructure by the act of it

924
00:49:27,593 --> 00:49:28,643
just being there and doing things.

925
00:49:28,643 --> 00:49:31,113
Is that, is that where I would
go to see, hey, what does my

926
00:49:31,113 --> 00:49:32,743
agent do in the last 24 hours?

927
00:49:32,743 --> 00:49:35,623
Is it something like I would
just look at my normal monitoring

928
00:49:35,623 --> 00:49:36,683
and logging platform for that?

929
00:49:37,089 --> 00:49:37,509
Lakmal: Yes.

930
00:49:37,579 --> 00:49:41,629
it will do all the audit logs, to the, log
itself like we are using, depending on the

931
00:49:41,629 --> 00:49:45,449
lo- log module, it can be, OpenSearch with
a different index with, for the, audit

932
00:49:45,449 --> 00:49:47,359
logs, what agent do, whether human do.

933
00:49:47,619 --> 00:49:49,249
Everything is tracked,
within the logs itself

934
00:49:50,637 --> 00:49:51,007
Bret: Okay.

935
00:49:51,437 --> 00:49:55,597
and all the data, about the
infrastructure, are the agents

936
00:49:55,597 --> 00:49:56,887
just pulling that real time?

937
00:49:57,237 --> 00:50:01,427
Or do we, do you have to, deal
with caching, you know, infrastruc-

938
00:50:01,447 --> 00:50:04,467
infrastructure graphs or any… Do
you have to do anything like that and

939
00:50:04,467 --> 00:50:06,317
to optimize in the OpenChoreo layer?

940
00:50:06,777 --> 00:50:07,027
Lakmal: Yeah.

941
00:50:07,127 --> 00:50:08,697
At the moment, it's a real time.

942
00:50:08,767 --> 00:50:11,287
we are not using any, VectorDB
or something like that, for the

943
00:50:11,287 --> 00:50:12,447
caching or something like that.

944
00:50:12,737 --> 00:50:15,837
At the moment, it's, real time
pulling the data, but we give the

945
00:50:15,847 --> 00:50:19,437
time interval, the context saying,
"Okay, within this time interval, you

946
00:50:19,437 --> 00:50:23,767
have to pull the logs, matrices." it
will just look in that interval and,

947
00:50:23,967 --> 00:50:26,317
get the, all the data to troubleshoot

948
00:50:26,817 --> 00:50:27,037
Bret: Right.

949
00:50:27,037 --> 00:50:30,327
So it's, so it, once it sees an event,
it already knows exactly the second

950
00:50:30,337 --> 00:50:34,577
that event happened, so then it can
limit itself to th- so that you're not

951
00:50:34,577 --> 00:50:37,537
burning a bunch of tokens by boiling
the ocean and scanning every log on

952
00:50:38,037 --> 00:50:38,357
Lakmal: Yeah.

953
00:50:38,629 --> 00:50:39,139
Bret: infinity.

954
00:50:39,149 --> 00:50:39,419
Okay.

955
00:50:39,437 --> 00:50:39,767
Lakmal: the idea

956
00:50:40,259 --> 00:50:40,539
Bret: Yeah.

957
00:50:40,539 --> 00:50:40,989
Perfect.

958
00:50:41,159 --> 00:50:43,909
is it, does it need to look
at, like, Grafana graphs?

959
00:50:43,919 --> 00:50:48,619
Like, or is it just simply doing
prom queries and just getting

960
00:50:48,619 --> 00:50:49,799
that data real time as well?

961
00:50:50,299 --> 00:50:53,319
Lakmal: It's the data to the,
observability MCP server.

962
00:50:53,359 --> 00:50:55,879
It's, just going to the MC- MCP servers

963
00:50:56,379 --> 00:50:56,749
Bret: Yeah.

964
00:50:57,249 --> 00:50:58,209
RIP Grafana.

965
00:50:58,469 --> 00:50:58,719
Sameera: Yeah.

966
00:50:59,219 --> 00:50:59,559
Bret: Yeah.

967
00:50:59,659 --> 00:51:00,399
Oh, sorry, what would you say?

968
00:51:00,399 --> 00:51:01,199
I was talking over top of you

969
00:51:01,699 --> 00:51:05,699
Sameera: No, this is directly from,
observability MPV service talk to

970
00:51:05,699 --> 00:51:08,439
the OpenSearch and get the data.

971
00:51:08,843 --> 00:51:09,193
Bret: Yeah.

972
00:51:09,253 --> 00:51:09,603
Yeah, yeah.

973
00:51:09,903 --> 00:51:12,293
Yeah, so that it's a little
bit simpler than it having to

974
00:51:12,293 --> 00:51:15,953
constantly, figure out everything
and store it as some sort of cache.

975
00:51:16,053 --> 00:51:18,563
Which, I mean, in theory, that would
make the agent faster so that it didn't

976
00:51:18,563 --> 00:51:21,563
have to query everything itself when you
start to work with it, but it also adds

977
00:51:21,563 --> 00:51:25,833
a lot of complexity and, and resource
utilization, which gets back to the

978
00:51:25,843 --> 00:51:29,633
point of at some point, everybody has
had that infrastructure where they

979
00:51:29,633 --> 00:51:33,693
realize they, they have a, a cluster
that has more resources used for the

980
00:51:33,693 --> 00:51:37,233
infrastructure than the actual apps
themselves, which, you know, has happened.

981
00:51:37,293 --> 00:51:39,783
sometimes when we have small clusters
and we're getting started, like we are

982
00:51:39,783 --> 00:51:43,193
like, "Yeah, you know, the, the app
only costs $100 a month to run, but

983
00:51:43,193 --> 00:51:44,903
the infrastructure costs 10,000 a day."

984
00:51:45,947 --> 00:51:46,537
Lakmal: That's true.

985
00:51:46,963 --> 00:51:47,363
Bret: yeah.

986
00:51:47,803 --> 00:51:48,853
Well, this has been very cool.

987
00:51:48,893 --> 00:51:51,423
we could honestly, I could talk to you
for another hour about this because

988
00:51:51,423 --> 00:51:54,573
I'm really, I'm really interested in
the patterns and the, and the ar- the

989
00:51:54,623 --> 00:51:57,343
architecture design that you've learned,
because I think these, these are things

990
00:51:57,343 --> 00:52:00,513
that we're gonna have to do the same
thing for our cloud infrastructure.

991
00:52:00,513 --> 00:52:02,733
We're gonna have to do the same
thing for our line of business apps.

992
00:52:02,733 --> 00:52:05,923
We're gonna have to s- figure out how
to give these agents under- a deeper

993
00:52:05,923 --> 00:52:10,063
understanding of that infrastructure
so that we can depend on them more and

994
00:52:10,063 --> 00:52:14,273
rely less on the human, the human tribal
knowledge that we all have about how

995
00:52:14,273 --> 00:52:18,083
these systems are put together and where
all the bodies are buried and where all

996
00:52:18,093 --> 00:52:21,373
the, My, the friends, my friends of mine,
they call it the sins of the data center.

997
00:52:21,373 --> 00:52:23,603
Where are the, where are the
sins of the data center at?

998
00:52:23,613 --> 00:52:25,723
And this thing is gonna
have to know all that.

999
00:52:25,773 --> 00:52:29,023
this thing is really, when I say that,
I mean like dozens of agents that all

1000
00:52:29,033 --> 00:52:30,913
have certain context and certain control.

1001
00:52:31,313 --> 00:52:34,463
but it all kind of feels like it's coming
back to this still, this, Viktor Farcic,

1002
00:52:34,513 --> 00:52:38,173
who runs the DevOps Toolkit channel,
a friend of mine, he talks about that,

1003
00:52:38,173 --> 00:52:41,783
like to me, to him, Claude Code is the
center of the universe and he manages

1004
00:52:41,783 --> 00:52:45,123
everything through it, and that anybody
who's creating a project that isn't

1005
00:52:45,123 --> 00:52:50,853
expected to be local harness first as my
interface is creating an outdated project.

1006
00:52:50,853 --> 00:52:55,473
So this kind of feels like it's, this,
is doing exactly what his, he was

1007
00:52:55,633 --> 00:52:59,783
predicting over the last year, which is,
you know, the harness is my gateway to

1008
00:52:59,873 --> 00:53:02,953
all this infrastructure, and everything
else needs to be there to help me

1009
00:53:02,953 --> 00:53:05,093
be like local agent harness first.

1010
00:53:05,473 --> 00:53:07,983
and it's pretty cool to see
that, to see that take place.

1011
00:53:07,993 --> 00:53:11,103
all right, so people get started
at the openChoreo.dev website, and

1012
00:53:11,103 --> 00:53:13,223
then I think you're on, LinkedIn.

1013
00:53:13,223 --> 00:53:16,253
I'm trying to think what the
project is on LinkedIn and X.

1014
00:53:16,293 --> 00:53:16,603
Lakmal: Yeah.

1015
00:53:16,773 --> 00:53:20,763
We have the X and LinkedIn
pages, and also we have the Slack

1016
00:53:20,783 --> 00:53:22,963
channel, CNCF Slack channel.

1017
00:53:23,373 --> 00:53:25,423
we were actively, engaging with there

1018
00:53:25,923 --> 00:53:26,263
Bret: Yes,

1019
00:53:26,275 --> 00:53:28,035
Sameera: And we use
GitHub discussions a lot.

1020
00:53:28,145 --> 00:53:30,225
If you want to engage
with us, we'll be there.

1021
00:53:30,623 --> 00:53:32,083
Bret: I love to, I love
GitHub discussions.

1022
00:53:32,083 --> 00:53:34,773
I d- wish they were used
more, r- rather than issues.

1023
00:53:34,783 --> 00:53:37,013
Like, I feel like a lot of things just
need to start in discussions before they

1024
00:53:37,013 --> 00:53:39,783
go to issues, and maybe some projects
do that now, where they not, they don't

1025
00:53:39,783 --> 00:53:41,383
even let you post things in issues.

1026
00:53:41,383 --> 00:53:43,163
You have to, you have to
start the discussions first.

1027
00:53:43,563 --> 00:53:45,753
yay, AI ruining open source for us.

1028
00:53:45,823 --> 00:53:46,353
at least for now.

1029
00:53:46,353 --> 00:53:47,043
We're figuring it out.

1030
00:53:47,273 --> 00:53:48,933
thank you both so much for being here.

1031
00:53:48,983 --> 00:53:52,793
you can follow the project, like s- we
said, on LinkedIn or on X or, join the

1032
00:53:52,793 --> 00:53:56,503
Slack and the… Is it the, is it the
Kubernetes Slack or the CNCF Slack?

1033
00:53:57,003 --> 00:53:57,913
Lakmal: CSCF lab

1034
00:53:58,245 --> 00:53:58,745
Bret: CNCF

1035
00:53:59,057 --> 00:54:01,917
Sameera: Slack OpenChoreo
channel, I would say.

1036
00:54:02,075 --> 00:54:02,435
Bret: Yeah.

1037
00:54:02,635 --> 00:54:02,955
Okay.

1038
00:54:03,205 --> 00:54:06,255
I'm in both, and I can never remember
which projects are in which and,

1039
00:54:06,265 --> 00:54:07,465
or if the Kubernetes… Yeah.

1040
00:54:07,805 --> 00:54:09,145
So it's in the CNCF Slack.

1041
00:54:09,165 --> 00:54:10,805
You can, probably just
Google that and find that.

1042
00:54:10,875 --> 00:54:11,895
tell your agent to sign you up.

1043
00:54:11,905 --> 00:54:13,305
Like, don't, you know,
don't go do it yourself.

1044
00:54:13,625 --> 00:54:16,525
thank you so much, Lakmal and Sameera,
for being here, I'm looking forward

1045
00:54:16,525 --> 00:54:17,705
to seeing what's next in the project.

1046
00:54:17,715 --> 00:54:18,285
last quick thing.

1047
00:54:18,285 --> 00:54:18,825
What's next?

1048
00:54:18,835 --> 00:54:22,695
What's, what big PRs are coming down the
pike since we're talking open source here?

1049
00:54:23,195 --> 00:54:23,815
Lakmal: More agents?

1050
00:54:24,699 --> 00:54:25,549
Bret: More agents.

1051
00:54:25,672 --> 00:54:26,722
Could-- I could have guessed it.

1052
00:54:26,732 --> 00:54:27,462
I could have guessed it.

1053
00:54:27,613 --> 00:54:28,413
Sameera: All about AI.

1054
00:54:28,913 --> 00:54:29,263
Bret: Yeah.

1055
00:54:29,743 --> 00:54:31,303
More, more of the AI overlords.

1056
00:54:31,313 --> 00:54:31,593
All right.

1057
00:54:31,593 --> 00:54:32,523
Thank you so much for being here.

1058
00:54:32,563 --> 00:54:34,853
thanks for everybody in chat
for being with us, and we'll

1059
00:54:34,853 --> 00:54:35,533
see you in the next one.

1060
00:54:35,693 --> 00:54:36,103
Bye, everybody.

1061
00:54:36,323 --> 00:54:37,343
Thanks so much for watching.

1062
00:54:37,553 --> 00:54:38,333
I'll see you in the next one.