Kubernetes DevOps and SRE the right way TechWorldwithNana Beyond Coding Podcast 91

Show video

Hi everyone. My name is Patrick Akil. And if you're interested in DevOps, SRE, Kubernetes and how those all fit into effective teams within the organization, then this episode is for you. Joining me today is Nana Janashia.

She's a teacher, YouTuber, CNCF 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. Beyond.

Coding, do you make the visuals for your own channel? Do you make them yourselves as well? Yeah. So it's two of us. So me my friend, she does the post editing of the videos. Yeah. Including the animations and thumbnail and all this stuff. And I'm the one who does it, who says, okay, this color is fine or yeah, I like that thumbnails kind of chooses the last one, but she does actually like almost all the visuals.

That's really cool. And you two start it 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 side of like freelancing on that software engineering project, we were actually working on a startup which was like completely different thing, like in the real estate industry, like writing something for, for like this all online broker thing for rentals and then this YouTube channel kind of thing was like a super side project place that I just started it because I wanted to have some video content on Kubernetes because I learned a lot about Kubernetes, and he was like a lot of knowledge just scattered in notes and stuff. So I, I basically decided to have that in a video format so I could rewatch them, so I could refresh my knowledge genius feature if I needed to, and if my startup failed and nothing.

And it was like not a success. And I had to go back to freelancing. Refresh my career is not. It was the idea of the YouTube channel.

Well that's that's so simple and it's genius basically because a lot of the 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 soon as you use the day to day, it's going to be inherent. It's going of going to be second nature. And as soon as you stop using it, you're like, Oh, what was this thing again? And you kind of need a refresher, which is exactly what a YouTube video would be then. Yeah, 100%. Exactly. But really cool that you're doing it together with. Is that a friend? I'm assuming it's a female or 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 visualization. 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 for that document. Good 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 these videos. Yeah.

So I, I have the knowledge in Dev also 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. And I love DevOps, right? So I actually started like learning all this stuff and her like she doesn't have any interest in any of these DevOps technologies. So she took over like this complete post editing the animations thumbnails, 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 LinkedIn page and so on. And 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, amazing for me that I have actually someone who does all that part where I don't have to worry about 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 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 DevOps 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, I was actually interning in, they had like we had we were this big or the largest software development team and then we had this tiny, teeny cloud department, which was like one guy and one intern as well. So that was there 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 in my, my impression. So I just continued with software development. I tried to, I tried to actually do a lot of various tasks within the software development, like doing the frontend that can different languages and stuff.

So I discovered actually that I like the became part way more and then like I joined a project where we used a lot of different technologies, like it was actually an Iot project. Yeah. So we had the hardware components, we had the, the mobile application, the Android application for the web application frontend, backend dollarized. 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? Hardware.

Okay, now the interesting, how does Docker work? Oh, that sounds interesting. And then things like Jenkins set up. So like just by switching between those different tasks, like the types of tasks, I actually realized like more and more what kind of things I enjoyed doing. And that was like configuring stuff like I would enjoy to take it like our Webpack builds and optimizing it or make it faster, right? So for example, our build was like super slow. It took 10 minutes to start test or whatever. I was like, Oh, I'm going to look into it and optimize that.

So it takes one minute instead of ten. So I like doing this kind of stuff. And then and again at this point, I have no idea what 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 and coding. Yeah. And then the next project was we're also joined as a software engineer. I actually took over Kubernetes, 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 this full time. And I was actually doing full time only Kubernetes, okay? Like the not even like scarcity pipeline or anything else, like full time setting up Kubernetes, configuring like 100 different things and services inside integrations. Yeah. So it was the entry point and then the other DevOps 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 a new career path is so valuable because that's going to 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 things on the fly? And if so, how do you do that? Yeah.

So my my very first experience, Kubernetes, there was not actually the first one. Okay. So so what happened is that in the project that I mentioned where we had everything Docker, we didn't use Kubernetes, right? And again, I have this like curiosity that I wanted to learn, like as much as possible. And also like there were more into direction of like infrastructure management and coffee reconfiguring, configuring stuff. So my idea was that I wanted to learn this. Yeah. So I actually I remember I went to, to my manager and I said, I actually want to take switched from full time to like 40 hours to 330 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. Yeah.

So not something that I learned at 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 bugs 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 it's 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, you know, Yeah. And then my manager was like, okay, so what? What exactly you want to learn? And I was like, Okay, guys, blah, blah, set up stuff.

