Kubernetes, DevOps and SRE the right way with Nana Janashia

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.