Tariq Islam: With an interest first, right? Yes.
Jamie Duncan: Thanks for joining us joining us today on episode
10 of the K files. My name is Jamie Duncan. I'm a customer
engineer at Google, with me as always, is john Osborne. I run
this as john Osborne, chief architect for Red Hat, public
sector. And tark Islam. Everyone, this is Tarik Islam,
sales engineering manager at Google. Um, we've been having a
discussion for about 10 minutes. Now before we click the Record
button. We know what we want to talk about, but we're not 100%
sure what to call it.
We've called it get ops and it's not quite get Ops, we've called
it ci CD. And it's not quite that. JOHN, you said the CN CF
has a name on application development and delivery,
something like that.
John Osborne: Yeah, so Helm is a is a CNC f project that
graduated this year. And they have it filed under application
definition. And deployment, I think, okay,
Jamie Duncan: but that's your target quote was immediately
hated it. Yes. Like
Tariq Islam: that right under thanks. I hated
John Osborne: definition and development. That's what they
have it. Mission development, probably
Jamie Duncan: the most accurate definition tark throughout was
called up CD. So Ops, continuous delivery. Really, what we're
going to spend about we're gonna spend a little time talking
about is how you once your cluster is deployed, but not
doing the actual development of the application. What happens in
the middle, what tools are there out there to configure your
cluster to set up all those security setup all the policies
to set up all the configurations and the bits and the bytes, and
get your cluster ready for applications and then deploy and
manage those application life cycles?
Tariq Islam: So it's interesting, you mentioned it
that way, Jamie? Because it just kind of occurred to me that this
is actually how we see a lot of organizations adopt things
across the timeline. They Oh, it always starts with Okay, I'm
gonna get my cluster stood up. But then how do I actually like
manage this thing, day to ops is maybe synonymous with this
topic, a little bit, right? cluster configuration,
environment configuration, what does all that look like? And
then they start worrying about creating a harness for for
application delivery.
John Osborne: And and maybe that that'll be the segue for us and
to see ICD? It's been probably, to me, like the most fragmented
space, right? I mean, we're like six years into Kubernetes. And
there's been a ton of these projects that have just kind of
been hot for like a year, and then he never really heard it
from them again, right?
Jamie Duncan: I mean, he was what, two and a half years ago,
we we went over to tartes office in Northern Virginia, and looked
at what case on it and
John Osborne: chase on it.
Jamie Duncan: json at ham sandwich sauna. I mean, there
were a ton of them that we looked at, and I haven't heard
of most of them. Since that day, when we stole free lunch from
Google.
Tariq Islam: I actually forgot it existed.
Unknown: Exactly.
Tariq Islam: Wow, man, it's been a while. I mean, this ecosystem
is full like it's kind of defined as in the beginning
there was Helm in Helm was pretty okay. Well, it fill the
gap. It I mean, it it filled it filled a, an implicit need for
any sis ops team, any sis ops team worth, it's worth its
weight, right? If I'm gonna adopt Kubernetes, I really I
need to be able to define define the gates, I need to define the
guardrails and Helm did does a great job at that, of that, at
least at some scale, but perhaps not at scale. And maybe we can
talk about that today. But it definitely filled a need. I
forgot how wild Kubernetes was in the early days until I went
back to this episode and started looking at Helm to and like all
this stuff came back like what Helm was first released, there
was no our back in Kubernetes at all, and like and then how
maintains like, this whole state, in its its own outside of
Kubernetes, because there was no CR DS or anything like that.
And, and everything used to run his route. And, you know, all
the Docker images would mount to the home and the battles that
were fought. Yeah, you know, so. So let's do this. Let's, let's,
uh, let's define Helm real quick. For the folks listening,
just, you know, for good podcast hygiene here. I'll take, I'll
take a crack at it, it's probably gonna be half half
wrong. What's gonna be half right?
It'll be half right. I've always seen Helm as as, as a
templating. approach to to. I almost have to say Git ops.
Again, I don't want to overload that term.
John Osborne: package management, maybe?
Tariq Islam: Yes, exactly. It's application package, not
application pack. Because remember treating your
applications in a packaged way. But it's, it's it's a, it's a
templating. It's a templating tool effectively. I mean, it's
almost like a DSL. And it's very specific. And it is important to
note by the way that that Helm is. It's It's different from
customize. I'm introducing that term early on, because as soon
as you Google Helm or customize, in your, in the Google quick
results, you actually see, like one of the first results is Helm
versus customize. So we'll talk about customize as well. But
there seems to be a bit of a not a battle going on. But folks are
wondering which one to use when and why hounding the first one
to Market. But templating is how I would have I would describe
it,
John Osborne: that's how I think of it as I mean, to me, like my
mental map, our model is I still kind of think of it like Jinja
templates in Python, but that's probably shortchanging some of
some of this. Yep. Similar capabilities. But
Jamie Duncan: it really it feels a lot like To me it feels like
Ansible for Kubernetes.
Tariq Islam: Is it though, I'm channeling my, my Thor right
now.
Jamie Duncan: That's what. And as I was saying that I five
seconds previously, because I, you know, in my brain out my
mouth, I wonder if I feel that way, because that's when I
really learned both of those tools. I learned them sort of
beside one another. Or if there's a relationships there, I
think there's at least some relationships there. Because
john, you know, explicitly called out Jinja templates,
which is how you do templates in Ansible.
Unknown: Mm hmm.
Jamie Duncan: there on the surface, there are at least some
similarities. But what Ansible is, at the end of the day is
largely a templating engine. So they have
Tariq Islam: maybe a right that actually, if you're going by
that description, because that's how I mean, that's how that's
how we see helm. Now. I mean, that being said, though, I think
there's there's a discussion happening right now around
whether whether a, an ops team that's managing this Kubernetes
platform should use Helm or customize is the room to use
both. Maybe I'll nip that last one in the bud right now and say
using both is just going to add way too much complexity. But I
think it's a good discussion. Because if you if you look at
the the structure of helm, I mean, it's come a long way in
terms of its architecture as well. They look at security
concerns, initially, you had client side, server side
components, and now you don't, they've done a great job of
locking certain things down and addressing the security concerns
that were
John Osborne: that were there early on. If you were in the in
the early days, you know, they have these in the old version of
Helm a this thing called tiller, which basically, yeah, it's
mashed up all the template was basically was the templating
engine and would just apply everything to the Kubernetes
API, there was no security because it didn't exist in
Kubernetes. But do you actually remember the beginning? And I
forgot about this until I started going back and look at
some wild stuff, but it would actually just deploy everything
in the coop system namespace.
Jamie Duncan: That's all it would do.
John Osborne: Well, that was like the default namespace it
would deploy to. So yeah, so he was not iterating. And all of a
sudden, you're just not really, yeah. Which is a really good way
to like FUBAR your cluster, but I do like I do like helm. It did
fill a gap in the beginning. But if you also look at a lot of the
tools that have been around, it's the only one, like,
customize as much as someone new right, like out of the first
generation of tools. It's the only way to hell yeah, still
here.
Tariq Islam: So john, and your and so if I were to ask you the
question, I don't think we've addressed this for for the, for
the folks listening, what what do I use Helm for?
John Osborne: I always, so two parts that I always felt like,
especially in the early days of Kubernetes, but still probably
to this day, one of the big things about it was actually the
content around it. So there's like a Helm chart that exists
for almost anything. So if you want to go install MySQL on
Kubernetes, or, or,
you know, some Apache project or, or WordPress, because every
example is WordPress, right? You can just go you can just type
Helm install, and it'll pull in a chart that has that for you.
Now, there's of course, like, you know, there's security
concerns around that. There's, there's ways to do that more
securely, but to get up and running the content around it,
almost like Docker, right? Like if you think about when Docker
was really big. In the beginning, it was more. There's
all these based, yes, they did everything with API, all that
stuff. But I think a big reason was they have the ecosystem,
right, and Cal has the ecosystem. But I don't think it
works that well for individual use cases. But it does work well
for teams that are going to gate. At least that's where I
start. See it. And that's where I see people using it as more
like, you know, ops teams or some, some team that's going to
gate resources to a developer, but they're going to give them
access to certain variables, then you can, they can give them
Helm charts that they can override certain things, but not
certain other things. I also see kind of, sometimes in the
enterprise teams will have like, they'll allow, say, like five
variations on let's use like Tomcat as a simple example. But
they're going to allow you five, five variations of Tomcat rate
and Helm is a kind of a good way to lock down Tomcat, but just
give you the five variations, and you can kind of pick and
choose with the templating.
Tariq Islam: Yeah, and so that's, that's where I feel like
Helm starts to come apart a bit, because of all the possible
variations that you start running into as an organization.
You know, if I've got five variations, you know, in a
couple years, I might end up becoming 15 different
variations. And I think that's where the discussion with
between Helm and customize comes into play. Do I want to do like
templating till till I die? Or do I want to actually start
leveraging an overlay based system? Like the one customize
represents? I mean, we haven't we haven't even defined
customize. Yep. But I think that's that's the question.
John Osborne: Do you want to define customers?
Tariq Islam: Yeah, so so customize. It's not it's not
templating? It's primarily it's, it isn't work, for lack of a
better term, an overlay engine, right. And the unique thing
about customize is that it's actually baked into the cube
CTL. See, ally. So you can use the dash k flag to use it. from
an engineering standpoint, it's it's maintained by, you know,
core Kubernetes, whereas Helm is, is maintained by by a third
party, said, distributors, what
John Osborne: is the third? I mean, it seems mostly IBM and
Microsoft, from what I've seen, but
Tariq Islam: yeah, that's what I've seen as well. That's what I
mean by third party. I'm not saying that it's outside the
community. But the fact that customize is part of you know,
the coop CTL. See, Li like the that actual flow, just kind of
intrinsically brings it closer to the Kubernetes platform. And
I'm, I've always been a bit of a purist slash, minimalist slash,
whatever, just, I like that type of thing, right? Just bring me
up, keep me as close to Kubernetes as you as you
possibly can. And I'm happy.
John Osborne: Tell me if my mental map is just horrible, but
in my mind, I kind of think of customizes. Like, if I was
working locally, and sort of scripting things out with sed
and a bunch of other Linux command line tools, eventually,
when I that mature it, I get something like customize.
Tariq Islam: That's about right, man.
Jamie Duncan: Yeah, that's, yeah, you're certainly in the
right neighborhood, if not at the right front door. It can
turn on
John Osborne: their eyes.
Jamie Duncan: Right, like Tarik said there, you can overlay. So
you can you have a directory called base. And inside base are
all of the objects that you want to have created when you run
this customize script. So if you want to create a namespace,
deployment objects, Ingress objects, whatever, and you can
parameterize those. So in that regard, it's not drastically
different than helm. And they even look a little alike. So you
have this base directory, and then everything you run, pull
starts at that base directory. But then you can overlay
different things on top of that. So you can also have a directory
called production or a directory called development. And you can
populate those parameters with directory with dev values, or
prod values or your own custom values. And then you can also
have parameters files, where you're just filling things in,
or where you override a specific thing. It gets to the same
place, my biggest, the reason I use customize more than I use
Helm is that I keep everything in the repository. The biggest
problem I have with Helm is that I have to pull in, I have to do
Helm repo add, and then go add the repository for WordPress
that contains the helm charts, or for whatever I'm installing.
And then I have to turn around and tell it to go update those
like, like a package manager, like using Yum, or apt. And then
they're stored off in some library folder. And they're not
a part of my repository, where is customize inside the
Customize library itself. It just understands what a
namespace, what that yamo looks like. It understands all these
different things. And I can do other cool things like for
secrets, I can actually just have it I can feed it two or
three pieces of information and have it generate a secret for
me. You do a lot of really cool little shortcut, things like
that inside customize. And it's all inside my repo. I don't have
to pull another another chunk of code down and put like, like
subscribing to a repository.
Tariq Islam: And I think that's part of the power right for an
organization to be able to start adopting a thing like, like get
ups, right? I mean, if you're keeping everything in
repository, it kind of lends itself towards that. So
immediately, I think it becomes a lot more scalable. Now, for
me, I still am a fan of helm. Because it I mean, if you've
installed this do in the last year, you probably use the helm
install or the helm chart for it. I love that right? I love
being able to just go to Helm chart and install something,
it's pre configured pre package ready to rock. That's been
great. But But to your point, Jamie, it's I lean more towards
towards customize for for things that I want to break apart and
put back together for my own purposes,
John Osborne: it does seem like in terms of ci CD usage, that I
see more customized now, in terms of, you know, someone's
going to write some code or it's going to iterate I know in the
Git ops model, like the default projects like Argo and flux,
like most of their examples, use customized as well. I still see
how I'm filling a need. In terms of the the teams and the people
in that handoff, do you see customize being used for those
cases as well? or?
Unknown: Yeah,
Jamie Duncan: Yeah, I do. And because of that overlay idea
that I can, I have a folder that contains all of the uniqueness
that represents my production environment. And it's just
labeled production, or a dev a dev environment or, and I can
split it and slice it and dice it however I want. And it's
going to take those objects in, in my base folder, my base
directory, and it's going to add or subtract from them, as per
the instructions in those in the customized folders. So I can, I
can get to that same place. And I can do all of the things that
you're supposed to do inside there. And it's all and kind of
interesting, when you're talking about where it's the default for
ci CD. And I think it's just because it's easier is because
it's part of coop CTL when I install coop CTL I install
customize all of your container images that do all of those
builds have coop CTL in them because they have to, as so and
so I just get all of that functionality out of the box.
Whereas if I'm using helm, every time I run that build my
container image has to grab the repo and pull the repo down and
do all of the things you have to do to make him work. And that's
time consuming at scale when I'm doing lots of build today.
John Osborne: So how am I think one of the reasons why Helm is
so popular just has this massive ecosystem of existing charts,
right? I mean, is there ways to plug those charts in to
customize or kind of leverage that ecosystem? Or or do you
have to use Helm if you want to leverage all that?
Tariq Islam: You'd have to you'd have to pull apart the the helm
chart a little bit. Because it's in its its its own non k
standard format. It's still YAML. But it's still its own.
That's what I call it. That's why I mentioned it kind of being
its own DSL earlier. Because you really it if you're on Helm
today, you've been on Helm for years and you want to go over to
customize, it's going to be a migration. That's what you're
effectively looking at. Right? It's some form of a migration.
John Osborne: I do like how I customize, it doesn't change the
original YAML that you had. Makes it Yeah, just makes it
easier. What about in production? Right? Like, is it?
Do you think there's benefits to one versus the other? if, you
know, some say some YAML goes astray, right? Like, what's the
Is there a way you can tell inside the annotations or inside
the metadata? How that yamo was constructed in the first place?
Tariq Islam: I don't think that there's any auditing, how do you
unpack that? I know and
Jamie Duncan: I know, customize has like a dry run option. In
fact, the default, yeah, just output YAML. So the way you
actually use customize, you know, the customized command
reads a dot customize file that then you tell it you feed it
those parameters, but by default, it just spits out YAML
and then you actually pipe that into if you're not using coop
CTL dash k. a bad habit that I formed early on and still do is
to run the customized command and then pipe that into coop
CTL.
Tariq Islam: You don't even do the dry run, you just fly by the
seat.
Jamie Duncan: Exactly like you get pipe
John Osborne: live production,
Unknown: exact reference or for the week.
Jamie Duncan: Dry runs for people with SLA.
John Osborne: Well, yeah, and Kubernetes does have some of
that built in with the the last apply configuration annotation
that's in there. Now if you look in I think it's 118. They added
that where you can go see what the previous yamo was before it
got applied.
Jamie Duncan: I don't know there's any way The first time I
saw it.
John Osborne: I don't care for I don't care for it. I saw in the
Git repo that they people complained and they said that
people like it because it provides info but I just feel
like it takes so much space. That to diverge too much, but
Tariq Islam: religious c li best practices.
John Osborne: Yeah. But I didn't know if there's any way to I'm
not it. I'm not expert enough in either of them even though I've
used both them a decent amount, but to actually unpack the how
they were created. So you could see where things went awry.
Jamie Duncan: Yeah, I don't think there is like it unless
you tell it to. So I have significantly like, I'm very
much a pure consumer of helm, where I do exactly what you
said, john, I, you know, I'm reading the instructions on how
to deploy something that I haven't deployed before. And it
says, Go grab the helm chart and run Helm and set these set these
variables. I do exactly. That's, that's pretty much my experience
with helm. Customize, I've gone a fair bit deeper, I'm certainly
not an expert by any stretch, but have, you know, sort of
written some customized schemas and done some work to deploy to
different environments. So I can say pretty confidently, like, in
customized, there's not an inbuilt function to let you do
that. But if, but that idea of everything's a parameter,
anything I want is a parameter. I could add, you know,
annotations and labels and all the things that I would want to
add. to to see any of that information. I don't know that I
like the idea of debugging that way. But that's kind of Yeah, I
know what you're getting to maybe,
John Osborne: yeah, just you know, any other information, you
know, it's, uh, I'm always, I'm always looking for how I can
unpack things, you know, how things gotten to the state, they
got into any any information, there's good.
Tariq Islam: So Helm was great initially, because it filled
that gap, right, it filled that need for, you know, establishing
those guardrails, but I also felt like it violated, you know,
certain principles around DevOps and actually brought, it brought
certain things too far over to the right, I guess. So, you
know, I, I interacted with organizations that had adopted
Helm and suddenly had developers using Helm charts and kind of
overreaching into the infrastructure deployment
process, application deployment process, and it muddied the
waters quite a bit. And it, it actually prevented operations
teams from being able to make certain decisions without, you
know, significantly impacting everybody else around them,
which is kind of the antithesis of why they were trying to do
all of this to begin with. And I found that that customized
somewhat addresses that because it's not customized is just not
something that a developer really can worry about, I guess,
given where customize lives, in the process of creating these
overlays and applying them at a given moment in time,
Jamie Duncan: right, they could do it in on their laptop, they
could you know, the, the customized files are in the
repository. But they couldn't do it in an environment that
mattered because our back because of all that stuff that
didn't exist back in the day, to take care of it. Customize is
able to take advantage of it, I think, as I look at and we kind
of dogged, not dogged him, but we certainly, at least I gave it
a poor connotation when we were talking about all the service
meshes and how hashey corpse console deploys with the helm
chart. And I said it felt kind of like 2005
Tariq Islam: I remember that.
Jamie Duncan: Like that is like that's with a slightly more
intelligent thought on it. I hope customize is taking the
lessons learned from helm. And building. prob, for the reasons
you just said tarak, as well as the the stuff I was talking
about, like where it's, it's easier for it to live in a
repository without any external dependencies. It's taking the
lessons learned from Helm and making it a more cloud native
DevOps friendly get ops friendly, buzzword friendly
tool.
Tariq Islam: Yeah, I just think and this is not to say that Helm
had poor design principles that they certainly don't, they never
did, but I think they fell victim to having to do things
that I think at this point, you know, five years later, we know
that we probably want to leave to some other tool or to some
other thing and doing it some other way. And I think
customises has benefited from the things that Helm had to just
deal with. Right, so Helm is kind of like, you know, back in
my day, right, we had to walk to school and shoes and six foot
snow and work without shoes. It's that type of thing. I just
feel like customized has taken has been able to take advantage
of of just being that next iteration, I guess. I mean,
maybe that's the conclusion that we're kind of alluding to here
between the two. But that's not also not to say that you
shouldn't use helm. Can we? Can I Can any of us say that, that
there isn't a use case today? Where I
John Osborne: think I think that's where I'm struggling to,
because Helm still has a Mac, ball. And also kudos to the home
team for what they did with with three, they did. A lot of that
complexity, they ripped out Teller, they moved it all into
the, you know, into the client side, their mood, much code, all
that stuff. So kudos to them. But they, they do still have a
massive ecosystem of users. And even though I use Helm when it
first came out, with helm, to which I think one was out for
like a month or something at the time, but it does kind of feel
like that most of the users are not net you new users. And maybe
that's wrong, but their ecosystem is so big. So maybe
I'd like to wish we had somebody on the show that that just
picked a new that just picked a new tool, and they picked him
over customized. And maybe it is that that people and that the
templating. And maybe that mental model just works better
for them than having
Jamie Duncan: an interesting thought I just had as we were as
y'all were talking that through. If I'm building an application,
and I'm the ops team, and I have a dev team or multiple dev
teams, and I'm deploying it into my infrastructure, I think
customized is easier, is a more effective solution. But if I'm
sending something out to the public, as a product, I have
Helm chart is what I would most likely pick. And I don't think
it's just because of the size of the ecosystem. I think those
Helm charts with the external dependencies that I can control
as a product owner, make that workflow a lot easier than
saying go grab some GitHub, and here's the customized file. And
here's the variables you can override it let's it is it is
packaging my my container native application.
Tariq Islam: Yeah, no, maybe maybe that maybe maybe there's
absolutely room for both, right, because I've always looked at
customize. Something that's more infrastructure related,
environmental related. So if I'm trying to define to your point,
Jamie earlier, my dev environment, my production
environment, everything in between. and, and leverage the
overlay architecture that customized provides me to be
able to do that at scale. That's That's me harnessing things
right or setting up a harness. And those are my guardrails. And
it's easy for me to do at scale, especially in enterprises, where
there's like maybe dozens and dozens of lines of businesses
that I've got to be able to support. How long the other hand
would, I guess be further left, where we're to now talking
about? Well, we, we support or approve this specific
configuration of my sequel to be deployed?
John Osborne: I think to Jamie kind of touched on something and
I'm not even sure how to articulate it. But I feel like
customize makes assumptions about your ops team. And I think
that there's something there with with Git Ops, where Git ops
makes assumptions that it's not just infrastructure as code, but
your workflows revolve around Git. And I feel like with
customize, it's making assumptions that your ops team
has workflows that are good, that are focused around get, and
that you're working really closely with your dev teams,
which maybe isn't always the case. And I don't know if I've
articulated that correctly. But I feel like there's there's
something there with the assumptions around customize and
how you're working. It's the design principles. You're
Tariq Islam: right. And I think, and I just made another
Association, as you were saying that I I've always felt like and
I don't know, I'm just not realizing this, but I've always
felt like Helm charts. Were very similar to openshift templates.
Is that a fair analogy?
Unknown: Yeah.
Tariq Islam: Do you guys remember that?
John Osborne: Yeah. So openshift templates did have some extra
things in there. But yeah, it was probably 80% analogous.
Tariq Islam: Just in terms of use cases? Yeah. Not so like for
like, but just giving, giving, you know, they didn't on the
right. And a way to give some sort of well defined, not
necessarily catalog of thing that's something separate No, I
think that you know, if you want to if you want to deploy a
patchy if you want to deploy my sequel if you want to deploy sto
if you want to deploy X, Y or Z thing on top of this hardness or
on top of this environment that I've configured, here is a is a
happy little is a happy Helm chart for you to, to use. And
this is this is the baseline of what we'll take this, these are
the guardrails around that application
John Osborne: openshift templates didn't really have all
that layering approach. It just had one master template with
environment variables. And and it could it could do some random
generation of numbers and passwords and things like that.
But it wasn't, it wouldn't layer on all your changes, per se.
Yeah, it
Tariq Islam: wasn't true templates. Yeah, exactly the way
the way Helm is, but I'm thinking just, just
functionally,
Jamie Duncan: I think you certainly have similar feelings.
It's been a while since I used an open ship template.
John Osborne: But yeah, the most ops experience, Jamie, like, do
you think I was touching on something on the assumptions?
Jamie Duncan: Yeah, no, yeah. And I think those assumptions
like, you know, if you're facing inward, if you're building an
internal application, you know, if you're the ops team in a
DevOps environment, those relationships are very different
than if you're sending your code out to an end user.
John Osborne: Or if you're a large enterprise that has never
met, the I've seen, never met them before, regardless of
Jamie Duncan: what's on your paycheck, you know, those end
users are completely different experiences, depending on you
know, how those things are structured. I think it's really
interesting idea, and I've always thought of them as sort
of a linear, like an evolutionary path. And they may
not be,
John Osborne: I'm gonna be in the shower, and something's
gonna hit me. I'm gonna really set articulate this. So yeah, it
does feel like a handoff. Almost like a ticket driven handoff
versus an API driven handoff or something.
Jamie Duncan: Yeah, that's a good way to put it. Yeah. Yeah.
One is not less valid than the other one. They certainly have
different use cases. Mm hmm.
John Osborne: And they both exist, and aren't going
anywhere.
Jamie Duncan: Yes, as a neither. God knows neither going
anywhere, anytime soon. Yeah.
Tariq Islam: Yeah, I know, we got to wrap this up. But I just
I would love to see. I would love to see if anyone out there
has actually leveraged both, right? We've got plenty of
examples of folks leveraging one or the other. But I'd love to
see a success story around. Yes, we we've we've got the use
cases. And we've we've leveraged both across, you know, a few
different processes between cicd between in, you know,
infrastructures code and the whole Git ops thing that we've
been doing. I'm sure there's someone out there.
John Osborne: There's definitely I've seen people online saying
that they were doing it. But I think to me, the cognitive
overhead is now just too high. Yeah, of what you're doing.
Jamie Duncan: You know, we talked a lot and that, you know,
Episode 10, we'd have our first guest. If someone does want to
weigh in there, whether you have sort of expertise level taking
something in production into production with both of these
tools and where you're using them. Let us know. And come hang
out and talk for a few minutes about make us a little smarter.
John Osborne: Always down for always down, I get smarter.
Jamie Duncan: It rarely works for me, but yeah, it really
works. So I think this is it's kind of we again, we were
talking about this before we started recording. I think we're
going to do the next few episodes on sort of CDW
principles, sort of ci CD concepts and where it all lives
in the Kubernetes ecosystem right now. This was for a few
minutes. We talked about this being the The first of those,
but we've picked it, we jumped right into the middle. So I
think we'll start that in earnest here in a couple of
weeks. But is there anything else we want to we want to kick
this? Do we want to kick this from another angle? Before we
wrap up?
Tariq Islam: I feel like we've arrived to a point here where we
could we could confidently tell folks that there are use cases
for both.
Jamie Duncan: Yeah, I think we've certainly teased out a
pattern that none of us had fully recognized before. We'd
all have pieces of it, but I've never had the whole fault
Tariq Islam: and tools why it's why I love this podcast with you
guys. It's always a journey of discovery and reflection. That
fantastic tastic
John Osborne: Yep. There's about 400 projects in the CNC f
landscape for CIC D some I definitely think we should pick
some of them that are that we think are gaining traction or
resonating the most with customers.
Tariq Islam: See ICD is probably going to cover about 380 of
those. So I mean, we'll get we'll get right to it in the
next episode.
John Osborne: Do you want to you want to tackle DevOps to without
being too hand wavy?
Tariq Islam: Well, I just causing me some anxiety over
here.
Jamie Duncan: You have a stay in pain behind my left eye. Sweet
Tarik, you want to bring us you want to close this out? I mean,
this was this was this is the topic you wanted to cover?
Tariq Islam: Yeah. No, we we So yeah, just to wrap it up
covered, we covered helm. And its history in, in this space
that goes way back, I mean, way, way back, covered its use cases
kind of its architecture and the iterations in between. We looked
at, at customize and we we juxtapose them, we compare and
contrast and them. And I think the coolest thing about this
episode is I think we've all kind of arrived at a place where
we feel like there's definitely room for both, but it's got to
be really well thought out. So again, if there's if there's
anyone out there that's done this in any real way,
Jamie Duncan: we'd love to hear from you. Very cool. Thanks for
joining us on episode 10 of K files.
John Osborne: Thanks, everyone. Stay safe.
Tariq Islam: Thank you.