And they actually offered me, they were like, Do you know what? You can take that day? And you are going, It's still going to be employed with us like 48, like full time. So we're going to pay for that is like, you know, upskilling 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 this out to kind of keep our employees like one full day to kind of self develop and learn whatever they want, which is going to be like eventually the variable for the company. So and my manager was like, okay, so this 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 now. Okay, 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 AWP and Kubernetes. And I also always say that in the in the videos as well, like how to learn new stuff, right? So I didn't want just learn something like let's go through all the services or Kubernetes, you know. So I was like, okay, what what is a project that I can actually take and use to learn this, Right? Yeah. So I took our documents application as an example, and I was like, okay, I'm going to take this and I'm going to deploy that to prominence cluster on AWP. So that was like a perfect project where I could just practice both because it was super painful and I think because imagine we would have like this half Iot system that is like has integrations with this hardware components and take these.

And while learning Kubernetes and why learning enterprise. And I think back then, if I remember correctly, there was no community service on the NWC. Okay. Actually configured everything from scratch. So I just rented the servers and I had installed the stuff like with kiosk or something.

So it was a little bit more difficult. Yeah. And like every Friday I would just work on it and it was, it was super interesting and fun doing it based on that project that I actually had. 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 database 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 plan for the customer to to ask ask us to actually deploy those stuff in the company's 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. I'm willing to take less time and less pay because of that, just to teach myself those things. And obviously props to your manager and the company for being like, No, no, no, we can do this and it can be a win win as well. The only thing you have to do is then also like look into Kubernetes because we expect this to be a bigger thing.

Yeah, good for them, because they were kind of right, because Kubernetes is still tried and true in that case segment. Amazing input. 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 to live? It's like, yeah, really, really cool, super cool. And then obviously a lot of stuff now is more managed and more service towards, which makes sense if something is established than IWC 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 barebones.

Setting everything up and even Iot in hardware is not the not the most easy domain to be in in that aspect, which is radical. Did you. Yeah so there was was also like the that the challenging part was also like super fun for me.

Yeah. Because I remember that like so the process was that I would learn like this AWG services, I would learn Kubernetes and how it work and I would like sketch and design, like how to map what we had like this operate services and each service had like different requirements like storage requirement or networking requirements which were different. So how do I actually put them there and connect them together? So I would do this like solutions.

Architect kind of kind of things and design. And that was like the fun part. That would be 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 self-guided. Well, I was just doing whatever like I would, I would learn and get input and then I would just sit down and kind of brainstorm and I'd go, okay, how 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 like more pieces together until I had like this complete picture. So it was like a you and it was, it was difficult also because I was at a very, very early stage and there was like very little information out there like 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 to that specific issue that I had online, because it was just I would find questions where, like somebody like I have exact the same question, but it was like not answering at all. So that was also challenging part because like if you're programing, right, like yeah, doing Java or whatever, like you would find tons of resources on it, right online.

So that also made the, the self 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 Soma figured it out and then shares it.

That's really a stage of like an early, early on technology, I guess, and the adoption there. What I yeah, what I wonder is because I, 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 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 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 here in setting things up, more so or how do you reinvent the wheel in that aspect? Yeah, that is a really interesting part, especially like with 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 misconfiguration in the integration part of that. Like expose your, your whole cluster or whatever like application up. So that is especially interesting in the, in the new tools 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 in Kubernetes, right? Yeah. And then I had when I joined this this project where I 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 this huge company. Yeah. So that was like a different perspective of like, I'm not just learning stuff myself, 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, resilience and stuff.

So there was another perspective and I would that was for me, it was important to get the inputs from different teams. So it actually work right in the middle of software developers and operations engineers. Yeah.

And the I.T operations stuff that they were actually the ones with most knowledge in terms of how, how the cluster especially underlying infrastructure should work, should work. So kind of the ideal case of how the cluster should be configured. Developers just wanted things like I just want a database to run with these configurations so I can connect my application. Right? But I.T operations guys were like, okay, so we want this kind of monitoring.

We want to see be able to see someone that the application developers leaked any secret data and it's logged in a console. So things like that. Right. So we'll get input from this experienced engineers and then okay how do I know configure that inexperienced cluster. Right.

So that was like my additional knowledge input for what are the best practices, like what things needs 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 Kubernetes best practices themselves, right? So how do I secure the cluster itself? How do I, you know, make sure that the resilience is there? Yeah, using the controls that Courantes gives us.

So it looks like a lot of phases of, you know, like self-learning and then getting these best practices of generally how the set up should look like and then how do I meet these two specific technology like Kubernetes. So it's, it's, it's, I don't think that it'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. 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. So 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 the 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 that would like first of all, like I still have that curiosity that I had before in terms of like learning new stuff and see where the trend is going. Great. So for example, things like multicloud and or hybrid cloud and the developments in this directions. So what I actually did for a long time, like I think like the last year, almost the whole year I had projects. So I would take actually consulting projects, Yeah.

