0:07
Hey, I'm Brian Teller. I work in DevOps and SRE
0:10
and I run Teller's Tech. Ship It Weekly is where
0:13
I filter the noise and pull out what actually
0:15
matters when you're the one running infrastructure
0:18
and owning reliability. If something's just hype,
0:21
we'll call it hype. But if it changes how you
0:24
operate, we'll talk about it. Most weeks, it's
0:26
a quick news recap. In between those, I drop
0:29
interview episodes with folks across the DevOps
0:32
world. This is one of those interviews. Today,
0:35
I'm joined by Eric Pate. He's a cloud and DevOps
0:38
engineer. He has a background in building and
0:40
running enterprise web and ERP systems. And he
0:43
has a really grounded approach to leveling up
0:46
through hands -on projects. Eric? First off,
0:49
Brian, thanks for having me. I appreciate it.
0:51
Yeah, no worries. I'm excited about this conversation
0:54
because my DevOps journey. Definitely hasn't
0:58
been a straight line. I come from a software
1:00
engineering background. I have spent years building
1:03
web applications. And I must say that at some
1:05
point in my career, I realized I was fascinated
1:08
about cloud technology and how things run in
1:12
the cloud beyond just shipping code, you know.
1:15
I'm looking forward to sharing what has worked
1:17
for me. what hasn't and hopefully a few lessons
1:21
that can help someone else who is on a similar
1:23
path as me. I appreciate it. That sounds awesome.
1:26
It's interesting because I started as a developer,
1:28
I guess, too. I worked... tech support but then
1:30
i did some like early web development and kind
1:33
of jumped into devops kind of a lot of the same
1:36
way a different industry but um a lot of the
1:38
same way you did so that's very exciting exactly
1:40
brian so can you just tell us who you are and
1:43
what you do day to day well like i said i'm a
1:46
cloud and devops engineer with expected in AWS,
1:51
Linux, CI, CD automation, containerization, infrastructure
1:55
as code. Basically coming from a software engineering
1:58
background. So I principally develop web applications
2:02
and then ship through cloud technology. And yes.
2:07
Oh, that's very cool. And so what system, I guess
2:10
most of the systems, are they AWS based like
2:12
most of the cloud systems or? Yes, they are.
2:14
So coming from my previous background. All right,
2:20
so we develop PHP -based applications. And previously,
2:24
we host the applications on web servers, not
2:29
cloud platforms, so to speak. But then with the
2:36
advent of cloud technology and the thing in Android
2:40
cloud, there has been the need to migrate from
2:42
traditional deployment methods to cloud technology.
2:47
What made you realize when you were doing this
2:50
full stack web development, what made you realize
2:53
that writing code is only part of the picture
2:55
and you wanted to dive into DevOps as well? Right.
2:58
So let me say this, that I found myself more
3:01
curious about modern methodologies and technologies
3:05
around code deployment and how applications scale
3:10
and remain reliable in production environments.
3:12
Yes. Very cool. being a developer to touching
3:19
DevOps stuff? Was it like networking, CICD, just
3:23
AWS, Linux? Like what was the part that you found
3:26
to be the hardest? Well, Brian, that's a great
3:29
question, Brian. How does LevelUp for me, I would
3:32
say, was familiarizing myself with key DevOps
3:35
concepts and with the stack of technologies that
3:39
come with it, i .e. source code management using
3:42
Git, package management using Docker, building
3:45
CICD pipelines. using tools such as Jenkins,
3:49
GitHub Actions, container orchestration using
3:51
Kubernetes, you know, mastering cloud services
3:54
on platforms like AWS, Google Cloud, and also,
3:58
you know, getting a grip on infrastructure as
4:01
code, you know, using Terraform Ansible, and
4:04
of course, implementing continuous monitoring
4:06
and observability with tools, you know, such
4:08
as Prometheus, Grafana, and things of the sort.
4:11
I must say that, you know, beyond that, tools
4:13
also another hardest level level up for me was
4:18
the shift shift in mindset all right the mindset
4:21
shift i .e you know moving from let me say i
4:27
know how this process works on my local host
4:30
to how how that same process behaves in production
4:35
at scale Now, that's a big jump. You know, that's
4:39
a big jump, which requires grit and a lot of
4:41
hands -on experience, hands -on practice, and
4:45
also a grip on the technology that you're working
4:47
with. Yes, Brian. Yeah, those are two really
4:49
good points. A, there's just a lot to know. When
4:52
you talk DevOps, that is just such a wide breadth
4:56
of tools and technologies. And then the other
5:00
side of it, yeah, testing locally, great, it
5:02
works. Then you scale that up to 10 ,000 users,
5:05
100 ,000 users, a million, completely different
5:07
complexities than you're going to have running
5:09
that locally. And things are going to show up
5:11
that you didn't even think of when you were down
5:13
in the 10, 100 early user stage. Exactly, Brian.
5:17
Yeah. So was there anything that clicked first
5:20
for you or were there things that took longer
5:23
than expected as far as like learning like AWS?
5:25
Because like speaking of like DevOps being wide,
5:28
AWS has a ton of different technologies and a
5:30
ton of different. ways of doing the same thing
5:33
so is there anything like in particular that
5:35
maybe clicked earlier or or was harder to learn
5:38
over time that's a great question again brian
5:40
i would say this that um what really clicked
5:44
for me was realizing that um devops sits at what
5:49
what what i will call the intersection of you
5:52
know software engineering and systems thinking
5:55
and business impact what you're doing ultimately
5:59
and largely impacts on business decisions. So
6:02
I enjoyed solving problems like, why is this
6:07
deployment failing? Or why does this service
6:10
degrade and that's a load? And how do you, or
6:14
how do we automate this so it never breaks again?
6:17
You know, that shift in mindset, just from writing
6:21
features to owning the process, owning the system,
6:25
owning reliability and delivery. you know actually
6:29
pulled me in yes so so that's it for me now brian
6:33
what let me add this that what didn't click for
6:35
me like you said earlier all right was the sheer
6:39
breadth and depth of new tools and technologies
6:42
i had to learn you know you you you are not dated
6:46
with lots of of of tools and technologies to
6:49
learn technologies in respect of cloud in this
6:52
respect of networking You need to know the ins
6:54
and outs of Linux, the ICD pipelines, observability,
6:57
you know, it can feel overwhelming, really overwhelming.
7:00
But early on, I tried to try to learn everything
7:05
at once. And that I would say was my mistake.
7:08
All right. You need to progress slowly. You need
7:12
to trust the process, follow along slowly. So
7:17
progress really accelerated when I focused on
7:20
the fundamentals and learned. by building, you
7:23
know, and breaking things on my home lab. Exactly.
7:27
Yeah, that's a good point. So yeah, just focusing
7:29
on one area and then building on that. Exactly,
7:33
right. So looking back at your background, you've
7:36
worked on enterprise grade systems for big organizations.
7:39
What changes when it's not a side project, kind
7:42
of like we talked about earlier, running locally
7:43
in dev, what changes between that and like mission
7:47
critical, like enterprise grade systems? Like
7:49
what are some things maybe you have to worry
7:51
about? um that you wouldn't in a local development
7:55
environment all right so brian my my first instance
7:59
in deploying a mission critical application was
8:03
a voting was an online voting system okay for
8:06
for a school cool and yes and you can imagine
8:11
that the system works fine on your machine And
8:16
then the moment you have to go live or go or
8:21
deploy on production, all right, the results
8:24
you are getting is entirely different. Users
8:27
are trying to access the system and they cannot.
8:31
And you know, elections are contentious matters
8:33
and that you cannot afford to let your users
8:38
lose trust in your system. And so for me, that
8:41
was a great learning curve for me. You really
8:44
have to be prepared for such instances that you
8:48
need to have some virtual environments where
8:51
you can literally test what you have built and
8:56
you want to deploy. So for some mission -critical
8:59
systems, I have been privileged to work with
9:02
teams that have deployed online voting systems.
9:05
We have deployed some enterprise resource planning
9:09
platform for institutions like the food. an agri
9:14
-organization of the United Nations, the Ghana
9:17
office to be specific. So that platform encapsulates
9:21
everything to make their business processes work
9:25
efficiently. So there are modules on procurement,
9:29
modules on human resource management, modules
9:33
on financial management and things like that.
9:35
These are mission -critical systems which you
9:38
can't afford to let them fail. Yeah. So for me,
9:42
they have been a great learning experience for
9:44
me practicing on or working on these systems.
9:48
Yes, Brian. So what did that era teach you that
9:51
actually helped you in DevOps now? Like reliability
9:53
mindset or like working with stakeholders or
9:56
like change management? What was the most valuable,
9:59
I guess, part of that? Brian, you literally mentioned
10:01
everything that was a learning experience for
10:06
me, right? From system reliability to change
10:11
management. It was a great learning experience
10:14
for me that for users, once your system is unreliable,
10:20
it's not available, it's not giving them the
10:24
expected results, they begin to lose trust in
10:27
the system. And then also the change management
10:30
process is very critical and very important.
10:33
There has to be user acceptance. be user accepted.
10:37
You need to tag them slowly and make sure that
10:40
they learn or they get comfortable with the system.
10:45
And so lots of sensitization, stakeholder engagements,
10:48
lots of consultations. All right, you run campaigns,
10:52
you run some communication campaigns here and
10:56
there to ensure that there is some... there is
11:00
user acceptance, all right? There's user acceptance
11:03
because no matter how good your system is, if
11:06
users do not accept the system, the system is
11:09
100 % bound to fail. Yeah, that's very true.
11:12
Very true. Okay, so switching gears, you posted
11:16
about your home lab on the go, which I believe
11:18
was a Mac mini. I'm just curious, why that approach?
11:22
Why a Mac mini? Mac mini, all right. So let me
11:26
just say this, that I purchased, This Mac Mini
11:30
just some time ago. And I said to myself, well,
11:33
why don't I just turn this into my home lab?
11:38
Dedicated specifically for practicing, you know,
11:41
and for honing my tech skills. So I own a laptop
11:47
and I also have this home lab dedicated specifically
11:52
to... practicing my, my DevOps skills. And so
11:56
with this, this platform, I am not afraid to
12:01
break things down. All right. For sure. Yeah.
12:03
To feel in the, make all the mistakes. All right.
12:07
To, to, um, what should I say? To make all the
12:10
mistakes that, that you need to make while, while,
12:15
while learning as well. Yeah. So this home lab
12:17
is, is dedicated. to help me practice my DevOps
12:21
skills and also to hone my tech skills as well.
12:24
Very cool. So are you doing like Docker, pipelines,
12:26
monitoring, like break -fix? Exactly. So just
12:30
last night, so I decided to containerize a static
12:37
version of my website. All right. So I Dockerized
12:41
the website, all right, built the image on that
12:48
platform. All right. I pushed that Docker image
12:52
to Docker Hub, right? And then I went on also
12:58
to run the Docker run command, right? So which
13:03
literally converted the image to a container.
13:05
And then I ran the application from the web browser,
13:12
you know, to local host port 8080. And that gave...
13:18
So I used that home lab, all right, to practice
13:24
writing of Docker files, all right, CICD pipelines,
13:28
constructing my Docker Compose files, you know,
13:31
building my Jenkins files. And so you would be
13:36
seeing a post for me very shortly detailing the
13:40
process that went through and containerizing
13:43
the static version of my website. Very cool.
13:47
So basically that home lab helps me practice
13:52
without guardrails. All right. Make the mistakes.
13:56
All right. Do my debugging in there. Build Docker
13:59
images. Run Docker images. Run Jenkins files.
14:03
You know, build my Jenkins files. Run CICD pipelines.
14:06
Push my image to Docker Hub. Pull from Docker
14:09
Hub. things like that. Very cool. Well, I'll
14:11
look forward to that post. And I think, I think
14:14
that just goes to show you that you don't need
14:15
fancy hardware either for a home lab. Just take
14:19
what you take, whatever you have or, or what
14:21
you've used previously, or, you know, if you
14:23
have an old Mac mini or whatever, you don't need,
14:26
you don't need like a big rack and stack server
14:28
set up. Like you don't need a bunch of fancy
14:30
machines. Exactly, Brian. Exactly, Brian. So
14:34
shifting gears a little bit from the home lab,
14:36
and we talked about this at the top too a little
14:38
bit, but I'm just curious. So we talked about
14:40
how the tools are endless, right? You have Terraform,
14:42
Kubernetes, Jenkins, Prometheus, Grafana, Ansible.
14:45
How do you choose, how do you personally go by
14:48
choosing what to learn next? All right. So this
14:52
has been my structure. All right. So I begin
14:55
with source code management. All right. So the
15:00
basics for me is very critical. You need to be
15:04
familiar with the basics. You need to have a
15:07
stronghold on the basics, which is Linux. All
15:10
right. So things to do with Linux commands, mastering
15:14
bash scripting are very important and very, very,
15:17
very, very critical because at the core of DevOps
15:21
is Linux. You cannot be a DevOps engineer. And
15:25
not no Linux. Linux is very critical. So I focus
15:29
on the fundamentals, which is Linux. And then
15:32
I move on to source code management tools, you
15:35
know, like Git. And then I progress into package
15:39
management using Docker, right? And then I progress
15:43
to CICD pipelines using Jenkins. So the idea
15:49
is how do I use automation, all right, to build?
15:54
the Docker image and then push it to a repository.
15:59
All right. Okay. And then from the Docker, from
16:03
the CICD pipelines and practice, all right, so
16:07
I move on to the cloud platform. All right. So
16:11
that now after pushing to the Docker repository,
16:15
all right, it has to be pulled onto your cloud
16:18
platform. Now we have cloud services also that
16:21
can serve us as your... your Docker repository.
16:25
All right. So the various cloud platforms have
16:28
services that can serve as, you know, Docker
16:32
repository. And then I move on to learning infrastructure
16:37
as code. All right. But in between that one,
16:41
so from Docker to the cloud platform, my process
16:46
would be to learn Kubernetes next. And then after
16:49
learning Kubernetes, you learn Terraform. Okay.
16:52
or infrastructure as code so basically terraform
16:56
ansible and then you move on to to to implementing
16:59
continuous monitoring and observability with
17:02
you know tools like prometheus and grafana gotcha
17:05
so so so for me that has been my structure well
17:10
some people have their structure. But for me,
17:14
at the heart of DevOps has been to learn and
17:19
show that you get the fundamentals right and
17:21
show that you have a good grip on Linux and then
17:25
you progress from there. And then learn the entire,
17:28
through the process, learn the entire pipeline
17:29
and follow it through. It sounds like, right?
17:32
Exactly. Exactly, Brian. Exactly, Brian. So what
17:35
are your thoughts on certifications versus like...
17:39
doing your own projects what do you think is
17:41
more valuable well for certifications let i would
17:46
say this that's a very dicey dicey matter yeah
17:52
it is that's a dicey matter right well here is
17:55
it hands down i'll see real projects would always
17:59
make the big difference for anyone right certifications
18:04
and courses will help build structure but running
18:08
real you know, setting up CICD pipelines, deploying
18:12
to cloud infrastructure, breaking things, monitoring
18:15
them, fixing things, you know, that's where everything
18:18
clicks. That's where everything clicks, yes.
18:20
So certifications help, all right? Like I said
18:23
earlier, certifications and courses would help
18:26
you build structure. But, you know... Hands down,
18:29
I would say real projects would always make the
18:32
big difference. Real projects and hands -on projects
18:35
will make the real difference. Because you have
18:39
to fail, right? You have to learn to fail and
18:40
be okay with that. You have to learn to fail.
18:42
You have to learn to fail. You have to learn
18:45
to fail. For me, there have been several times
18:47
where I have just tried to organize a Docker
18:52
Compose file. as basic as getting it to run successfully.
18:56
Brian, and it's been a challenge. And so I put
19:00
that file down, go to sleep, come back the following
19:03
morning, and it starts to end. And surprisingly,
19:06
things begin to click for me. All right. And
19:08
then when you realize that you made mistakes,
19:10
oh, I made the mistake here, I made the mistake
19:12
there, I made this mistake. Just two weeks back,
19:16
all right, one Docker Compose file that I wrote
19:19
just wasn't working. Only for me to realize there
19:22
was a dash, a dash I had introduced somewhere
19:25
that shouldn't have been there. And it's been
19:27
a great learning experience for me. So I would
19:29
say that hands down, real practice and real projects
19:33
would always make a difference. Yeah, I agree
19:36
with that. I think, yeah, I think certifications,
19:38
boot camps have their place, but as a foundational,
19:43
a structure school, same thing, but you need
19:46
that hands -on learning. At some point you need
19:48
to actually dive in. be comfortable with failing
19:51
because that's okay. Like, you know, it's okay.
19:53
You're going to stumble a little bit and that's
19:55
okay. So wrapping up a bit, what's one piece
19:59
of advice you would give someone trying to break
20:02
into DevOps in 2026? Where should they start?
20:04
What should they do? All right. So what I would
20:07
say is this, that let me say this, that I would
20:10
just say, focus on depth and not hype. Focus
20:14
on depth and not hype. So I... I have found out
20:17
that employers, you know, care more about how
20:20
you think and solve problems, right? How you
20:24
think and solve problems than knowing every tool
20:29
there is, all right? How you think and how you
20:32
solve problems, all right? Because at the heart
20:35
of that all, that is what DevOps really is. Simplifying
20:38
things, automating processes, and then shipping
20:41
code faster and efficiently. all right and so
20:45
how you think now my my my other advice would
20:49
be this that consistency would always beat intensity
20:53
all right that consistency would always beat
20:55
intensity you don't need to learn everything
20:58
in three months you need to show up steadily
21:01
all right you you need to show up you need to
21:04
have a routine if you tell yourself that you
21:06
would dedicate two hours each day to learning
21:09
devops do that You need to show steady progress.
21:13
You need to build. You need to document. You
21:15
need to reflect. You need to repeat. And it's
21:18
okay to fail. It's okay to fail. Do this repeatedly.
21:22
And I would say also that slow down and be consistent.
21:27
You don't need to master everything overnight.
21:29
Just show up. Build something small and keep
21:32
going. And also one thing I would say also would
21:36
be this. Learn to share your journey, all right?
21:40
Learn to write, learn to post, learn to talk
21:43
about what you are learning because it's only
21:45
through that process that it reinforces your
21:48
knowledge. It creates visibility as well. And
21:51
then opportunities often come from when people
21:54
see the way you think and not just what's on
21:57
your resume. The way you think, the way you solve
21:59
problems, the way you handle challenges. That
22:03
would be for me, Brian. Yeah, I agree with that
22:05
a lot. All right, so where should people follow
22:07
you and what should they check out? All right,
22:09
Brian, so people can follow me on LinkedIn and
22:13
then also my personal website, which is ericpatty
22:17
.com, ericpatty .com. I'm also on Facebook and
22:21
also on Instagram. And so I'm primarily on LinkedIn
22:25
and I have a website, ericpatty .com. Yes, Brian.
22:29
Awesome. Appreciate it. Well, thank you, Eric
22:31
Pate, for coming on and being on Ship It Weekly.
22:34
I really appreciate it. Thank you, Brian. It's
22:36
been great. Thank you. All right. That's the
22:38
interview with Eric. Quick reminder on the format.
22:41
Ship It Weekly is still the weekly news recap.
22:44
And I'm dropping these guest convos in between.
22:47
If you want to catch both, hit follow or subscribe
22:50
wherever you are listening. And if this episode
22:53
was useful, share it with a coworker or your
22:55
on -call buddy and leave a quick rating or review.
22:58
It's annoying how much that stuff actually helps
23:01
the show. We'll be back next week with the regular
23:03
news episode. We'll see you then. Thanks for
23:06
listening.
