Hi everyone. My name is Patrick Akio and if
you're interested in devops SRE kubernetes and how those all fit
into effective teams within an organization than this episode
is for you. Joining me today is none agenda.
She's a teacher YouTuber CN CF Ambassador Docker Champion, AWS
hero. All those accolades.
She got by helping millions of people enter the devops field
and get really good at it. I'll put all her socials in the
description below. Check her out.
And with that being said, enjoy the episode.
Do you make the visuals for your own channel?
Do you make them this yourselves as well?
Yeah, so it's two of us. So made my friend.
She does the, the post editing of the videos.
Yeah, including the animations and some nails and all this
stuff and I'm the one who does who says, okay, this color
scheme is fine or yeah. Like that thumbnails, kind of
chooses the, the last one. But she does actually, like,
almost all the visuals. That's really cool.
And you two started from the beginning because I didn't
realize that actually looking into your videos.
Yeah. So We were both working as
software Engineers actually in the same project and on the site
of like freelancing on that software engineering project, we
are actually working on a start-up which was like
completely different things. Like in the real estate industry
like writing something for for like digital online, broker okay
thing for rentals. And then this YouTube channel,
Canada be was like us. Super side project like that.
I just started because I want you to have some video content
on communities because I learned a lot about kubernetes and it
was like a lot of knowledge has scattered in notes and stuff.
So I basically decided to have that in a video format so I
could re-watch them so I can refresh my knowledge, he's
future. If I needed to and if my startup
failed and nothing anyways, like not a success and I had to go
back. Are you insane?
Like, my fresh, my current, his knowledge that was the idea of
the YouTube channel? Well, that's that's so simple
and it's genius. Basically, because a lot of time
like if especially, if it's new and you don't use it, you teach
yourself something and you don't use it more on a day-to-day
basis, you're going to have to refresh like that knowledge,
right? Because as soon as you use it
day to day, it's going to be inherent.
It's going to be second nature and as soon as you stop using
it, you're like ah what was this thing again?
And you're going to need a refresher is exactly.
Lee what a YouTube video would be then.
Yeah. 100% exactly. But really cool that you're
doing it together with is it friend.
I'm assuming it's a flower, a colleague in that way because
I've seen the visuals especially like one of the latest videos.
I think it was probably beginning of this year or late
last year where you talk about how to actually start a career
in Tech because there's various roles, there's various
responsibilities. Obviously if you're new, you're
going to have to see what you like and what you don't like,
and it's a whole lot and I saw the I saw some of the tracks
that you laid out also on the website and it looks very cool.
I love the visuals. Yeah, thanks.
I will also forward the pediment to her because stuff and do you
do the trainings together with her as well or is that all, you
know. That's so we have splits that
part. So we basically have no overlaps
almost when we work together on this video.
See ya. So I have the knowledge in
devops. So she even though she has a
background in software development like she doesn't
like devops at all like, She would never do that as her job
actually. Yeah, I loved it works, right?
So I actually started like learning all this stuff and her
like she doesn't have any interesting to any of these
different Technologies. So she took over like this
complete post editing animation stum nails like doing the
YouTube analytics and all this stuff.
She helps like in like researching the topic.
She does also a lot of social media together with me like on
our link Page and so on. So all of the things around, but
the research and creating the content itself like that's all
on my side, which I actually love to do way more than the
other stuff. So which means it's like super
great pleasing for me that I have actually someone who does
all that Parts where I don't have to worry about.
Okay, how the video is going to be animated after that?
I can just focus on the content itself.
Yeah. Yeah.
I love the Synergy in that aspect.
I mean, I know you love Devops and it's all over your channel,
even with the tools and using the tools in a great way,
instead of just making stuff work.
But how did you get into develops in the first place?
Could you kind of go over that for our audience?
Yeah. So as I said, I started with
software development and I actually for the first probably
two years of working as a software developer, I had no
idea about anything related to cloud or devops.
It was like, I remember in the, in the first project that I was
working, I was actually Turning in.
They had like we had we were this big or the largest software
development team and then we have this tiny teeny Cloud
Department which was like one guy and one intern.
Oh well. So that was the that was a cloud
team basically. Yeah.
And we like all of us were like, oh, they're doing something with
Cloud, right? So that was like, my take on
cloud and my impression. So I just continued with
software development. And I try to, I try to actually
do a lot of various tasks within the software development, like
doing the front-end back-end, different languages and stuff.
So I discovered actually that I like the beckon part way more
and then like I joined the project where we used a lot of
different Technologies like it wasn't actually an iot project.
Yeah, so we had the hardware components.
We had the mobile application. The Android application for it.
The web application front and back hand doc arised.
So some very different parts and it was actually an amazing
opportunity for me to try out different things which I was
like, super curious. Like how does this work hard?
We're blocking an interesting. How does talker work?
Oh, that sounds interesting. And then things like Jenkins set
up. So like just by switching the
between those different tasks like the types of tasks.
I actually realized like more and more.
What kind of things I enjoy doing?
And there was like, configuring stuff like I would enjoy take
it, like our web bills and optimizing it or make it faster,
right? So for example, our build was
like, super slow, he took 10 minutes to start test.
Whatever. I was like, oh, I'm gonna look
into it and optimize that. So it takes one minute instead
of 10. So, I like doing this kind of
stuff and then, and again, at this point, I have no idea.
Yep. Devops like, I'm just doing,
like, things that I know that are part of like, software
engineering, but I just love to do more than like sitting in
coding. Yeah.
And then the, the next project was we're also joined as a
software engineer. I actually took over kubernetes
Club setting up kubernetes cluster.
Okay figuring all this stuff. So that's where that was the
first entry into this thing where okay.
I think I want to do is this full time and I was actually
doing full time only kubernetes. Okay?
Like that, not even like see ICD pipeline or anything.
I was like full-time setting up, kubernetes, configuring like a
hundred different things in Services inside Integrations.
So correctly was the entry point and then the other develops
Technologies. I love that.
It's very much similar to my own experience where I was in an
environment where I got to try out a lot of stuff.
Figure out what you like and figure out what you don't like.
And I think that especially early on kind of in your career
path is so valuable because that's gonna like allow you to
focus on what you actually like and grow towards that and grow
really fast in that. But you said kind of kubernetes
was your first experience in that but I'm assuming you didn't
have any prior knowledge to kind of being responsible for a
cluster like that. Did you teach yourself with
things on the Fly? And if so, how do you do that?
Yeah, so my my very first experience carbonated there was
not actually the first one, okay?
So what, so what happened is that in that project that I
mentioned, where we had everything dr.
Eyes, we didn't use kubernetes, right?
And again, I hit this like curiosity that I wanted to learn
like as much as possible and also, like there were more in
the direction of like infrastructure, management and
coffee great, configuring stuff. So, So, my idea was that I
wanted to learn AWS. Yeah, alright.
So actually, I remember, I went to my manager and I said,
actually want to take switch from full-time to like, 40
hours, to 3:30 hour week job because I want to take like one
additional day, like, except for the weekend to actually learn
things that I want to learn, right?
So not something that I learn a job because we also had created
this project and it was a maintenance phase.
So I wasn't like learning new stuff.
He was like just maintaining fixing bucks for the customers,
you know, this kind of stuff. So it was not interesting
anymore for me because we weren't doing anything new.
So I was like, I just need one more day in the week to learn
things that I want to learn and that's going to be like 80s.
And then my manager was like, okay, so what exactly you want
to learn and I was like, okay, aw, yes, blah blah, this setup
stuff and they actually offered me.
They were like, you know what, you can Intake that day and
you're going to still have to be employed with us like 48 like
full-time. So where you going to pay for
that as like, you know, upscaling of our employees.
And I think I was actually the first one in the company who,
who was doing that. Yeah.
So they were like we anyways want to test these out to kind
of give our employees like one full day to kind of self develop
and learn whatever they want, which is going to be like
eventually variable for the company.
So and then my manager was like, okay, So obvious is great.
But there's one more thing that I would like you to learn that
our customers may need in the future which is kubernetes,
okay? Ladies, okay, yeah, whatever,
why not? So that was actually so it was
his input and that I just I think over the course of like
six month or so. Yeah, every Friday I would just
learn AWS and kubernetes and I also always say that in the
videos as well. Like how to learn new stuff,
right? Right?
So I didn't want to just learn something like let's go through
all the aw services or kubernetes, you know.
So I was like, okay what is what is the project that I can
actually take and use to learn these?
Right? So I took our do caressed
application as an example and I was like, okay I'm going to take
this and I'm gonna deploy that to communist cluster on AWS.
So that was like a perfect project where I could just
practice both cos it was super painful and challenging because
imagine you have This half iot system that is like, hesitant
Integrations with this Hardware components.
Yeah, you take these and while learning kubernetes and while
learning AWS, and I think back then, if I remember correctly,
there was no community service on AWS, okay?
Actually configured everything from scratch.
So I just rented the, the servers and I had installed the
stuff like with chaos or something.
So it was a little bit more difficult.
Yeah. And like if every Friday I would
just work on it and it was it was super interesting and fun
doing it based on that project that actually has.
Yeah. And I remember like at the end
of six months or so, I actually managed to, you know, to have
the the images of those containers on the ews registry
and then actually run them in the cluster which was like super
impressive for myself and for the team as well.
Because I think there was actually a And for the customer
to ask ask us to actually deploy those stuff in the kubernetes
cluster. Yeah.
So that was actually my first experience with kubernetes that
is so cool. I mean, the the sense of
ownership that must have had, or even, even the fact that you
went to your manager and said, listen, this is what I want,
right? This is what I want to grow in
and willing to take less time and less pay because of that
just to teach myself those things.
And obviously props to your manager, in the company, for
being like, no, no, no, we can do this and it can be a win-win
as well. Anything you have to do is then
also like, look into kubernetes because we expect this to be a
bigger thing good for them because they were kind of,
right? Because kubernetes is still
tried and true in that case, segment evening.
I would like, I'm so grateful know when I think about it,
because it was like, literally the start, like, yeah.
Why don't you just try and learn communities?
Yeah, yeah, really, really cool. Super cool.
And then obviously a lot of stuff now is more manage than
and more service towards which makes sense if something is
established and Ws. And even the other Cloud
providers are going to make it more easy for you to run your
stuff on there. But back then it must have been
very bare-bones. Setting the setting everything
up and even iot and Hardware is not the not the most easy domain
to be in in that aspect. Which is really cool.
Did you? Yes.
So there was go ahead. Was also like the that
challenging part was also like super fun for me because I
remember that like more. So the process was that I would
learn like, this AWS services. He sees that would learn
kubernetes and how it works. And I would like sketch and
design, like, how to map what we had like, this Sakurai services
in each service had like different requirements, right?
Like storage requirement or networking requirements, which
were different. So how do I actually put them
there and connect them together? So I would like do this.
Select Solutions, architect kind of kind of things and decide and
that was like the the fun part of it actually, awesome.
Did you get kind of Guidance through that as well or were you
really just thrown into the deep expecting to teach yourself a
lot of things? Yeah, it was like super, like
completely Lee. Well, I was just doing whatever
like I would, I would learn and give to get even put and then I
would just sit down and kind of brainstorm and id8.
Okay, how do I fit this Parts together?
Yeah, then I would go and research more and then I would
go back and try to put more, like, more pieces together until
I had like this complete picture.
So it was like a and he was, it was difficult also because it
was at a very, very early stage and they was like Very little
information out there like on online.
I could never find like straightforward answers to any
of my questions. Yeah, like troubleshooting like
something went wrong, like it was just trial and error because
I could never find the appropriate answer like to that
specific issue that I had online because he was just, I would
find questions where, like somebody was.
Like I have exactly the same question but it was like not
answered at all. So that was also challenging
part because like if you are Programming great like no doing
Java or whatever. Like you would find tons of
resources on it right online. So that I also made the ceph
self-learning part a little bit, a little bit more challenging.
Yeah, I can imagine. I mean, that's really kind of
the fact that you were more so trailblazing, right where
everyone is going to having the same issues.
But the answer, the one final answer is not really out there
yet until someone figures it out.
And then shares it, it's really a stage of like an early early
on technology, I guess. And the adoption there.
What? I, what I wonder is because I
started out in operations more. So before I did software
development and with the tools that you use in operations, you
really want resiliency, right? Because this kind of piece of
product or this product is going to run for a while.
And if it is flaky in any sort of way, or if it's not as
resilient, people are going to get calls or alarms and are
going to be expected to like, bring this thing live again,
when it goes down, and stuff like that.
And I think that's especially challenging when you're kind of
adopting a Technology, which hasn't been established as much
yet. But also, when you're teaching
yourself things, right? Because I mean, from a, i can
get this from a software engineering point of view, if
you get stuff running, sometimes, that's great.
But sometimes in an operational sense that might not be good
enough, right? Because running is one thing and
then it also has to be resilient and you have to have it
configured the right way and then even what is the right way?
What would you advise for people that are kind of figuring those
things out? Is it more?
So is the information now. Established yet?
Is there more of a guideline year in?
Things up more. So or how do you reinvent the
wheel in that aspect? Yeah.
That is a really interesting part especially like, with the
with the tools that are new, right?
Yeah, and especially when you do Integrations of multiple tools
like that, like, you increase the security risk because you
may do like, a Miss configuration in the integration
part that will expose your whole cluster or whatever like
application setup. So, that is, especially
interesting in the, in the new tool scenarios.
So, Like in my learning process and then how I then kind of
transfer that into my YouTube videos, it was interesting
because so I had this self-taught knowledge and
kubernetes, right? Yeah.
And then I had, when I joined this project, where did like
full-time kubernetes, it was like Hands-On but building an
actual cluster for like production, right?
For a really important project in these huge company.
Yeah. So that was like a different
perspective of like I'm not just learning stuff myself and, you
know, Kind of test creating a demo cluster.
Like this is really like, this has to work in production, like
with the things that you mentioned, right resilience and
stuff. So there was another perspective
and I would, there was for me, was important to get the input
from different teams. So I would actually work right
in the middle of software developers and operations
Engineers. Yeah, and it operations staff
that they were actually the ones with Knowledge in terms of how
how the cluster especially underlying infrastructure should
we should work. So kind of the ideal case of how
the cluster should be configured.
The developers just wanted things.
Like I just want a database. Yeah, run with these
configuration so I can connect my application, right.
But it operations guys were like, okay, so we want these
kind of monitoring, we want to see be able to see someone that
the applicant the application developers leaked, any Add data,
and it's logged in the console. So things like that, right?
So I'll get input from this experience engineers and then
okay, how do I now configure that in a component is cluster,
right? So that was like, my additional
knowledge input. For what are the best practices,
like what things need to be configured generally.
And now, how do I configure that in kubernetes?
Right? And then additional step to
that. And it was also interesting,
that was like the next phase. So to say was okay, what are the
His best practices themselves, right?
So, how do I secure the cluster itself?
How do I, you know, make sure the resilience is there.
Yeah. Using the controls.
The Koran is gives us. So it was like a lot of phases
of you know, like suffering and then getting this best practices
of generally, how the setup should look like and then how do
I met these two specific technology, like kubernetes.
So it's I don't think. There's like a shortcut or easy
way to do that because you have to like, go through the stages,
I think. Yeah, I really like that.
You leveraged kind of, I mean, even in learning the production
experience that you had or the production experience that you
were going to have in setting up that thing in production
basically with the knowledge of both the operational side as
well as the development side in what needed to be there right
there, the actual requirements and then looking into the best
practices of how to kind of fit those requirements in the tool
that you're using, which then at the time was kubernetes.
I think that's A really cool combination of kind of a factor
to fit in what you were doing more daily.
But since I mean, I don't know what you do, more on a
day-to-day basis, this was more, so the experience in the past
but now that you're educating people more and you're even
training people more, do you still have that same kind of
production level experience that you take with you or that same
kind of level of input because I feel like the more you move
towards trainings or even content creation, the less you
move or the more you move away. Also from them production
experience Yeah, that's that's absolutely correct.
And yeah so that happens automatically when you kind of
have less time for like working on actual projects and you go
into teaching. Yeah.
So there would like, first of all, like I still have that
Curiosity that I had before in terms of like learning new stuff
and OKC where the trend is going right.
So for example, things like multi-cloud and or Crowd cloud
and the developments in this directions.
So, what I actually did for a long time, I think like the last
year, almost a whole year, I had projects.
So I would take actually Consulting project.
Yeah. So Consulting projects where I
would work with it team that had like kubernetes and they had
like some some issues or usually would be like a maybe software
developers team who Had to take over the cluster management, you
know, take doing the creating the devil's processes.
So, take on these kind of projects where I could
contribute of course like you know, help them set up the
current cluster, the, the cic processes, Etc, but also learn
like, how do different companies use that?
Like what is the purpose? And how do they try to implement
kubernetes to achieve those goals, right?
So I always Try to have that. Accompanying consulting job and
especially when you do Consulting and you don't like to
like eight hours of troubleshooting, something in
the cluster like yourself, and you kind of go on the higher
level, you have actually more time to look at work projects,
right? Yeah.
So you actually have a little bit of advantage of comparing
like different different, you know, it projects.
Like how does this project use communities?
What environments do they have? Like what What other tools are
they using, right? So you kind of have this, okay?
You're helping but you're also getting input and knowledge from
them. What I also did that was
actually super important for me when I actually started creating
videos on in siebel and terraformed account.
For example, we've ends will actually reached out to the
ansible team or we had a connection.
Then I, then I kind of followed up.
And I was like, like, I have this questions about ends equal
and it was, it was The the same thing that we talked about so it
was like I can use ansible and this I know like all this stuff
but what I'd like the best practices of doing this.
Like am I doing this right? Is this configuration correct?
Or is there like a best practice of doing that?
So I I send them questions and so I would actually talk to the
teams of developers to get from them like the input.
I will talk to other Engineers that worked at large companies
to get their input. Like how are you doing, like,
Like how for example, there was a company that used devops and
Sr e. Okay, in one team.
So I was really wondering the like how large companies
actually divide the tasks between those two roles and
like, how do they manage the combining those.
So I would actually just talked to engineers and get like these
kind of input from other companies using this stuff so it
is Looks like I'm still trying to learn as much as possible.
Yeah. And to kind of collect Knowledge
from multiple companies and the kind of condensed that in 1
plus. Additionally, like the, I don't
know things from official documentation or whatever out
there and then kind of repackage that and kind of put that in
YouTube videos. Yeah.
Paying it forward in that way. Yeah, I really like that.
I mean, the hard part, and I think the challenging part
looking from an outside perspective, Point of view is
like, oh I need to know all these things or I need to like
accommodate for all those things.
But even the way you explained it now you just share and
collect information right? And I think collective
intelligence in that way leads to then best practices, right?
And obviously best practices in combination with actual
practical experience or requirements is then going to
lead to the best end result. And I love that you first of
all, gather that information leverage your network that you
have or the different projects that you do consolidate that and
put it in a nice package too. Forward for those people that
are going to come behind you. I think that's really cool, but
thanks, thanks. There was a very good summary
over very short. No, no worries that that's my
job as podcast hooks. But for me like, I last year,
I've started teaching teaching people more software development
in specifically go as a programming language.
But what I've learned is that first of all, I love go which is
kind of where my love for teaching.
Also kind of sprung where I Is like, okay, I want to teach
people this but now that I've done it once or twice and even
Thrice I'm like okay this is kind of more of a routine and
it's not necessarily about the material anymore, it's more so
about the interactions with the people, their perspective on
things or the things that they challenged in a way as that also
kind of been your experience because you've switched and
you've done more with teaching rather than actual Hands-On
production experience. Yeah.
So the like, one thing that I love about that part the
teaching part. Yeah.
And Had this like, from the very beginning like from the very
first videos that I made about Docker and Cooper especially
kubernetes and even now. So that one thing is that like
let's say there was, there was this fear around kubernetes,
right? Like what are these careers
components? Like they all sound the same but
they're like, super difficult. So for me, the most exciting
part of creating those videos was creating the content where
someone who had red light Like hundreds of blog articles and
maybe the whole documentation even works with kubernetes and
had like, these chaos in their mind, would watch the video and
be like, oh no, that's how it works.
You know, like yeah, have those those aha moments like in the
video and I absolutely love that.
Like when I know, okay, they're like lots of unanswered
questions about some topic. Like I don't know things like
what is the difference between devops engineer and SRE, right?
Yeah. So I would I would actually
search a lot of Articles look articles and I would like try to
notice what is missing in all these articles.
Like what information is missing that I know that a lot of people
would have liked that I have and then I would basically just work
on that on delivering that information in my videos.
So I kind of know that I'm Answering the questions that
they can't easily find on internet.
You know very specific and understandable way and that is
still what motivates me actually to in every single video.
I want to have those, those kind of pieces.
So they say yeah no I mean for me that is 100% recognizable and
and I can compare that to the episodes that I do with the by
cast because I'm in the driver's seat, right?
When I'm like interviewing or talking to you.
For example, I can ask the questions that would interest
me, which I hope also. The audience would have kind of
the same question. Us and for you analyzing
different information that is out there with the lens of.
Okay, but what what questions do I still have right?
What is still unanswered and then finding a way to answer
that for the people that tuned in.
I think that's, that's really cool.
Like, that's also obviously recognizable because that's kind
of the reason why I started this podcast.
And I think that helps with motivation.
That's always helped me with motivation.
If I do a topic, which just doesn't interest me, I did a Q&A
episode and people were like, how do you, how do you come up
with new topics? I'm like, Only because they're
interesting. Do I do them right?
If they're not interesting. And the most boring example I
could come up with was like pouring concrete yet, then it's
not going to be a good. It's not going to be good
episode like this is not gonna fly.
I think that's that's very recognizable for the people that
have done. That one of the questions.
I mean, I have this in my head because I still kind of struggle
with the concept here and there is the thing that you mentioned,
what is the difference between kind of devops and are sorry
because I saw those terms devops first, an SRE kind of later and
some people are Joining them in one team and some people are
keeping them very separate. What are they?
Are, they separate, should they be joined?
Like, how would you explain that to people that are kind of new
with those terms? Yes.
So, that the brief explanation, actually, I was one of the
videos where I deep the most research, okay, there's that.
And the problem was like exactly what you mentioned like and I
think the reason for the issue is because they're like a
relatively new. Yeah.
So a lot of companies just don't know how to define a line
between them, right? Even like line between devops
and development. For example, like, in some
companies devops is doing the operations part, right?
So like a lot of their lot of Mix-Ups there.
Yeah. So when you and when I was
searching for this online, like doing the research, like all the
information was like, very general, and it was like, kind
of people were afraid to like specifically Define the, the
line between them. So, I did actually lot of
research research including like, I was, The interviews and
content from the creators of SRE, like people who actually
came up with the concept and how they actually defined that, plus
the the the devops, and then how it's actually implemented in the
practice, right? Because that could be a little
bit different from how the original idea was.
Yeah. So shortly explained that's my
view. Is that devops is actually more
on the development side, and Sr has more on the operation side.
And the reason why I think it's absolutely Shit image, have
those two separate roles even though they have overlaps and
they may sound like they do something is because like, when
you think about devops, right? So, you have to have
development. Understanding, you have to
understand this whole development life cycle, you
don't program is a devotee engineer, but you have to
understand how developers work you have to work with setting
up. The holes is eicd pipeline,
which is already a huge part, right?
To get that completely streamlined.
In automated then have the infrastructure part.
So if you're on cloud like you have to be knowledgeable with
AWS Cloud, for example, right? Whatever Cloud, you're on.
And then on the infrastructure part we have the kubernetes
which as I mentioned, they would like a full-time job, right?
Just to do kubernetes. So you have so many things as a
devops engineer that you have to know.
Then now, when you go and say, you know what, you as a divorce
engineer, you also have to monitor the deployment and you
have to do the operations part. It's just too much, right?
Yeah, so I think that history is like a perfect addition to take
over some of the stuff that they books engineer would like,
possibly not be able to do and should not like there should be
some limit, right? Yeah.
So it's kind of adjacent role that kind of takes over the in
focuses on the operation side, but obviously, there are lots of
overlap, so that, right, so they have the same objective, which
is the application should be Be released fast and it should run
reliably and the underlying infrastructure cluster
everything should be reliable and that's kind of a goal of
both of them so they can take like their own Parts but work
together for the same objective. So I believe that in especially
large projects, you should have both roles actually, maybe with
multiple engineers in neutral interesting.
I didn't look at it through that lens that the devops side is
more like adjacent towards the Up inside and the SRE more.
So towards the operational side. When you look at kind of an
organizational structure or even a hierarchy in there.
What I've usually worked in is more so feature teams and
luckily, in those feature teams, I've always had the privilege
that we use a lot of managed services, so the operational
overhead is not as much, right? If you use a lot of like Cloud
run for example, on Google Cloud platform, you don't have to set
up your own kubernetes cluster and instances, just scale as you
just increase in traffic in that way.
Which means your No overhead, consciously is a lot lower.
So we've always done then the software development side, as
well as the operational side just by the virtue of
operational. Overhead, not being a lot, but I
could imagine that if you take that with you and you really
want to fine-tune an optimized for that, especially in your use
case of iot. For example, then the
operational side is going to be a whole lot more more so than
being able to fit in then that same feature team.
But how would you structure then?
If we have, for example, a development department and an
operational environment, should they Should those be the same?
Should the devops kind of knowledge and a sorry, knowledge
fit within the same feature team or what have you seen that kind
of works well together in that way.
Yeah, so in the future teams is definitely the the best thing is
that you have different roles in one team.
Yeah. Because like when you think
about it, do developers have to work with Davos engineer.
Developers also have to work with a sari and in fact, as like
original idea is that SRE should do their job.
Like, if they, if they do their job, well, they have less work.
So if they automate stuff In the, you know the application
setup in everything is running properly reliably and everything
is automated then you know a sari has less things to do.
Right. Yeah.
Because everything like the monitoring is already running.
If something happens they will get notified but what they what
do they do? Meanwhile so they can take up
the developer role, right? So they can actually program and
become part of the development team now.
Yeah. So I think it because you have
this kind of combinations, right?
So Um, I don't know, test Engineers have to work with
devops Engineers because they are really important part of the
whole Ci City pipeline part, right?
You have security Engineers. For example, they should, you
know, provide inputs. And make sure the cluster is
running properly. It's secured or multiple levels.
The infrastructure is secured. You have the security checks in
the pipeline, right? So like what do you think about
this roles the tasks of these roles?
Everything is kind of intertwined, right?
So it makes Makes complete sense to have these people working
together instead of having like, department of justice re and
Department of just these people because then you would have
still have that overhead of mixing up people and have, you
know, having them communicate with each other.
But I think it's just easier when it's project-based look
like feature teams where like everybody, everyone has the
knowledge of what the other people are doing in the same
project. I think so, as well, I think the
best teams are with a shared mental model, right?
And if your team needs to just put out, a lot of software needs
to land in production, needs to be resilient and obviously you
need to see what's happening over there.
They you need all those aspects in that same team although as
you can't do it by otherwise you would be glued to another team
who picks up kind of those operational responsibilities and
that that doesn't make sense because then as one team you're
going to be misaligned with another team and you can't
really do something else without that other team.
So then, are you really at all? Thomas in that way.
Not really. So I really like that.
You also mention that the knowledge for whatever you're
doing should be within the team right in isolation, to make sure
that you are autonomous. In that way, I also in this is
more. So my personal prep experience
have heard from people that are more labeled as Cloud Engineers
or platform Engineers or what have you can pick any label in
that aspect that, they like that experience.
More being within the feature teams seeing kind of what goes
on there, instead of being kind of taken out.
That context and putting like being put in more of a platform
specific team but then on the flip side also online I've seen
that that also works where you have platform engineering teams.
For example, whose goal is to make a platform which kind of
functions as a product for other developers, then for the to make
their work better in that way. So I don't know if there's a
goal, I see. Like I can imagine the the
separation working for platform Engineers or Cloud Engineers
specifically because Like there's a little bit more
separation there, right? So they there do their job like,
manage and create this reliable Cloud infrastructure, maybe they
do like some migrations, something, like a lot of the
tasks could be that is not directly related to the
application itself or the project and could be like, for
the whole company, right? Where lots of applications can
can actually use the same Cloud environment.
So that would that I would say did this is like one of the
roles that I Can imagine can be like its own department, but at
some point like like when there is a overlap of, okay, so you
know, Club engineer has to configure and manage the
kubernetes cluster. For example, on AWS, they still
have to work with software developers and like, specific
project teams. So again, there's like a lot of
advantages of having them in the future team as well.
Yeah, I agree. I mean, even even I'm now so in
an iot projects. Oh, I like that.
You mentioned that. But the the way we solve
problems, right, we can do that in different Avenues and if you
don't have the respective knowledge of the different
domains within the same team, then you're going to always
solve it in the way that is within your domain.
Like, if I'm a software engineer, I'm going to do stuff
that is programmatically more accurate or to get stuff done.
Whereas, if I have a cloud engine next to me, he can
challenge me and be like, oh, maybe we should put that in
terraform, right? And both are going to have pros
and cons and it's really going to depend on our use case.
But if that conversation doesn't take place, even if those teams
are separated, Then everyone's kind of doing their own thing
and you don't really have standardization.
You don't have that knowledge. You don't have cross pollination
with regards to the knowledge sharing in that way.
So, yeah, lots, that's an interesting.
That's a really interesting point actually.
Yeah, yeah. So I, that's more of a personal
learning that I've seen, but also, I don't know if you, if
you saw any of this, when I Google devops and especially
lately, I've been a bit more on Twitter.
I saw loaded t, a lot of terms related to platform engineering
saying that develops dead or a lot of YouTube.
Videos being obviously jumping on that and being like, who is
devops did, what is kind of your take on that?
Because I do think more and more companies are trending towards
platform engineering, so kind of reduce their operational
overhead. But then Yeah, I mean I don't
think I mean, I think that the if this trend continues, which
is going to be good, I think they're whoops, Engineers will
not be like Devils engineer will not be dead, but that most
Engineers maybe can breathe a little bit more because, but
like a part of their responsibility can be like
distributed and taken over by another role.
Yeah. But they still would have like a
large set of tasks. They still like, would have Do
so I think it would just be like, okay, they have are less
workload, right? So they can actually concentrate
slyke on smaller set of tasks and and kind of do that.
So like generally, I don't think it Devil's is going anywhere for
the next year's because like, and that's again, based on the
input that I have, you know, seeing all the companies and
hearing about the project is that a lot of companies are
steel. Very far away from like having
the super nice streamlined process automated process.
Yeah a lot of things are still being done manually and that's
exactly like we're devops brings the most value.
So I think like when you think about the benefits of having
this automated processes, I think companies would still want
to do that. And a lot of a lot of the things
that devops engineered is doing specifically is not part of
platform engineer, or cloudy, Engineers job.
So that That's the reason why I think that works is actually
gonna, you know, either stay demanded as now or even even
become more demanded. Yeah, I like that as well.
And even even let's say we're in a world where a lot of stuff has
an automated, then that will probably bring new challenges in
the devops role. What kind of morph into solving
those challenges than right? Just because something morphs
doesn't mean you don't move with it.
That's kind of the whole thing in this Tech landscape, which I
enjoy as well. I've one of my final questions
was, I did a lot of research on you, and I saw your CNC have
Ambassador. I think it's AWS Champion, or
hero, and Docker Champion, our hero, but we're those always
liked those goals that you set for yourself and then you
achieve, or are those more buy products because of the things
that you're already doing. Yes, they were 100% by-product.
Yeah. Right.
It was okay. Then this will be actually
funny, but I actually didn't know these titles.
Existed, I remember, I remember seeing content.
Of one of the docker Captain's. So that's the title.
I was like, wow, that's a clever name.
I actually thought that that is also concrete.
I was like, wow, that's a cool name.
And I actually thought he was like the the made-up name of the
content creator. So when dr.
Reached out, actually Duncan was the first one to reach out and
they were like, yeah, we would like you to be a doctor kept and
I was like, oh it's a title, you know you can get forever
producing content on the technology.
So I was Obviously like super honored and flattered because
like I had been using Docker for a long time and then AWS reached
out and then CN CF. And so he was completely like
by-product it even if I had known about them, I think it
still wouldn't have been my goal because the same way.
Like, for example, sure like I would would have wanted to have
like 100,000 subscribers, you know, 500,000 subscribers, but
even the subscriber, Count was not like my goal, right?
Yeah. So it was more like my goal is
like as I said right for every single video that I produce or
produce, I wanted it to be the most unique, right?
So the information that you get here, like at least like 20% of
the information you cannot get anywhere else because it's like
condensed like I don't know processed so that was my goal
and the And then I would just check like analytics once in a
week or once in a month to just see the growth, right?
So we still have the growth, and then at some point, we're going
to reach half a million subscribers.
At some point, we're going to reach 1 million subscribers.
So those things like are usually not Michael's like things that
are like more measurable. Are not my God.
I mean that's honestly that's what I was hoping for just based
on how this conversation flowed. I feel like you have such a
drive that that would never be towards a statistic or something
that's measurable, but more. So about like a curiosity or
kind of an insatiable thing to be really good at something.
And then obviously, the way you pay it, forward has a lot of
byproducts that come out of that.
So I'm really happy with that. Yeah, any also, Takes a lot of
pressure off you, right? Yeah.
Is it Creator? Because when you decide, you
know what, I'm just gonna focus on my efforts and I'm gonna try
to produce the best video like this is, I want this video to be
the best on Prometheus or best, or whatever it just takes off
your other. I really don't care about the
views. Like, if I, if I know that the
video, I think I we had this video about hybrid, cloud and
multi-cloud, right? Okay.
I thought the topic was interesting.
Yeah, and I did some research and like, I knew like most of
the stuff about these but, you know, I try to also produce
content that was like unique and I think it didn't get many views
or something like it was like one of the least viewed like I
didn't care. Like for me it was like I
created the video that I really like and I'm like super you know
proud of and I enjoyed the creation process so I really
didn't care that you didn't perform like super well you know
so Is measurement. It just takes off the pressure.
Yeah, and you're creating because you don't care like
exactly. That's probably way more healthy
than to be depressed about like statistics and numbers and
things like that as a as a final thought I still had and it's
probably because I saw that last video when people are newly
coming into the tech domain as a whole kind of early in career in
that way as well. They're going to try out a lot
of things to see what works out for them.
But exactly, as you mentioned, the reason why devops is there.
The reason why I sorry, got there in the first place as
well. It's because right now, we're in
a landscape where things are quite complex.
There's different roles and specializations for lot of
things just so they fit together as possible pieces and the whole
puzzle, should then be in a team as well.
But if you really early on in your career, what would kind of
be your advice in figuring out what you kind of are going to do
at the end of the day, roll wise, or even what's a good fit
in there? Wait, I think I've actually
usually outside so software development.
Yeah and full stack because I think you can start like with
basic full-stack like trying everything out like front and
back-end not. Not necessarily just one and
then kind of test it out there. But there are also a lot of like
apart from software engineering directly like what about Heroes
that you can also use as an entry point.
Right? So, I think like everybody has
at some level I believe kind of Direction my inclination,
towards a specific area. For example, I met a lot of
people who said, you know, I like data, right?
So how can I get started in it with this direction, right?
So in a data science Direction. So in that Row in that area,
they are like is a data analyst, for example is an entry-level.
So, If you need, if the person doesn't know like okay, they
want to do like data or they're fascinated by Ai and eventually
they want to work there. I think the best thing to start.
He's still software development software engineering.
And as I said, like, I think I mentioned that like several
times in the video because I know that a lot of people are
stressing out like okay but I if I if I learned these and then
later I want to do something else in the ITT like you know
it's a waste of time but that's the thing like if You to learn
something or development like you get there, so many other it
roles where you can reuse that knowledge, right?
Yeah. Even like in machine learning or
data size, you can use your software engineering skills
right and knowledge. So I think I would just start
with with whatever is the easiest to start with with which
again, in my opinion, you software development because
also because of the resources, the amount of resources
available I think there's Software development has the
most because it's not like the newer profession is like data
related to engineering stuff. So you will finally lots of free
tutorials. Lots of, you know, courses out
there, even put cams, whatever. And then, like, once you were
like inside the, it feel like, if you get the job, like, you
have so many opportunities, like, you can switch jobs, and
you can do one year of completely different thing.
And another one. Italy something else.
And I think that's like a lot of people I see enjoy that Dynamic
and change right switching between roles like I would like
they're like lots of stuff that I did in the software
development like especially from the development that I don't use
now anymore in the devops but it's not like I wasted my time
but yet still it was still good invested time, right?
Yeah. Experience those skills.
So yeah. Like Entry level.
And then you can even as a, even as a little bit more experienced
engineer, you can just switch around and do something else,
right? So switch roles, come back to
the original role after discovering that you didn't like
any other rolls out there. So I think the opportunities are
really unlimited in 90. Yeah, I absolutely agree.
The interesting thing is because I also thought about this.
A lot of things probably originated from software
development, right? If you look at what a data
engineer does, they it data and software and put into
production. Well, the software development
component is still out there and I had a, I had a conversation
with the security Specialists and they said they are, they
were actually following one of my go trainings and they were
like, okay, I think I'll be a better security specialist.
If I have a better view of what, actually, the developer
experience is or what developers face on a more day-to-day thing,
so I can better accommodate for that, right?
With the conversation, I have with the communication with the
security perspective that he has, and I thought that was a
very interesting. Effective, right?
Because a lot of things actually do come together.
So, exactly. As you say, if you take with you
a bunch of experiences from different domains, they're not
wasted experience, right? Because they're going to give
you a perspective that other people probably within that same
role and field might not have which is then going to help you
challenge conversations and challenge thought for the end
result, to be better because of that.
And I think the landscape that we have now.
Yes, it is complex but that also brings out a lot of
opportunities, right? For people that Are like eager
as yourself to learn a lot about specific, domains and to really
figure out where their Drive is and eventually you will probably
land it. Time is going to vary.
And yes, you might not think that experience is relevant, but
you're going to take it with you and that is then your career
path. Yeah, hundred percent.
I've really enjoyed this conversation.
Not coming from your really like your drive really shines through
in this conversation which I really enjoyed talking about, as
well as your journey and training and educating people as
well. Is there anything you'd still
like to share with our audience? Audience before we leave off.
No, I think the the something that I always mention is and
Ice. Also see that this is something
that we share, I think the unique thing that people take
with them, when they enter the I.T, I.T role and kind of
develop an advanced is this curiosity and like, excitement
of learning new things. And I think also, what's unique
about it is you never lose that because it never gets like
boring. Young and the same is like super
Dynamic. So I think that's like the most
exciting part of this whole thing that I also seen in so
many Engineers. Like, I don't, I don't actually
remember any exceptions from this.
Yeah, yeah. 100% aligned with that.
We're going to round it off here everyone.
Thank you for listening. I'm going to put all none has
socials in the description below.
Now, I janesha check her out, and with that being said, thank
you for listening. We'll see you on the next one.