So consulting projects where I would work with a team that had like Kubernetes and they had like some some issues or usually would be like maybe software developer scheme who had to take over the cluster management, you know, take doing the creating level processes. So a take on this kind of project where I could contribute, of course, like, you know, help them set up the Kubernetes cluster, the density processes, etc., but also learn like how do different companies use that? Like what, what, what is the purpose and how do they try to implement Kubernetes to achieve those goals? Right? Yeah. So I always try to have that accompanying consulting job, and especially when you do consulting and you don't let do like 8 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 we 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 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 Invisible and TerraForm, for example, we've actually reached out to the Ansible team or we had a connection. And then I kind of followed up and I was like, like I have these questions about Ansible, and it was it was 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 are like the best practices of doing this? Like, am I doing this right? Is this configuration correct or is there like a best practice in doing that? So I send them questions and so I would actually talk to the teams of developers to get from them. Like the input. I would talk to other engineers that worked at large companies to get their input, like, how are you doing? Like how, for example, there was a company that use DevOps and it's r E okay in one team. So I was, I was really wondering like how large companies actually divide the tasks between those two roles and like how do they manage the, the combining those? So I would actually just talk to engineers and get like this kind of input from our companies using this stuff. So it is like, like I'm still trying to learn as much as possible. Yeah. And to kind of collect knowledge from multiple companies and to kind of condense that in one 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 point of view, is like, all 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 to pay it forward for those people that are kind of come behind you. I think that's really cool. But Thanks notes that there was a very good summary over the setting of very short No. No is that that's my job as podcast. Yeah but for me like I last year I've started teaching teaching people more software development in specifically go as a programing 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 was 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 a more of a routine, and it's not necessarily about the material anymore.

It's more about the interactions with the people, their perspective on things, or the things that they challenge in a way as that also kind of being your experience because you've switched and you've done more with teaching rather than actual hands on production experience. Yeah, so like one thing that I love about the parts, the teaching part. Yeah.

And I had this like from the very beginning, like from the very first videos that I made about Docker and especially Kubernetes and even now. So that one thing is that like, let's say there was, there was this fear around Kubernetes, like, like what are this Kubernetes components? Like, they all sound the same, but they're like, super difficult. So for me, the the most exciting part of creating those videos was creating a content where someone who had read like hundreds of blog articles and maybe the whole documentation even works with Kubernetes and have like this chaos in their mind would watch the video and be like, Oh, that's how it works.

You know, like, have those, those aha moments like in the in the video. And I absolutely love that. Like when I know they're like lots of unanswered questions. But some topics like, I don't know, things like what is the difference between DevOps engineer and CRT? Right.

Yeah. So I would, I would actually search a lot of articles, blog 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 like 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 the Internet.

Yeah, 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 to say, yeah. No, I mean for me that is 100% recognizable and I can compare that to the episodes that I do with the bike just 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 questions.

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 tune 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 a good episode. Like it's just not going to fly. I think that's a yeah, 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 concepts here and there. Is the thing that you mentioned.

What is the difference between kind of DevOps and SRT? Because I saw those terms DevOps first, then sorry, 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 join? Like how would you explain that to people that are kind of new with those terms? Yeah. So the brief explanation actually I it was one of the videos where I did the most research on that. And the problem was like exactly what you mentioned like. And I think the reason for that issue is because they're like relatively new.

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 there are a lot of mix ups there. Yeah. So when you and when I was searching for this, all my 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 line between them. Yeah. So I did actually a lot of research research, including like I watched interviews and content from the creators of it's already like people who actually came up with the concept and how they actually defined it, plus 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 certainly explained that.

My view is that DevOps is actually more on the development side and it's there is more on the operations side. And the reason why I think it's absolutely legitimate to have those two separate roles, even though they have overlaps and they may sound like the same thing is because like when you think about DevOps, right? So you have to have development understanding. You have to understand this whole development lifecycle. You don't program as a device engineer, but you have to understand how developers work. You have to work with setting up the whole CSG pipeline, which is already a huge part, right? To get that completely streamlined and automated.

Then you have the infrastructure part. So if you're on Cloud Lake, you have to be knowledgeable with risk cloud, for example, right? Whatever cloud you're on. And then on the infrastructure part, you have the Kubernetes, which as I mentioned, it was 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 in and say, you know what, you as the engineer, you also have to monitor the deployment and you have to do the operations part like it's just too much, right? Yeah. So I think that S3 is like a perfect addition to take over some of the stuff that DevOps NGO would like possibly not be able to do and should not like. There should be some some limit, right? Yeah.

