Ship It Conversations: From Full-Stack to Cloud/DevOps, One Project at a Time (with Eric Paatey)

Transcript

Hey, I'm Brian Teller. I work in DevOps and SRE

and I run Teller's Tech. Ship It Weekly is where

I filter the noise and pull out what actually

matters when you're the one running infrastructure

and owning reliability. If something's just hype,

we'll call it hype. But if it changes how you

operate, we'll talk about it. Most weeks, it's

a quick news recap. In between those, I drop

interview episodes with folks across the DevOps

world. This is one of those interviews. Today,

I'm joined by Eric Pate. He's a cloud and DevOps

engineer. He has a background in building and

running enterprise web and ERP systems. And he

has a really grounded approach to leveling up

through hands -on projects. Eric? First off,

Brian, thanks for having me. I appreciate it.

Yeah, no worries. I'm excited about this conversation

because my DevOps journey. Definitely hasn't

been a straight line. I come from a software

engineering background. I have spent years building

web applications. And I must say that at some

point in my career, I realized I was fascinated

about cloud technology and how things run in

the cloud beyond just shipping code, you know.

I'm looking forward to sharing what has worked

for me. what hasn't and hopefully a few lessons

that can help someone else who is on a similar

path as me. I appreciate it. That sounds awesome.

It's interesting because I started as a developer,

I guess, too. I worked... tech support but then

i did some like early web development and kind

of jumped into devops kind of a lot of the same

way a different industry but um a lot of the

same way you did so that's very exciting exactly

brian so can you just tell us who you are and

what you do day to day well like i said i'm a

cloud and devops engineer with expected in AWS,

Linux, CI, CD automation, containerization, infrastructure

as code. Basically coming from a software engineering

background. So I principally develop web applications

and then ship through cloud technology. And yes.

Oh, that's very cool. And so what system, I guess

most of the systems, are they AWS based like

most of the cloud systems or? Yes, they are.

So coming from my previous background. All right,

so we develop PHP -based applications. And previously,

we host the applications on web servers, not

cloud platforms, so to speak. But then with the

advent of cloud technology and the thing in Android

cloud, there has been the need to migrate from

traditional deployment methods to cloud technology.

What made you realize when you were doing this

full stack web development, what made you realize

that writing code is only part of the picture

and you wanted to dive into DevOps as well? Right.

So let me say this, that I found myself more

curious about modern methodologies and technologies

around code deployment and how applications scale

and remain reliable in production environments.

Yes. Very cool. being a developer to touching

DevOps stuff? Was it like networking, CICD, just

AWS, Linux? Like what was the part that you found

to be the hardest? Well, Brian, that's a great

question, Brian. How does LevelUp for me, I would

say, was familiarizing myself with key DevOps

concepts and with the stack of technologies that

come with it, i .e. source code management using

Git, package management using Docker, building

CICD pipelines. using tools such as Jenkins,

GitHub Actions, container orchestration using

Kubernetes, you know, mastering cloud services

on platforms like AWS, Google Cloud, and also,

you know, getting a grip on infrastructure as

code, you know, using Terraform Ansible, and

of course, implementing continuous monitoring

and observability with tools, you know, such

as Prometheus, Grafana, and things of the sort.

I must say that, you know, beyond that, tools

also another hardest level level up for me was

the shift shift in mindset all right the mindset

shift i .e you know moving from let me say i

know how this process works on my local host

to how how that same process behaves in production

at scale Now, that's a big jump. You know, that's

a big jump, which requires grit and a lot of

hands -on experience, hands -on practice, and

also a grip on the technology that you're working

with. Yes, Brian. Yeah, those are two really

good points. A, there's just a lot to know. When

you talk DevOps, that is just such a wide breadth

of tools and technologies. And then the other

side of it, yeah, testing locally, great, it

works. Then you scale that up to 10 ,000 users,

100 ,000 users, a million, completely different

complexities than you're going to have running

that locally. And things are going to show up

that you didn't even think of when you were down

in the 10, 100 early user stage. Exactly, Brian.

Yeah. So was there anything that clicked first

for you or were there things that took longer

