0:02
Thank you. Hey, I'm Brian Teller. I work in DevOps
0:06
and SRE and I run Teller's Tech. Ship It Weekly
0:09
is where I filter the noise and pull out what
0:12
actually matters when you're the one running
0:15
infrastructure and owning reliability. If something's
0:18
just hype, we'll call it hype. If it changes
0:20
how you operate, we'll talk about it. Most weeks,
0:23
it's a quick news recap. In between those, I
0:25
drop interview episodes with folks across DevOps,
0:28
SRE, and platform engineering. Today is one of
0:32
those interviews. Today, I'm joined by Danny
0:34
Teller. He's a DevOps architect at Tipalti, and
0:37
we're going to talk about internal developer
0:39
platforms and why he thinks we're headed towards
0:41
more internal IDPs instead of just backstage
0:44
everywhere. Danny, can you introduce yourself?
0:47
Yeah, definitely. Thank you very much, Brian.
0:48
Well, thank you for having me, first of all.
0:50
As I stated, I'm the DevOps architect for Tipalti.
0:53
Tipalti is a... rather a medium -sized business
0:56
company that is in the fintech world. And most
0:58
of the things that I handle is working with our
1:00
developer teams and our architects to kind of
1:03
steer the direction of the company from not a
1:05
software perspective, but a DevOps perspective.
1:07
And that also includes platform engineering because
1:10
we can't have just one of them anymore. So you
1:12
got to go with both. Yep, for sure. So one of
1:14
the things that made me want to reach out to
1:16
you was about this talk about IDPs. And I'm curious
1:21
your thoughts on... idps like what what are your
1:24
thoughts on where do you think idps are headed
1:25
for everyone else internal developer platforms
1:28
i know idp is an acronym for for many different
1:30
things uh in the devops identity it could be
1:32
identity it could be yeah yeah what's your thoughts
1:35
well it's obvious that in recent years there's
1:37
been a rise of platforms in any company you can
1:40
take backstage for example which was open sourced
1:43
and everybody can take it and use it as they
1:45
see fit And then in recent years, we had rising
1:47
companies like, what are they called? Northfolk,
1:49
I think, or Northflank. And you have Port .io,
1:53
which are offering a huge integration suite.
1:55
And so on. And many companies that started to
1:57
buy into platform engineering. There were already
2:00
platform engineering teams across different companies,
2:03
but they were doing something internal. Some
2:04
of them transitioned from DevOps into DevX, which
2:08
are more... program oriented rather than ops
2:11
oriented and they started picking up things like
2:13
backstage and introducing it to the organization
2:15
to you know simplify the way developers work
2:19
because one of the core things you have in platform
2:22
engineering is reducing everything from developer
2:25
perspective from operations perspective and developers
2:28
lifetime to literally nothing so they have nothing
2:31
to worry about but the golden standard can be
2:33
like he types in something and into chat and
2:36
he gets everything done behind the scenes that's
2:38
kind of like that golden mantra, if you will.
2:41
So we have all that rising every day. And that's
2:44
why things like Backstage are highly adopted
2:46
and have a great community. That's why we have
2:48
great products like Port .io and other ones and
2:51
so forth. What do you think changed that makes
2:53
internal tools more realistic now? I think with
2:56
all the changes recently in the AI world, in
2:59
Gen .AI. It kind of simplified how we view IDPs.
3:03
If you're talking about last two years, then
3:05
we've been constrained to companies and open
3:07
source solutions. So if you take Backstage, which
3:10
is a great product when it works, which is a
3:13
great sentence to say. So when it works, it's
3:16
great. But when something breaks because it's
3:18
so tightly knit together with Node .js and TypeScript
3:21
and all the... stuff it's written in, it makes
3:23
it very difficult to maintain. So unless you
3:25
have developers that specialize in that and also
3:28
understand infrastructure, then you can't actually
3:30
maintain it. Every little thing breaks it. You
3:33
always have to rebuild the image and it makes
3:35
it very difficult to manage. Even if you look
3:37
at Backstage, Portal Backstage, that recently
3:39
launched from Spotify, the SaaS offering, this
3:44
is what they do behind the scenes. They explicitly
3:46
said that whenever you make a change to Backstage,
3:49
we rebuild your image. So they took what you're
3:52
doing already and just call it a SaaS platform.
3:55
And it's written just in their docs. It's a little
3:58
funny. I don't know if the docs are still written
4:01
this way, but I do remember Spotify saying too
4:03
that they recommend at least like six full -time
4:06
developers managing backstage, which is just
4:08
cost prohibitive for most companies. I mean,
4:10
they just can't afford. But that level of staff
4:13
to run an internal platform. Yeah, I mean, the
4:16
DevEx team should not just be doing backstage.
4:19
They have to also develop more internal tools
4:21
for the company. I mean, whatever DevEx engineers
4:23
do is usually with creating, you know, like the
4:27
pre -commit hooks, for example, like they were
4:29
created. I mean, it's kind of a thing for platform
4:32
engineering to have or DevEx developer experience
4:34
to have. So this is what they do day in, day
4:37
out. And then came stuff like IDPs. And they
4:40
made things a lot easier because you have a central
4:42
control plane that can be integrated into virtually
4:45
anything. And you can see a developer just working
4:49
with one single pane of view instead of tens,
4:51
which include metrics, traces, monitoring, deployments,
4:56
pipelines, so on and so forth. So it's great.
4:58
The idea is great. But then you're encountering
5:01
a bigger problem. And that's when you start to
5:04
manage it. And because these teams are very...
5:07
Oriented in writing it, that's great. But now
5:11
that you have Gen AI, you can kind of cut that
5:13
in half. Even your platform engineers, even your
5:16
classic DevOps engineers, they can do it on their
5:19
own because they are familiar with the tools
5:21
like Backstage. They are familiar with tools
5:24
like kubectl. They are familiar with Terraform,
5:27
so on and so forth. So even DevOps that are not
5:30
trained as software engineers do know how these
5:33
things work. So specking it out with tools like
5:36
SpecKit or creating plans with Cursor or Cloud
5:40
Code and Skills becomes very easy. Instead of,
5:44
so you can just ask it, okay, go ahead and study
5:47
how Backstage works. Let's create a Pythonic
5:49
Backstage instead. Makes it also just as easy
5:53
to do. Yeah, that makes sense. So what do you
5:55
think Backstage got right? I think Backstage
5:57
as a concept, it's great. I think it's really,
6:00
it's one place where you just throw many integrations.
6:04
And it just works. And people have one centralized
6:07
location for that. I mean, they got that right.
6:10
The idea is great. Condensing also tech docs
6:13
in there, which is my favorite feature in backstage.
6:16
I love that feature. And the tech radar that
6:18
they have there, it's just great. It's a great
6:20
user experience. When it works and you see it
6:23
live and everything, you just want to buy into
6:25
that. But when you start managing, that's when
6:28
you lose it. So can you give me an example? Like,
6:30
what did you build and what problem exactly were
6:33
you solving with that build out? Yeah, so, well,
6:36
we at first tried working with Backstage. We
6:39
did. We ran for a whole year. But given that
6:42
we've had many projects in the same time, so
6:45
managing Backstage kind of fell apart. And we
6:48
had a couple of our three engineers trying to
6:51
manage the backstage as a whole and doing their
6:52
own thing in developer experience as well. And
6:54
it just fell short. So you can maintain that
6:57
for 350 developers. It's insane. And that's not
7:00
including the DevOps team, which was also trying
7:02
to help at the time. So even though we integrated
7:05
stuff into that, we tried to work with it, it
7:07
just proved to be a maintenance nightmare. So
7:10
it dropped off. And then you start looking into
7:13
other products. You see like Port, like I mentioned,
7:16
and other ones like Northflank and so forth.
7:18
And great. So they can sit in your system. They
7:21
can integrate their SaaS platform. But when you
7:23
start seeing how they work, when you start seeing
7:26
if you can do it on your own, because the plugins
7:29
are already there. They're already online anywhere.
7:32
And even if you point an LLM to certain plugins
7:35
and tell it to learn it and then recreate it,
7:37
you can just do it with zero maintenance. It
7:39
becomes super easy. barely an inconvenience yeah
7:43
i so at my last company we actually ran roadie
7:46
for a while which is another sas backstage like
7:49
offering and i found that it was good at helping
7:53
us get set up quickly but beyond that um and
7:57
we were very immature to the whole idp process
7:59
at the time this was a new experience for us
8:01
we were just moving from a devops team into a
8:04
platform like devex experience team but i did
8:07
find that like i i don't really know what it
8:10
really bought us at the end of the day and it
8:12
may be a better product now this was a few years
8:13
ago but i don't know what it really bought us
8:16
above what backstage could offer or or any other
8:19
like you mentioned another sass um in the adoption
8:22
yeah definitely i mean you don't know you can't
8:25
tell until you actually try it but for us anyway
8:27
all these products they didn't they just fell
8:30
short so we decided to try something on our own
8:33
because well At the end of the day, through IDPs,
8:36
I'm supposed to be able to provision whole environments
8:40
per se. I'm supposed to be able to see every
8:43
other environment that I have as a developer,
8:45
even up to production and so on and so forth.
8:48
So in the initial stage, we decided to drop all
8:51
the other ones and focus on the real pain for
8:53
our developers. And that was actually developer
8:56
environments. It's something that's been brewing
8:58
in our company for a very long time. We've been
9:00
trying to do it for a very, very long time. And
9:02
it proved to be very difficult. Because of the
9:04
nature of FinTech and all the stuff that you
9:07
need to work with and maintain all the time,
9:09
it just becomes a small developer environment
9:12
becomes very, very large. So we tried to minify
9:15
that as much as we could. And eventually we got
9:17
to something that you can work with. It wasn't
9:20
100 % of the entire product, but 85 % is already
9:23
good enough. I mean, missing a couple of features,
9:25
but it's already something a developer can use
9:27
to work with. So we went with the classics. We
9:29
decided to go with Argo CD, cross -plane, and
9:32
all the infrastructure is going to manage it
9:33
in the first stage. And that's going to start
9:34
with that. You just commit a normal YAML and
9:37
you get the entire infrastructure in your backend.
9:40
Everything. You can gain all the databases, all
9:43
the stuff that you need to run the application
9:44
smoothly. You get it out of the box. Everything
9:47
is prepared using best practices from Platform
9:49
Engineer. Golden images, golden charts, if you
9:52
will. Networking, all clusters, standalone clusters,
9:55
not namespaces. even monolithic machines if we
9:58
have to. So everything is bundled together. So
10:00
in about 30 minutes, you can spin up a whole
10:03
semi -product environment. And the next stage
10:05
after that is, well, you know, connecting an
10:08
AI to that. Because if today I'm spinning an
10:11
entire flow, everything the system has, I'm just
10:14
saying, go ahead and use it. So we're trying
10:17
to play with various ways to see how we can ask
10:20
an LLM like Claude or ChadGBT through Slag and
10:24
say, listen i need this and this xyz flow go
10:28
ahead and create that for me so instead of creating
10:30
the entire flow which is say five to six machines
10:33
including any uh kubernetes cluster and some
10:36
old stuff legacy machines we can dumb it down
10:39
to something really really small and the way
10:41
to do that is playing with llm you have to make
10:44
sure your model can actually access all these
10:47
flows and to see them and compile exactly what
10:50
it needs and then request that from from crossplane
10:52
in our ground So this is something we're toying
10:54
around with to see how we can do that. But we
10:57
have kind of success in that area because we've
11:01
developed quite an idea for that. And it proves
11:06
to be very useful for now. So it goes great,
11:08
really. I don't mind sharing it. It's fairly
11:11
straightforward. Is it just an MCP server that
11:13
can reach out to Argo and kubectl? So pretty
11:17
much behind the scenes, you have the Slack bot,
11:19
which connects to Cloud or Bedrock or any other
11:22
one. In turn, it does use an MCP. So that MCP
11:26
actually is a tool that calls to GitHub, and
11:29
it kind of rags all the repositories back to
11:32
itself using a small depth. Or actually, it just
11:35
takes a specific file. That specific file is
11:38
kind of an XML structured file that says, this
11:41
is the repository. This is what it contains.
11:42
This is the flow. This is the database needed.
11:45
These are their names. This is kind of what this
11:47
repository represents and how it works. So when
11:49
we use requests, I need payments flow, for example.
11:53
Then it's going to pull all these repositories.
11:55
They're actually relevant repositories because
11:57
we have a RAG map of all of these repositories.
12:01
It just pulls all these relevant files, piles
12:04
that into a list of flows, repositories and flows.
12:08
And after that, it just communicates with using
12:11
another MCP with Crossplane and Argo, submits
12:14
a YAML that it needs, and then provisions it
12:17
for the developer. Very cool and interesting.
12:19
So going back to these developer environments
12:22
that you set up, I'm assuming they're ephemeral
12:24
in nature, like because you're using Crossplane
12:26
to provision everything. Yes, we're using also
12:29
a TTL controller as the annotation. Basically,
12:33
you get an environment from 8 to 5. That's it.
12:37
And if you need to extend it, you can. Interesting.
12:40
Are you using Terraform to provision the initial
12:42
infrastructure or is everything through Crossplane?
12:45
Everything is Crossplane. Okay. Interesting.
12:47
And why did you choose that approach? Is it just
12:49
to be closer to the actual application in Argo?
12:53
Yes, I wanted to use Argo as much as I could
12:55
because it just makes sense. you already have
12:57
the provisioners within Crossplane. So I don't
13:00
need to toy with anything else. And eventually,
13:03
if the developer in the first offering just submits
13:06
a YAML file, which is, what, five lines long,
13:09
then already they have something reduced instead
13:12
of just provisioning through a pipeline and everything.
13:14
Just git commit and you get an environment. It's
13:16
far simpler, far better, and they always get
13:18
the same thing. That's very cool. So, okay, backing
13:21
up again. Sorry, going back to the developer
13:23
platforms and this new approach that you, you
13:26
know, you went the SaaS way, it didn't work.
13:28
You decided to do this internal thing. How did
13:30
you get adoption from the overall engineering
13:32
team? It's quite easy. Okay. It's quite easy
13:36
because it's a pain that we had to solve. So
13:38
this is a major, sorry, even pain in the ass
13:41
of developers since they couldn't have normal
13:44
developer environments. So once you sell something
13:46
that gives them exactly what they need. which
13:49
is environments, so it's kind of easy to roll
13:52
them in. So they have one place. They're not
13:54
even looking. All they get is this environment
13:57
that they're connected to. They have their own
13:58
Argo CD set up in that environment. They can
14:01
provision whatever they want. And the second
14:03
phase, which will connect the LLM, will be even
14:05
simpler for them. So every developer today wants
14:08
to work with as less screens as possible. They
14:11
just want to stick to their VS Code, their Visual
14:13
Studio, JetBrains, whatever, and just stick their
14:15
nose in there all day long. They don't want to
14:17
look at metrics and stuff. Just query this. I
14:20
want this from QL to tell me if there's a problem
14:23
in my app at 2 p .m. to 1 a .m. That's what they
14:26
want. So I think that it's easier to maintain
14:29
that locally using a DevOps team, platform team,
14:31
or even if you want to go even further in AI
14:35
ops team, because I do believe that using things
14:38
like agent core and bedrock is going to be the
14:40
future of these things. You're not going to see
14:43
more. more of graphs lying around or backstage
14:46
lying around. Because if you can get it through
14:48
text, and that text can also generate an image
14:51
for you, which is pretty damn good, by the way,
14:54
for now, from nano banana, so on so forth. So
14:56
you're kind of losing the entire idea of having
14:59
platforms like backstage or other ones, all you
15:02
need to worry about is integrations. That's interesting.
15:05
That's an interesting idea. I'm curious, what
15:07
was the biggest surprise with this approach?
15:10
Was it the tech? Was it the ownership model?
15:13
Was it like change management? Was there anything
15:16
that was a surprise, I guess? No, actually, there
15:18
were no surprises. We planned it thoroughly because
15:21
we knew what we wanted to achieve, how and when.
15:24
And the biggest thing is what we're struggling
15:26
with the most is what most people are struggling
15:29
with. And that's fine -tuning the models to get
15:32
exactly what you want. So we're constantly working
15:35
also with AWS engineers because we're also working
15:38
with Bedrock all the time and we're leveraging
15:40
that. We're kind of back and forth with them
15:42
all the time for the support. And it is working.
15:45
We are getting better and better at achieving
15:47
what we want. So, okay, let's say a listener
15:50
was listening to this and they thought the internal
15:53
integration aspect is really cool, but they've
15:55
never set up an IDP before. They're deciding
15:58
between... that approach or or backstage what
16:00
what signals would push them one way or another
16:02
in your opinion i think it's maturity definitely
16:06
maturity because i can also vouch for my for
16:08
what he did and myself as well that we started
16:11
off like everybody you go with things that are
16:14
well known and instead of creating something
16:16
on your own you want to test these waters first
16:18
because maybe you'd be surprised that you're
16:21
using backstage in such a small manner that maintaining
16:23
it does give you the benefit of everything you
16:26
need and you don't change it as much you maybe
16:29
update a version here and there but you don't
16:31
need all everything it can do or if you go and
16:35
you find that you work with companies that give
16:37
you the idp experience and that's also good enough
16:40
for you and you can you can stick with that and
16:42
it's great i mean if it works for you then stay
16:44
there but when you get to these points where
16:47
everything they give you is just not enough that's
16:51
when you start working by yourself That makes
16:53
sense. So what's one piece of advice that you
16:56
would give like platform or DevEx teams that
16:59
are wanting to start an IDP come 2026? I would
17:02
actually leverage as much as AI as I can with
17:06
that and also work with AI as best as I can.
17:10
I mean, even the recent features of Cursor that
17:13
they support skills from Claude or using Gemini
17:16
CLI or knowing which model. is best for what
17:19
kind of work after i get this through this hurdle
17:22
and i understand what's going on and how to use
17:25
it i will then go after idps i unders i will
17:28
have the models understand and map out how they
17:31
work and then start fixing my own ideas around
17:34
that very cool all right let's shift gears a
17:37
bit i wanted to talk about talk about two other
17:39
things but uh that were non -idp related uh one
17:42
was your mongo atlas i think it's called m atlas
17:45
yeah yeah the mat list kind of curious what caused
17:48
you to build this and was it because like terraform
17:50
operator limits weren't enough or like what what
17:52
was the reasoning like what were what pain point
17:54
were you solving frustration okay yeah so the
18:00
story starts with uh mongo when we started working
18:03
mongo we had our terraform modules everything
18:06
was up and running great but at some point the
18:08
drift was just too large to maintain from um
18:12
from Terraform perspective, from Terraform, the
18:15
Mongo modules that we built ourselves, and what
18:18
was actually within our Mongo Atlas cloud. So
18:20
that was a little difficult to manage. So we
18:23
said, okay, we have all these resources, and
18:25
doing Terraform import is not a nice way to do
18:28
it. It's error prone. So we decided to let that
18:32
go and see if we can do it in a different way.
18:34
We tried exploring the Atlas CLI, but it gave
18:37
us only a management perspective creation. creation
18:41
experience. It was very difficult to work with.
18:43
And then we decided to try the Kubernetes operator.
18:46
And then we found two big issues. You can't own
18:49
existing resources like you do in Terraform import.
18:53
So if you create a similar YAML with a similar
18:55
name resource and everything, it just says, no,
18:57
it exists. You can't do anything with it. And
18:59
the other part is it was semi -limited to what
19:03
we needed to do. So given all these issues and
19:06
the lack of abilities to work back from existing
19:10
infrastructure, it kind of led to the creation
19:11
of a MATLAS. MATLAS kind of tries to combine
19:15
the user experience from kubectl and also the
19:19
abilities of Terraform. So in a nutshell, you
19:22
can basically say, okay, I've got this organization
19:25
in Mongo Atlas. I want to map all the infrastructure.
19:29
All I have to do is hit a button. And well, I'll
19:32
hit a feature. It's called Discover. And it just
19:35
pushes everything into a YAML file. And moreover,
19:38
you can transform that YAML file using MathMath
19:40
as well into a workable YAML. Ah, interesting.
19:45
That's cool. Yeah. And since I don't rely on
19:48
states at all, because I thought that it would
19:51
be counterintuitive. so if you change something
19:53
because a lot of people may go on to atlas because
19:57
of a problem or whatever and start changing settings
19:59
because it does happen it's a database you don't
20:01
know what's going to happen the next day so i
20:03
left that part intentionally out so if you change
20:06
something online you can just update that yaml
20:08
again with the discover feature and have the
20:10
same thing already as infrastructure as code
20:12
if you apply something and then you can also
20:14
do it in a surgical manner like a partial reconciliation
20:17
so i don't break everything that's already existing
20:21
in mongo atlas so people can find matless on
20:25
github and they just search up okay awesome yeah
20:28
definitely i mean it's kind of i've recently
20:30
uh read from platform engineering labs that they
20:33
have this tool called form a or form i and it
20:36
kind of does it it's it's a tool written in pkl
20:39
in app in apple language and the idea behind
20:42
it is great it's kind of just trying to remove
20:44
what terraform does and also do the partial reconciliation
20:48
and the discovery and everything so when i read
20:51
about that it reminded me of like i'm pretty
20:53
much doing the same thing just in go and not
20:56
in pkl interesting i have not heard of that tool
20:58
interesting very cool it's fairly new it's like
21:00
six months old i believe and then uh so lastly
21:03
i wanted to just touch on this a little bit you
21:05
are a a golden jacket uh holder i'm curious what
21:09
that process was like going through all the certifications
21:11
well it was fun and it was tedious at the same
21:15
time But there was one aspect of it which really
21:19
frustrated me a lot. And I do hope that AWS will
21:21
listen to that and do change it in the future
21:24
because they do have the capacity to do that.
21:26
One thing that really pissed me off about the
21:29
exams is they're really outdated. That's the
21:34
one thing that really hits me every time. For
21:36
example, you have the DevOps engineer exam, which
21:39
I did that about earlier this year. When I already
21:44
did that exam, the code commit service was already
21:48
taken offline. Yet the exam had five to six questions
21:51
around that. So why are you asking me questions
21:54
about a service that no longer exists? Oh, that's
21:56
frustrating. Yeah. Yeah. So, and the thing that
22:00
also bugs me on that is they constantly say,
22:02
yeah, go to skill builder and read the docs all
22:05
the time. Read the docs. Okay. The docs said
22:08
the service is not existing anymore. So why should
22:10
I learn about it? Yeah. Well, then you have situations
22:13
like CodeStar going away and then changing. There's
22:16
a lot of inconsistency. I agree with that. Yeah,
22:19
and that's really the real frustrating part.
22:21
But apart from that, it's fun to do. I mean,
22:25
it does give you a lot of perspective on AWS
22:27
services and how it works, especially when you
22:30
read the docs and try to understand further than
22:32
what's actually asked about in the exams. And
22:35
it's great. I mean, it's a great feeling when
22:38
you finish all of that and, you know, kind of
22:41
just putting it behind you. Well, congratulations.
22:43
I mean, that's an awesome accomplishment. What
22:46
recommendations would you have for listeners
22:48
that maybe want to head down that road of trying
22:52
to pick up all the certifications? I would start
22:55
from the very lowest ones. I mean, it's true
22:57
what they say about the discounts. So start from
23:00
the very first ones and get that 50 % discount
23:02
for the next one. And it does train you for the
23:05
other exams because you get to understand how
23:08
these exams are structured. Yeah, of course,
23:11
you can go online and find these dumps or whatever
23:13
people really have out there. You can do that.
23:16
But once you really do these exams and even fail
23:18
once or twice these exams, you understand the
23:21
structure and it's quite easily understandable
23:23
for the next time you go ahead and do that. Yeah,
23:26
very true. Very true. All right. Anything you'd
23:28
like to leave our listeners with? Any recommendations?
23:31
Yeah, actually, I would. Yeah. I mean. There's
23:34
one thing that's been on my mind quite lately,
23:36
and it's regarding for all platform engineers,
23:39
developers, DevOps teams, literally quite everyone.
23:41
And it feels that with all the rise and changes
23:44
in Gen AI, a lot of people think that they're
23:47
staying far too behind. And I believe that because
23:51
of these changes, we should strive to really
23:55
get our knowledge up and running in our heads
23:57
far faster than we usually should. And yeah,
24:00
subscribe to these magazines, TLDR, so on and
24:03
so forth, and read more articles and so on. So
24:07
because it does give you the benefit of staying
24:10
ahead of others. And you need to do that not
24:12
because of job security, because it's just that
24:15
interesting. Yeah. Yeah, I think anyone that's
24:18
in SRE, DevOps, platform engineering. You have
24:21
to have a thirst for knowledge because you're
24:24
always inundated with different tools, CI, CD
24:27
processes, different ways of doing things. And
24:29
if you're not staying on top of that, then you
24:32
really are going to be behind. And the thing
24:34
I always come back to is, you know, I do a big
24:36
process or I'm rolling out a new AWS account,
24:39
a new way of. provisioning basically a new poc
24:42
that i'm doing what i did five years ago for
24:44
that poc is not what i would do today i would
24:46
architect it completely different than i would
24:48
have just five years ago maybe even two years
24:50
ago so yeah you you kind of need to always have
24:53
that that thirst and hunger for learning and
24:55
just staying on top of new things. You can't
24:57
stay on top of everything, obviously. I mean,
24:59
that's also, you know, the reality is imposter
25:01
syndrome does exist. You can't know everything
25:03
and that's okay. That's why they're teams. That's
25:05
why we're on teams and we're collaborators, you
25:07
know, but just trying to be present, I think
25:10
is really important. Yeah, most definitely. Awesome.
25:12
Well, where can people find you online? Mostly
25:14
I'm on LinkedIn. So that's the best way to reach
25:17
out to me. Some people already have, so. Awesome.
25:20
So Danny Teller on LinkedIn, if you want to reach
25:22
out. I'll also leave your MATLESS GitHub link
25:27
in the show notes. And thanks for coming on,
25:29
Danny. Really appreciate it. Thank you for having
25:31
me. I had a great time here. Thanks, Brian. Thanks.
25:34
All right. That's the interview with Danny. Quick
25:37
reminder on the format. Ship It Weekly is still
25:40
the weekly news recap, and I'm dropping these
25:42
guest convos in between. If you want to catch
25:45
both, hit follow or subscribe wherever you are
25:48
listening. And if this episode was useful, share
25:51
it with a platform or DevEx friend and leave
25:53
a quick rating or review. It's annoying how much
25:56
that actually helps the show. We'll be back later
25:58
this week with a regular news episode. We'll
26:01
see you then. Thanks.