So it's kind of adjacent or role that kind of takes over the and focuses on the operations side. But obviously there are lots of overlaps, right? So they have the same objective which is the application should 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 and neutral. Interesting. I, I didn't look at it through that lens that the devil site is more like a Jason towards the development side and the sorry 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 you're operational. 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 and optimize 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 that same feature team. But how would you structure then if we have, for example, a development department and an operational development, should they should those be the same? Should the DevOps kind of knowledge and necessary 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 feature 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 DevOps? Engineer developers also have to work with SRT, and in fact it's like original idea is that it's r, e should do their job. Like if they, if they do their job well, they have less work. So if they automate stuff in the, in the, you know, the application set up and everything is running properly reliably and everything is automated, then you know, sorry has less things to do. Right. Yeah. Because everything like the monitoring is already running.

If something happens, they will get notified. But what, 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 and because we have this kind of combinations, right, so I don't know, test engineers have to work with DevOps engineers because they, they are a really important part of the whole CIO city pipeline part, right? You have security engineers, for example. They should, you know, provide inputs and make sure the cluster is running properly, is secured on multiple levels. The infrastructure is secured, You have the security checks in the pipeline, right? So like when you think about this role, the tasks of this role, everything is kind of intertwined, right? So it makes complete sense to have these people working together instead of having, like Department of just Sorry and Department of Justice people, because then you would still have that overhead of mixing up people and having them communicate with each other. Yeah, but I think it's just easier when it's project based, like feature teams where like everybody, everyone has the knowledge of what the other people are doing in the same project.

Yeah, yeah, I think so as well. I think the, the best teams are with a shared mental model. Right. And if your team needs to just put out a lot of software, it needs to land and production needs to be resilient and obviously you need to see what, what's happening over there.

Then you need all those aspects in that same team. Otherwise you can't do it. 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 the other team. So then are you really autonomous in that way? Not really.

So I really like that. You also mentioned that the knowledge for whatever you're doing should be within the team, right? In isolation. Yeah. To make sure that you are autonomous in that way.

I also and this is more so my personal 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 future team, seeing kind of what goes on there instead of being kind of taken out of 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.

Other developers then to make their work better in that way. So I dunno if there's. A call I see, like I can imagine the separation working for platform engineers or cloud engineers specifically because like there is a little bit more separation there, right? So they, they do their job like manage and create this reliable cloud infrastructure.

Yeah, maybe they do like some migrations, some 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 IT company, Right. Where lots of applications can can actually. Q is the same cloud environment. So then I would say this, this is like one of the roles that I can imagine can be like, it's only apartment.

Yeah, but at some point, like, like when, when there is a overlap of, okay, so you know, club engineer has to configure and manage the Kubernetes cluster for example on us, they still have to work with software developers and specific project teams. So again there's like a lot of advantages of having them in the feature team as well. Yeah, yeah, I agree. I mean, even even I'm now also in an Iot project, so 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, 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 engineer 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 separate, 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 regard to that knowledge sharing in that way. So yeah, yeah. That's another really interesting.

Yeah, that's a really interesting point actually. Yeah. Yeah. So 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 a lot of, a lot of terms related to platform engineering saying that DevOps that 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 to kind of reduce their operational overhead. But then. Yeah, I mean, I don't think I mean, I think that that if this trend continues, which is going to be good, I think DevOps engineers will not be like that will change, will not be dead. DevOps engineers maybe can breathe a little bit more because they're like a part of their responsibility. They 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 to do. So I think you would just be like, okay, they have all this workflow, right? So they can actually concentrate like on smaller set of tasks and kind of do that. So like generally, I don't think Davos is going anywhere for the next year because like and that's again based on the input that I have, you know, seeing all the companies and, and hearing for the project is that a lot of companies are still very far away from like having this super nice streamlined process, automated process.

Yeah, a lot of things are still being done manually and that's exactly like where DevOps brings the most value. So I think like when you think about the benefits of having these automated processes, I think companies would still want to do that. And a lot of a lot of the things that DevOps engineer is doing specifically is not part of platform engineer or cloud engineer's job. So I think that's the reason why I think DevOps is actually going to, you know, either stay demand as is now or even even become more demand it.