than expected as far as like learning like AWS?

Because like speaking of like DevOps being wide,

AWS has a ton of different technologies and a

ton of different. ways of doing the same thing

so is there anything like in particular that

maybe clicked earlier or or was harder to learn

over time that's a great question again brian

i would say this that um what really clicked

for me was realizing that um devops sits at what

what what i will call the intersection of you

know software engineering and systems thinking

and business impact what you're doing ultimately

and largely impacts on business decisions. So

I enjoyed solving problems like, why is this

deployment failing? Or why does this service

degrade and that's a load? And how do you, or

how do we automate this so it never breaks again?

You know, that shift in mindset, just from writing

features to owning the process, owning the system,

owning reliability and delivery. you know actually

pulled me in yes so so that's it for me now brian

what let me add this that what didn't click for

me like you said earlier all right was the sheer

breadth and depth of new tools and technologies

i had to learn you know you you you are not dated

with lots of of of tools and technologies to

learn technologies in respect of cloud in this

respect of networking You need to know the ins

and outs of Linux, the ICD pipelines, observability,

you know, it can feel overwhelming, really overwhelming.

But early on, I tried to try to learn everything

at once. And that I would say was my mistake.

All right. You need to progress slowly. You need

to trust the process, follow along slowly. So

progress really accelerated when I focused on

the fundamentals and learned. by building, you

know, and breaking things on my home lab. Exactly.

Yeah, that's a good point. So yeah, just focusing

on one area and then building on that. Exactly,

right. So looking back at your background, you've

worked on enterprise grade systems for big organizations.

What changes when it's not a side project, kind

of like we talked about earlier, running locally

in dev, what changes between that and like mission

critical, like enterprise grade systems? Like

what are some things maybe you have to worry

about? um that you wouldn't in a local development

environment all right so brian my my first instance

in deploying a mission critical application was

a voting was an online voting system okay for

for a school cool and yes and you can imagine

that the system works fine on your machine And

then the moment you have to go live or go or

deploy on production, all right, the results

you are getting is entirely different. Users

are trying to access the system and they cannot.

And you know, elections are contentious matters

and that you cannot afford to let your users

lose trust in your system. And so for me, that

was a great learning curve for me. You really

have to be prepared for such instances that you

need to have some virtual environments where

you can literally test what you have built and

you want to deploy. So for some mission -critical

systems, I have been privileged to work with

teams that have deployed online voting systems.

We have deployed some enterprise resource planning

platform for institutions like the food. an agri

-organization of the United Nations, the Ghana

office to be specific. So that platform encapsulates

everything to make their business processes work

efficiently. So there are modules on procurement,

modules on human resource management, modules

on financial management and things like that.

These are mission -critical systems which you

can't afford to let them fail. Yeah. So for me,

they have been a great learning experience for

me practicing on or working on these systems.

Yes, Brian. So what did that era teach you that

actually helped you in DevOps now? Like reliability

mindset or like working with stakeholders or

like change management? What was the most valuable,

I guess, part of that? Brian, you literally mentioned

everything that was a learning experience for

me, right? From system reliability to change

management. It was a great learning experience

for me that for users, once your system is unreliable,

it's not available, it's not giving them the

expected results, they begin to lose trust in

the system. And then also the change management

process is very critical and very important.

There has to be user acceptance. be user accepted.

You need to tag them slowly and make sure that

they learn or they get comfortable with the system.

And so lots of sensitization, stakeholder engagements,

lots of consultations. All right, you run campaigns,

you run some communication campaigns here and

there to ensure that there is some... there is

user acceptance, all right? There's user acceptance

because no matter how good your system is, if

users do not accept the system, the system is

100 % bound to fail. Yeah, that's very true.

Very true. Okay, so switching gears, you posted

about your home lab on the go, which I believe

was a Mac mini. I'm just curious, why that approach?

Why a Mac mini? Mac mini, all right. So let me

just say this, that I purchased, This Mac Mini

just some time ago. And I said to myself, well,

why don't I just turn this into my home lab?

Dedicated specifically for practicing, you know,

and for honing my tech skills. So I own a laptop