Yeah, yeah, I like that as well. And even even let's say we were in a world where a lot of stuff has been automated, then that will probably bring new challenges in the DevOps role will kind of morph into solving those challenges then, right? Just because something morphs doesn't mean you don't morph with it. That's kind of the whole thing in this tech landscape, which I enjoy as well. Now I've, um, one of my final questions was I did a lot of research on you and yeah, I saw your since you have Ambassador, I think it's AWB champion or hero and Docker champion or hero, but were those always like, are those goals that you set for yourself and then you achieve or are those more byproducts because of the things that you're already doing? Yes, they were 100% byproduct. Yeah, right. Okay.

So we actually funny, but I actually didn't know these titles did. So I remember I remember seeing content of one of the Docker captains. So that's the title. I was like, Wow, that's a clever name. I actually thought that that is also content creator.

I was like, Wow, that's a cool name. Yeah. And I actually thought he was like the made up name of the content creator. So in that when Docker reached out, actually Docker was the first one to reach out and they were like, Yeah, we would like you to be a doctor.

And I was like, Oh, it's a title, you know, you can get for producing content on the technology. So I was, I was like super honored and flattered because like I had been using Docker for a long time and then AWB switched out and then. KF Hmm. And so it was completely like by product. It's even if I had known about them, I think it still wouldn't have been my goal.

Yeah, 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. Michael Right. Yeah.

So it was more like my goal is like as a, 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 can not get anywhere else because it's like condense, like, I dunno, processed. So that was my goal. And the, the and then I would just check like analytics once in a week or once in a month. You just see the growth, right? So we still had 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 like old, like things that are like more measurable are not like. 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. And it also takes a lot of pressure off you, right? As a creator, because when you decide, you know what, I'm just going to focus on my efforts and I'm going to try to produce the best video like this is, I want this video to be the best or Prometheus or best or whatever. It just takes off. I really don't care about the views.

Like if I if I know that the video, I think 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 this, but, you know, I try to also produce content that was like unique and I think it didn't get many views or or something like it was like one of the least viewed like I didn't care. Like for me was like I created the video that I really like and I like super, you know, proud of. And I enjoyed the creation process. So I really didn't care that it didn't perform like super well, you know? So those measures, it just takes off the pressure you are creating because you don't care.

Exactly. That's that's probably way more healthy than to be depressed about, like statistics and numbers and stuff like that. As a as a final thought, I still had and it's 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 S3 got there in the first place as well is because right now we're in a landscape where things are quite complex. There's different roles and specializations for a lot of things, just so they fit together as puzzle pieces.

And the whole puzzle should then be in a team as well. But if you're 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, role wise or even what's a good fit in there? I have actually usually I would say it's a software development. Yeah. And full stack, because I think you can start like with basic full stack, like trying everything all like front and back end, but 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 a lot of I.T. roles that you can also use as an entry point right? So I think like everybody has at some level, I believe, kind of a 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 I.T. with this direction? Right. So in the data science direction. So in that in that area there, like a data analytics, for example, is an entry level.

So if you if, 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 is 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, Oh, okay, but if I, if I learn this and then later I want to do something else in the i.t. Like, you know, it's a wasted time. But this thing like if you if you learn software development like you get, there are so many other i.t roles

where you can reuse that knowledge, Right? Yeah. Even like in machine learning or data science, you can use your software engineering skills and knowledge. So I think I would just start with with whatever is the easiest to start with, with which again in my opinion new software development. Yeah. Because also because of the resources, the amount of resources available, I think the software development has the most because it's not like the newer profession is more data related engineering stuff. So you will find like lots of free tutorials, lots of courses out there and bootcamps, whatever, and then like once you're like inside the I.T feel like you would 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 then other want to do 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 there 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 that it's not like I wasted my time, but it still it was still good invested time, right? Yeah, it's experience 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 roles out there. So I think the opportunities are really unlimited at night. Yeah, 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 incorporate data and software and put it into production or the software development component is still out there. And I had a I had a conversation with a security specialist and they said they 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 they have with the communication, with the security perspective that he has and I thought that was a very interesting perspective, 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 a 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, 100%.

Oh, I've really enjoyed this conversation coming from your really like your drive really shines through in this conversation, which I really enjoyed talking about as well as your journey in training and educating people. Well, is there anything you'd still like to share with our audience before we leave off? No, I think that the something that I always mention is and I also see that this is something that we share. I think the unique things that people take with them when they enter the I.T i.t role and kind of develop and advance is this curiosity and 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 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. It's like, I don't I don't actually remember any exceptions from this. Yeah, yeah, I 100% align with that.

We're going to round it off here. Everyone, thank you for listening. I'm going to put all Nana's socials in the description below. Nana Janashia Check her out. And with that being said, thank you for listening. We'll see you on the next one.

2023-02-19

Show video