and I also have this home lab dedicated specifically

to... practicing my, my DevOps skills. And so

with this, this platform, I am not afraid to

break things down. All right. For sure. Yeah.

To feel in the, make all the mistakes. All right.

To, to, um, what should I say? To make all the

mistakes that, that you need to make while, while,

while learning as well. Yeah. So this home lab

is, is dedicated. to help me practice my DevOps

skills and also to hone my tech skills as well.

Very cool. So are you doing like Docker, pipelines,

monitoring, like break -fix? Exactly. So just

last night, so I decided to containerize a static

version of my website. All right. So I Dockerized

the website, all right, built the image on that

platform. All right. I pushed that Docker image

to Docker Hub, right? And then I went on also

to run the Docker run command, right? So which

literally converted the image to a container.

And then I ran the application from the web browser,

you know, to local host port 8080. And that gave...

So I used that home lab, all right, to practice

writing of Docker files, all right, CICD pipelines,

constructing my Docker Compose files, you know,

building my Jenkins files. And so you would be

seeing a post for me very shortly detailing the

process that went through and containerizing

the static version of my website. Very cool.

So basically that home lab helps me practice

without guardrails. All right. Make the mistakes.

All right. Do my debugging in there. Build Docker

images. Run Docker images. Run Jenkins files.

You know, build my Jenkins files. Run CICD pipelines.

Push my image to Docker Hub. Pull from Docker

Hub. things like that. Very cool. Well, I'll

look forward to that post. And I think, I think

that just goes to show you that you don't need

fancy hardware either for a home lab. Just take

what you take, whatever you have or, or what

you've used previously, or, you know, if you

have an old Mac mini or whatever, you don't need,

you don't need like a big rack and stack server

set up. Like you don't need a bunch of fancy

machines. Exactly, Brian. Exactly, Brian. So

shifting gears a little bit from the home lab,

and we talked about this at the top too a little

bit, but I'm just curious. So we talked about

how the tools are endless, right? You have Terraform,

Kubernetes, Jenkins, Prometheus, Grafana, Ansible.

How do you choose, how do you personally go by

choosing what to learn next? All right. So this

has been my structure. All right. So I begin

with source code management. All right. So the

basics for me is very critical. You need to be

familiar with the basics. You need to have a

stronghold on the basics, which is Linux. All

right. So things to do with Linux commands, mastering

bash scripting are very important and very, very,

very, very critical because at the core of DevOps

is Linux. You cannot be a DevOps engineer. And

not no Linux. Linux is very critical. So I focus

on the fundamentals, which is Linux. And then

I move on to source code management tools, you

know, like Git. And then I progress into package

management using Docker, right? And then I progress

to CICD pipelines using Jenkins. So the idea

is how do I use automation, all right, to build?

the Docker image and then push it to a repository.

All right. Okay. And then from the Docker, from

the CICD pipelines and practice, all right, so

I move on to the cloud platform. All right. So

that now after pushing to the Docker repository,

all right, it has to be pulled onto your cloud

platform. Now we have cloud services also that

can serve us as your... your Docker repository.

All right. So the various cloud platforms have

services that can serve as, you know, Docker

repository. And then I move on to learning infrastructure

as code. All right. But in between that one,

so from Docker to the cloud platform, my process

would be to learn Kubernetes next. And then after

learning Kubernetes, you learn Terraform. Okay.

or infrastructure as code so basically terraform

ansible and then you move on to to to implementing

continuous monitoring and observability with

you know tools like prometheus and grafana gotcha

so so so for me that has been my structure well

some people have their structure. But for me,

at the heart of DevOps has been to learn and

show that you get the fundamentals right and

show that you have a good grip on Linux and then

you progress from there. And then learn the entire,

through the process, learn the entire pipeline

and follow it through. It sounds like, right?

Exactly. Exactly, Brian. Exactly, Brian. So what

are your thoughts on certifications versus like...

doing your own projects what do you think is

more valuable well for certifications let i would

say this that's a very dicey dicey matter yeah

it is that's a dicey matter right well here is

it hands down i'll see real projects would always

make the big difference for anyone right certifications

and courses will help build structure but running

real you know, setting up CICD pipelines, deploying

to cloud infrastructure, breaking things, monitoring

them, fixing things, you know, that's where everything

clicks. That's where everything clicks, yes.

So certifications help, all right? Like I said

earlier, certifications and courses would help

you build structure. But, you know... Hands down,

I would say real projects would always make the

big difference. Real projects and hands -on projects

will make the real difference. Because you have

to fail, right? You have to learn to fail and

be okay with that. You have to learn to fail.

You have to learn to fail. You have to learn

to fail. For me, there have been several times

where I have just tried to organize a Docker

Compose file. as basic as getting it to run successfully.

Brian, and it's been a challenge. And so I put

that file down, go to sleep, come back the following

morning, and it starts to end. And surprisingly,

things begin to click for me. All right. And

then when you realize that you made mistakes,

oh, I made the mistake here, I made the mistake

there, I made this mistake. Just two weeks back,

all right, one Docker Compose file that I wrote

just wasn't working. Only for me to realize there

was a dash, a dash I had introduced somewhere

that shouldn't have been there. And it's been

a great learning experience for me. So I would

say that hands down, real practice and real projects

would always make a difference. Yeah, I agree

with that. I think, yeah, I think certifications,

boot camps have their place, but as a foundational,

a structure school, same thing, but you need

that hands -on learning. At some point you need

to actually dive in. be comfortable with failing

because that's okay. Like, you know, it's okay.

You're going to stumble a little bit and that's

okay. So wrapping up a bit, what's one piece

of advice you would give someone trying to break

into DevOps in 2026? Where should they start?

What should they do? All right. So what I would

say is this, that let me say this, that I would

just say, focus on depth and not hype. Focus

on depth and not hype. So I... I have found out

that employers, you know, care more about how

you think and solve problems, right? How you

think and solve problems than knowing every tool

there is, all right? How you think and how you

solve problems, all right? Because at the heart

of that all, that is what DevOps really is. Simplifying

things, automating processes, and then shipping

code faster and efficiently. all right and so

how you think now my my my other advice would

be this that consistency would always beat intensity

all right that consistency would always beat

intensity you don't need to learn everything

in three months you need to show up steadily

all right you you need to show up you need to

have a routine if you tell yourself that you

would dedicate two hours each day to learning

devops do that You need to show steady progress.

You need to build. You need to document. You

need to reflect. You need to repeat. And it's

okay to fail. It's okay to fail. Do this repeatedly.

And I would say also that slow down and be consistent.

You don't need to master everything overnight.

Just show up. Build something small and keep

going. And also one thing I would say also would

be this. Learn to share your journey, all right?

Learn to write, learn to post, learn to talk

about what you are learning because it's only

through that process that it reinforces your

knowledge. It creates visibility as well. And

then opportunities often come from when people

see the way you think and not just what's on

your resume. The way you think, the way you solve

problems, the way you handle challenges. That

would be for me, Brian. Yeah, I agree with that

a lot. All right, so where should people follow

you and what should they check out? All right,

Brian, so people can follow me on LinkedIn and

then also my personal website, which is ericpatty

.com, ericpatty .com. I'm also on Facebook and

also on Instagram. And so I'm primarily on LinkedIn

and I have a website, ericpatty .com. Yes, Brian.

Awesome. Appreciate it. Well, thank you, Eric

Pate, for coming on and being on Ship It Weekly.

I really appreciate it. Thank you, Brian. It's

been great. Thank you. All right. That's the

interview with Eric. Quick reminder on the format.

Ship It Weekly is still the weekly news recap.

And I'm dropping these guest convos in between.

If you want to catch both, hit follow or subscribe

wherever you are listening. And if this episode

was useful, share it with a coworker or your

on -call buddy and leave a quick rating or review.

It's annoying how much that stuff actually helps

the show. We'll be back next week with the regular

news episode. We'll see you then. Thanks for

listening.

Ship It Conversations: From Full-Stack to Cloud/DevOps, One Project at a Time (with Eric Paatey)

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

More from Ship It Weekly

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

Get the next episode in your inbox