PurePerformance - Roadmap to k8s, DevOps and more with Nana

Episode Date: May 24, 2021

Wonder what you learn when building k8s from scratch for a large enterprise? Wonder what you learn when automating delivery by connecting your different DevOps tools together?Nana Janashia runs one of the most successful technical YouTube channels called TechWorld with Nana where she covers topics ranging from containers, docker, k8s, cloud native and DevOps. She basically takes her lessons learned and explains technologies and concept in a very easy way especially for folks that want to get started with.In this episode we focus a lot on DevOps, what the right trades of a DevOps engineer are and how to get started. Thanks Nana for your time and all the additional resources we talked about during the episode that are listed below:DevOps Bootcamp: https://www.techworld-with-nana.com/devops-bootcampDevOps Roadmaps for Humans with Bret Fisher: https://www.youtube.com/watch?v=UXf2c76KAyADevOps Roadmap: https://roadmap.sh/devopsLinkedin Profile: https://www.linkedin.com/in/nana-janashia/TechWorld with Nana YouTube channel: https://www.youtube.com/channel/UCdngmbVKX1Tgre699-XLlUA

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello and welcome to another episode of Pure Performance. My name is Brian Wilson and as always, my co-host Andy Grabner is with me. Andy, how are you doing today? I'm pretty good. I wonder what else I learned from you today, because before we got to recording, you excited me with your language skills. You speak a lot of different languages.

I can say no in a lot of languages. Yes, yeah. Except? Well, I don't know it in any of the Asian languages. Yeah. I know, well, you're challenging me on German, but I can say it. I can say nein.

Nein? You know. Okay. But, you know, no is no in quite a lot of languages. So it's a great way to show that you know a lot of languages is if you want to impress people and win friends. I can say no in Spanish. But usually when you say it in Spanish, it's a little bit more of a no.

A little bit more. I guess if I ask my wife, it depends on where you're from. Like in Colombia, maybe a slightly different pronounce than in Spain or in other countries. Yeah. But you know what? I'm really glad. I'm really glad.

I'm really glad that our guest today. Exactly. I'm really glad that our guest today, neither said no, nor nine when we asked her to get on the show. Andy is the master of segways, everybody. Yeah.

And I don't mean the little stupid driving machines. Yeah. And this is why I want to, I want to, I want to pass it over to nana to introduce us because nana it's it's an honor to have you on the show and thanks for not saying no to us because i know you're busy welcome to the show welcome thank you i'm great i'm glad to be here on the show and i can actually teach you two more ways two more languages to say no in which are

to my mother languages which you probably don't know georgian and mcgrelian that would be cool mcgrelian what is mcgrelian mcgrelian is like a really small tribal language it's it's it's very close to old greek like we have some words from those. And Georgian is more like a Middle Asian language. From the sound, it sounds very similar to Arabic or Hebrew. So, yeah. So then, come on, tell us. Should I say no in those?

Yes. In Georgian, it will be ara okay and in gregorian it will be uh var interesting interesting this is no there's no resemblance at all to know but we have actually one weird thing which is we have the the in georgian we have mom and dad uh reverse so you say um so mama means actually father in georgian and then data or daddy actually means mother which i like i would really wonder like what is the reason behind it we just want to be different because anybody can yeah it was it was a it was a disgruntled teenager who was like i'm not going to do it the way everyone else does it i'm going to do it my way exactly uh and talking about this another great segue nana you've definitely been doing

it your way in the last year uh because you right this is it was a great segue again brian thanks for that yes uh nana maybe for those people that don't know you but i think a lot of people that are listening to us now know you because i think we we name dropped you in the last couple of episodes we had one with christian heckelman where he talked about things not to do when you start with kubernetes we highlighted your youtube channel take well with Nana. I think it's the link that I've shared the most in the last couple of months since I found out about you. Yeah. And it's just phenomenal content. Thank you so much for the stuff. It's amazing what you put out there. Thank you. Thanks a lot. When we started actually using this Kubernetes video,

so it was me and my friend of mine, I actually had all this Kubernetes knowledge, actually, that I painfully acquired through setting up the Kubernetes project in one of the Austrian companies. And while I was learning, one thing that I realized was there were just no resources online, at least back then.

There were no documentation, like a proper documentation. There were no forums where I would ask a question or I would see a question, the same question that I had a problem with, which had answers to them. So there was like a sign for me, there must be other people struggling with this thing.

So I kind of put together all my notes while I was learning, like configuring logging, monitoring, like all sorts of different stuff, like volumes and storage. And once I had those notes now I figured let's let's put it in the video format and just put it on YouTube so that maybe other people can can benefit from it so that's how I just sent a couple out today because I was having a conversation and just for people who are not familiar with it for context, you run the range of everything from deep dive three-hour sessions on becoming an expert in, I forget which one it was, in Kubernetes, obviously. But then you'll do a lot of higher level ones.

The ones I just shared, I was having a conversation with one of my account executives yesterday, and he was confused between Docker and Kubernetes. He thought they were the same thing, or containers in Kubernetes. And I was explaining to him, came upon that this morning on that on that specific video and i was like oh here perfect take this one and also while you're at it here's the difference between docker and vms because i was trying to explain this hierarchy to them um so there's a lot of so many like great just primers of the fundamentals you know besides the deep dive you got those fundamentals which so many people maybe you don't necessarily need to go dive down deep into these areas but you you need a fundamental understanding of that foundationally in order to do other things so really appreciate what you've

done it's quite amazing thank you and just coming back to the notes um i've been and now brian this is the first time i mention it i've've been doing a lot of installations of Captain, our open source project, over the last couple of months. And it's always interesting to then go on a Zoom session and try to help people. And the first thing you see is their notepad or their Visual Studio Code with all of their kubectl comments and then all the notes.

And I've also seen a lot of API tokens that I shouldn't probably see, but nothing is recorded. But it's, as you said, right, we are learning. This is a new technology. We're all learning. And we're taking notes. And it's great that you have taken these notes and put it into an easy-to-digest, easy-to-understandable format.

So I know you don't need more followers, but one or two doesn't hurt, I guess, more. So we will definitely put the links in now today because you have such a broad range of topics today we want to focus on devops because you also said devops is something that that you live and breathe and you've been you know doing a lot of work especially around automation i also because you told me this about this you had a great interview with Brad Fisher on bradfisher.com. I think it was called, I'm just reading up my notes, on DevOps roadmaps for humans. And there's some great discussion.

That's why I don't want to kind of repeat what you have said there. So if people really want to get some basics and behind the scenes from you and some initial discussions, I encourage people just watch this particular video, but still for me, what would be interesting for you from you to get is, you know, there's a lot of people that are first of all, trying to figure out what DevOps really means because there's a thousand different definitions. Should we get into DevOps?

What does it mean to become a DevOps engineer? Maybe I'm not suited for a DevOps engineer. I think knowing whether you want to pursue a DevOps career, I think that if you can answer, well, I don't have the right skills upfront, then maybe you are preventing people from investing in something that doesn't make sense either. So my question to you is, what's initially your reaction when people ask you, what's the right way to get started with DevOps? Am I in the right field? What do I need to know? Or what is a good indicator maybe that tells me,

maybe this is not the right thing for me and I should do something else? Like very often when people ask me, like they're usually in the IT field or they're kind of looking at different, uh, job descriptions and kind of trying to figure out, uh, the first thing I say is that you have to have some foundational knowledge because I think just jumping into DevOps as the first field in your, uh, IT career is actually wrong because you're just going to be overwhelmed because DevOps is like having an overview of how the whole like the complete software development deployment process works right so that's like too many things at once for for an absolute beginner so I always

say either do the development first or system administration or cloud engineering. So basically get some basics of those two. Another thing is that I think you have to be the type of person that likes DevOps because my observation is that you need to love and also you need to be able to think in a little bit more abstract way because DevOps is like,

you don't go deep into, you don't specialize, okay, now I'm like whatever, Docker engineer, whatever. In DevOps, you have to know so many tools because there's so many categories and there's so many pillars of this whole process right so i think you need a skill to be able to connect all those stuff on

more a higher level than like go deep into one technology so if if there are people who you know they become uh language specialized right programming language specialized. And there are people who like to be specialized in something. So for those types of people, I would not actually recommend DevOps because then you would not have, like, it's going to be really difficult to specialize in one or two technologies in DevOps because especially with the developments and improvements in the deployment processes and development processes. There are new technologies and platforms coming up, right?

So you actually have to be open and ready to learn new stuff all the time, right? And not only new technologies, like new concepts, right? We have this GitOps now, we have the DevSecOps now, the thousands of other concepts. And I think that this is going to continue emerging because there are really, really cool things coming up. There are people who are developing on top of Kubernetes, right? They're developing on top of these new developments

because they see that developers and system administrators, DevOps engineers, they see that there's a real value in these improvements. So I think it takes a type of person and also you need to have some kind of basics in IT. So I think, so if I hear this this right it's a specialist versus a more generalist because in the end this is what you need to have process thinking, you need to have obviously then still the people skills because you need to understand what are the individual requirements of the people that you want to you know make happy in the end which is you know allowing a developer to use your pipelines.

Still, I guess, though, because this is also what I'm seeing in our organization and other organizations, a key skill is to build all these integrations, to kind of glue all these tools together. This is a lot of business. And I remember I was browsing through the questions that you got from the Brad Fisher show. And there was a lot of questions that come in. So, well, do I now need to learn Python or is Bash better?

What do I need to do in order? Then, you know, I think a couple of questions around the tooling and scripting languages. So do you agree that at least kind of one of the traits of a DevOps engineer definitely is scripting because scripting is the fundamental thing to connect tools this has to be there yes yes absolutely i mean you can you can operate i think um it is realistic that you do stuff and you configure devops pipelines and processes without scripting uh but it's just gonna be be more work. It's going to be more work for you.

You've got to make mistakes. Things are going to blow up and people are going to be emailing you and chatting you. Developers will be writing you, hey, the application isn't working. The sysadmins will be emailing you. So it just makes your tasks easier, right? And then things just more transparent also so you don't have to do the stuff for everybody but if you write

scripts, you kind of give them, like developers or operations people, you give them the scripts and tools so that they can do stuff. You kind of running to each problem and fixing it yourself.

So what I also think is feasible is, especially if you're a junior DevOps engineer, you can definitely start by doing everything manually on your own, and then you can kind of evolve from them and start, you know, learn bash scripting or Python, whatever. And then you start automating what you're already doing manually. Yeah, I found that always. I think, Brian, we talked about this years ago, the automation piece, right?

Start with automating something that you do manually right now is a great way also for you to then learn a new language. I think we both had the challenge or we talked about this that you know every year pick a new scripting language because it allows you to first of all keep your brain fresh you know being up to date on new technology what's out there but in the end really use the technology to automate something that you otherwise are spending too much mental time in and yeah i would just add to that too you know from what i'm gathering there are two you can come into devops from either as a developer who's really into the other side of

things and maybe want to broaden or if you're on operations but you like doing some coding and you want to expand um but i think when a lot of people hear scripting there's a little bit of fear right oh my gosh now i'm gonna have to be a developer. But what I've learned, like, so my background and just, I'm sure people listening have heard this before, but for Yunan as well, I was a communication major. I was studying television and film. I got into performance because I wanted more money than what I was making editing videos, right? So I was all self-taught. And so I don't have development background. I don't have heavy programming background. But when Andy brought up this idea of like, hey, actually, I think you got it from Wilson Marr,

didn't you, Andy? It might've been something, there was a list of things for performance people. But the point is that scripting is not development and is not as complicated as development. It's very straightforward. It's very much you put in what you wanted to do. So don't let that be a hurdle, I guess, is

the point I'm trying to make, because it's really not as complicated as development. And it's a lot more fun, because you just do things and suddenly, you know, things start working. You're like, oh, that's awesome. It just made my life easier. And you run the same script a hundred times trying to figure out why the first 99

times you get a compile error or like a runtime error because of a variable not set or some strange things. It's a missing indent. Something like that, exactly. But this is now a question to you, Nana, because I want to see if you have the same observation. And maybe if we say DevOps engineers are,

you know, using scriptings, using scripts to automate things, gluing tools together, yet most of them might not be trained software engineers, which is okay, right? Because we need a lot of people that can do automation. Aren't there two challenges? First of all, if every organization tries to build automation, kind of gluing similar tools together, aren't we running in a situation where, as a global community,

we're building a lot of, let's say, similar glue codes? And because we're trying to solve similar problems, because in the end, a delivery pipeline, what does it do? It does build, it does deploy, it does test, does evaluate, does promote. So the first thing is, aren't we running into a situation potentially where we're all building and trying to solve the same problem,

maybe with just with different languages and with different skills? And the second thing is, if most of the DevOps engineers are not trained software engineers, don't we run into the problem that these scripts that they generate are not following good development, best practices, and therefore you end up with very hard to maintain code,

duplicated codes and you know just in the end slowing people down? Yes and that is absolutely the reality. For example, a lot of companies since they've introduced Kubernetes, for example, in the company, they still try to build their own self-hosted Kubernetes clusters. Obviously, this is a really complex task because you have to take all your Kubernetes clusters. You may have your own on-premise stuff and you may

be using some other servers. So you have to take this complex technology, you have to make it even more complex and then make it easy to use, like the APIs and the developers, and you have to have an administrator team who is managing the security and stuff like this.

And I know that there are a lot of big companies, a lot of medium companies that actually try to build this themselves. And of course, now you can imagine how much resources, how much training, because you have to, like, you really have to now start telling your employees that they have to learn the Kubernetes and how to build all this stuff. And obviously there are solutions out there that are trying to solve the same problem. So I personally believe, now this is a more complex example, but in terms of scripts or some more

less complex use cases of just gluing two or three technologies together and building some processes. My approach would be, I would first try to find, is there a tool that is already doing something like this, which is maintained by a community, which is properly tested with whatever technologies that probably the developers know about and then use that. Because exactly as you said, because even if you know the technology, right, then who is going to keep maintaining this stuff? And usually from my experience, this is usually one person in the team that writes the scripts

and then he has all the knowledge and maybe documents just a little bit for other people. If he's in a different project or if he leaves the company, nobody knows how to fix anything or how to change the code. So they kind of stuck with this legacy script, whatever. And I think you're just explaining the person of christian hegelman who we had on the show two episodes ago he was the one who uh gave us an overview of things not to do when we started in kubernetes because in his company two years ago he started with kubernetes on bare metal like similar what you were describing in your kind of gig that he did in Austria and then running through all the challenges that he had and and um it's fascinating and then also because I did another thing with him he was showing his GitLab pipelines

and his GitLab pipelines the code was like more than a thousand line long uh because it's like combination of the process like the tool integration here another tool here some some some bash scripts in there. And then he said, you know, I'm constantly waiting. I'm constantly reacting to Slack messages from his colleagues saying, pipeline broken, please fix, because nobody understands, you know, why something breaks. And it's not, I don't want to say something bad about him,

but it just ended up like that because he had to build these pipelines. He had to build the automation and he built it based on his best knowledge. But now it just becomes a maintenance nightmare. Yeah. Yeah. I also know a case, it's also in one of the big companies,

where probably a couple of years ago, I don't know, when they first installed Kubernetes, they used custom scripts to install the whole thing, and they obviously adjusted stuff for upgrade because at some point, time came where they had to upgrade the whole cluster, so they adjusted the scripts.

And a couple of years later, the people who actually, two or three people who were involved in writing the script, they're in a different project, and this Kubernetes installation upgrade maintenance, whatever, script is seen like a black box for the DevOps engineers, for the rest of the company. It's like, we don't touch that. It's very fragile, right? So nobody knows what's going on in the script, plus nobody dares to touch and adjust that stuff because they don't know what breaks, right?

And this is actually a reality in a lot of cases. I feel like my... Because Kubernetes was also new to me about a year and a half ago. And then with our open source project, we obviously had to figure out a way how can we install it with our users. But most of our users were also new to Kubernetes. So we then came up with scripts that were automatically installing either micro Kubernetes or keys, so K3S. And then these scripts started to grow. I maintain one of these scripts that is now like 500 lines long, which is, you know, setting up K3S in a particular version

instead of traffic using Nginx as an Ingress controller. 5,000 if-then-else statements of what else you can kind of switch. I mean, it is exactly, you know, as you said, it's becoming a technical nightmare to maintain this. Now, what's the solution then to this like if people are now we cannot give the impression that it's it's a cool world but on the other side it feels like we are we probably end up with a lot of challenges and technical debt how can somebody that is really interested in devops make sure that they learn the right trades to not end up in a situation where when they move from one project to the next, that they leave behind a big mess?

It's a very good question. Let's try to solve it. I mean, I think it still needs some time for best practices overall to develop for DevOps space, because it's still relatively new. So we still need to gather some experience. Obviously, in some cases, technologies and tools have developed, right? So you don't have to write those custom scripts yourself. You can just go and use them.

And I think that happens actually very logically, and it needs some time, because after some time, when a lot of developers, a lot of teams have the same problem, at some point there is this open source tool or some kind of technology or even a commercial tool that solves the problem, because then it's obvious that people can do that themselves. Same with the Kubernetes installation, right? The managed Kubernetes service is, in my opinion, a really good solution

for not having to maintain any scripts or not having to deal with Kubernetes installation because that is a nightmare, right? So no Ansible playbooks for installing Kubernetes binaries or no command line tools, right? So whenever people ask me whether they should use the managed service of Kubernetes or install themselves, I always say, please take that.

It may cost, like, from the beginning, it may cost a little bit more, especially if you're building a large cluster. But you also have to, exactly as you said, right, you have to understand that the people, like, if it's a company that decides to build their own Kubernetes cluster, you have to have people who learn or who know Kubernetes enough to be able to write those scripts and to maintain and do the upgrades, et cetera. So distributing, delegating the stuff to the services

that do it for you is one of the solutions. But in many newer technologies or newer setups, there are no such tools yet. So in that case, the alternative still remains that the DevOps engineers or the teams, they still write their own scripts or files, whatever. In that case, I think the common approach

should be that one person or two people shouldn't write those scripts, right? It should be actually like a team effort and developers should be involved in them because the script is usually doing something for the application, maybe doing something for the operation side. So I think the DevOps, one person,

one DevOps engineer shouldn't be writing that script. It should be from different areas people just coming together and writing that script and also refactoring them as well. That's actually a good point

because earlier I mentioned when I said, isn't there a threat that if scripters that don't have a proper education in software engineering or the expertise in these practices that we end up with large unmaintainable scripts. So I think what you just bring up is refactoring. Refactoring scripts is something that, you know,

hopefully whoever's listening in and just started a DevOps role and you've been writing scripts for the last couple of months, you know, think about refactoring. Because refactoring means rethinking on how you structure their code. Your code grows over time, but how can you make it simpler? How can you break it down into reusable components? Throw away things that you don't need anymore, right? Reducing technical debt. I mean, you are probably doing more scripting

or have done more scripting than I've done in the last couple of months and years. Are there any, from a refactoring perspective, is there great support now in tooling, like in the IDEs? I don't know, does Visual Studio Code provide refactoring for Python scripts, for Bash scripts? I'm not even aware of it. Do you know?

Yes. I actually wrote a lot of the scripts in one of the projects in Node.js because we had this microfrontend microservice application with Node.js plus iPhone, actually, the right libraries for whatever I needed. And I used the IntelliJ. It has actually the... Like in the paid version, you have this JavaScript support

and you have everything there. But it's the same way. Visual Studio Code is really good. Especially if you add the plugins and extensions for any... Probably not for Java, but for Python, JavaScript is really good. So definitely the IDEs, they're really good for refactoring. And obviously you mentioned version control. I think these are all practices that we all need to... I know this

should be nothing new for a DevOps engineer, but these are all common practices. Doing PR programming, code reviews, these are all practices. Now, the next thing would be test-driven development. Do you have an idea on how do you test your automation scripts?

It's just other testing frameworks for that or approaches? I haven't used any in my projects, but I think it's because I know test-driven development from development part, right? Because I was a software developer before I became a DevOps engineer. So, I mean, you have this trade-off, right? I think long-term, it always pays off. It's always a good idea to do a test-driven development because you don't have excuses anymore to not test your code

and you end up with a better code, obviously. However, this decision is often not made because of different reasons right because it slows down the development process because when you start writing the features it's it's maybe more exciting plus from the business point of view more features and we don't have time for tests right we there there are a lot of cases like this but i think long term it always uh pays off to to have tests uh for your um application uh especially if you don't follow those best practices of you know a pair programming code reviews because the the less you review your code uh the more tests you need right because? Because the more risk

that you're going to make some mistakes. Yeah, because if you have built an automation script that let's say does a canary deployment in a production cluster and all of a sudden you make a typo and you've never tested it before, then yeah, have fun. Hopefully you have some auto remediation in there.

Yeah, that's why I really like this new concept of GitOps where I think it is really important, especially when we start creating more infrastructure as code and when this infrastructure as code is also doing very important stuff, right? It's important to also treat them as just normal code, right? Or maybe even more carefully, because when you just add a feature, maybe, okay, one microservice is down, right? But if you have a script that configures, like you

said, IngressController or some more important stuff in the cluster, then you may actually ruin the whole thing, right? So the whole thing is down. So definitely, you need testing, integration testing, before you actually apply that to production cluster. And I think, or I hope, it's going to become standard also very soon.

You have a really cool section on your Tech World with Nana, the DevOps Bootcamp. And I actually thought when I asked you earlier, what should people do when they want to get started with DevOps? I thought, yeah, the first thing is you go to my DevOps Bootcamp. You didn't self-promote, but I'm promoting this now. But I want to ask you not to give a full overview, but can you give a quick pitch on what do people learn in the DevOps

bootcamp and why do you think it makes sense to go there? And also, what do they learn i mean quick audio if that's something because you know a lot of people are they want to become devops engineers and the bootcamp sounds like an interesting idea yes and i i think this was actually feedback from many people that they were thankful that there is such such a product because i also saw that you don't have this step-by-step structured thing where you go through it and you learn all this stuff. So what we actually did was, or what I did was, I set up calls with my viewers, subscribers,

people who are interested in DevOps, and actually asked them, so there are Udemy courses out there. They are my YouTube videos, right? That you, that you watch and you can learn Docker, Kubernetes fully. So what is, what is still missing? Like what, what are your pain points? Especially while you're trying to become DevOps engineer, right? And the most common thing that people were talking about was, so they learned Docker and Kubernetes on my website, on YouTube, right, for my videos.

And they went to Udemy and they learned AWS there and they learned Terraform, whatever. But these courses and videos, they're about one technology, right? So you learn Docker and Kubernetes, but what about like the combination, right? So how do you use Terraform with Kubernetes? How do you use Jenkins to set up a CI-CD pipeline with Docker, Nexus, Kubernetes?

The whole thing, right? Exactly as I said, as a DevOps engineer, you're not specialized in one tool. You have to be able to juggle with 10 different technologies. That was the main thing missing because that's actually the most difficult thing to find in documentations because in Kubernetes documentation, you're not going to read a lot about how to integrate

into different CICD pipelines. That was actually the main focus for us to build a structured guide. So you don't learn like tool by tool, but you learn like you go through like a path, so to say. So you start with now we are adding Linux because, as I said, you need some basic basics to start with in DevOps. And, you know, you learn Docker, you learn Jenkins, and then immediately you learn how to integrate Docker in DevOps. And you learn Docker, you learn Jenkins, and then immediately you learn

how to integrate Docker in Jenkins, right? And then you learn AWS and Kubernetes, and then you learn, you have demos and projects how to use these four things together, right? And how all these kind of combines. So I think in terms of that, that's like something that was completely missing for people and the most difficult thing. And I also think when you apply for a job

and you start working as a DevOps engineer, like let's say a junior DevOps engineer, I think it's probably one of the jobs where you're mostly overwhelmed at the beginning because the people are going to come to you, oh, there's a DevOps engineer. Let's give all the difficult tasks to this guy. Exactly.

So another thing, and that was actually also from the feedback, was people just didn't feel confident in their abilities. Like they've learned, they've been learning for two, three months, like a hundred technologies, but they didn't know, like, am I ready for a DevOps task? Can I, you know, can I perform at a DevOps job? Like they were really stressed about that, especially as an entry-level DevOps engineer.

So that's another thing that we kind of take away from them. Because when you have built like an end-to-end, fully like 10 technology combination processes, you know how things work, right? And in each category of DevOps, like the CI-CD pipeline, the infrastructure as code, Kubernetes, containers, container orchestration, cloud, in each category, we have one tool. And that's also something that I believe in, is when you learn one technology, you are going to be able to learn similar technologies very easily because the concepts are similar. Exactly, if you understand the main concepts, like if you don't just focus on the technology but also the underlying concepts,

it's going to be super easy for you to learn new stuff. So, yeah. Hey, I have one more topic that I want to throw out, but I'm also a little cautious of time. So before I throw out the topic, I want to ask you, is there anything else? Because I remember when we talked about doing this podcast, you mentioned, hey, it would be cool to pick up some of the questions from the brett fisher interview that you gave that you couldn't answer is there anything still in there that we haven't

covered anything you want to throw out that you remember why i would have loved to have time or do we cover a lot of it i don't remember any of the questions actually you don't have memorized the list i didn't remember this one as well like the names of all the people you're going to get your revenge on like we all carry around with us i remember like mostly like topic wise they were all around like uh how do i get into devos like where do i start like this entry level thing yeah and the other category because i looked at the because if you watch the thing on youtube you see the the chat history and a lot of the other set of questions was around uh you know what's the tooling everybody was asking what is the right tooling what is the

right tooling and this now brings me to rephrase that question to you and i think you answered it earlier but is deciding on the right tool the first thing you should do or not when you go into DevOps? No, absolutely not. And that was probably one of the reasons why Kubernetes became so popular because it was kind of like the new hype. So everybody was like, that company is using Kubernetes, so let's use Kubernetes as well. And we had no idea what it was.

What is it? Do we even need it? I mean, it's good. It turned out pretty well for Kubernetes and the whole DevOps world. And that's actually a really good question because I see a lot of people, also the teams that I do consulting with, right? Should we use this and this and this? And I always try to, because first, before I tell them

whether they should use the tool or not, I tell them, let's go through the processes. Let's see what is the existing process, right? What kind of application are you deploying? How are you deploying it? What are your offline processes, right? How kind of application are you deploying? How are you deploying it? What are your offline processes, right? How is the whole delivery? How does your

how do your sprints are designed and how do they work? And then based on the existing processes, we decided on the tooling, right? Because it's the wrong part to start with, right? First of all, do we have a problem that tool solves?

If not, then we don't need the tool. Yeah. Cool. So now to my other question. Now, we talked about DevOps a lot, and it seems in the discussions we had, we focused a lot around automation of delivery, pipelines, building, deploying, testing, promoting, and all that stuff. I've been kind of active.

I wouldn't say active, but I kind of have been trying to follow the DevOps movement over the last couple of years. I did a lot of presentations, but in the last year especially, I also talked a lot about SRE, site reliability engineering. And my definition, or at least where I try to explain, and this is one slide that I have,

where I see DevOps and SREs kind of working in the end, hand in hand, but coming from two directions. And I want to just get your feedback on, because this is a slide I'm using a lot, and I want to just maybe get it validated so that you can say this is complete bullshit. You need to change it.

Or maybe I have something there. But from my perspective, DevOps is using automation to speed up delivery. And they are measured on things like deployment frequency, lead time to change. These are two of the DORA metrics. And there are more other metrics. But DevOps is really like using automation to speed up delivery and hopefully also increasing quality. On the other side,

and this is where I see the SRE movement coming in from operations. If you have constant more change coming in, then you want to somehow protect your SLOs, your SLAs in production. How do you do this? if the guys over there are using automation well you use automation in production to make your system more resilient because you want to make sure that your I think your change failure rate and your time to restore

services and the other two big metrics on the Dora Institute stay in acceptable levels so my question to you now do you see this as well? That is that kind of two teams still kind of the, the, from dev to ops automation or from, from dev to ops teams, and then the other one from ops to dev, both using automation and in the end, trying to deliver faster, but still maintaining the stability of the systems. Is this how I get it right or not? Like per definition, that's exactly right. Like that's the idea behind it. That like DevOps is coming from the developer side and the other one is coming from the operation side

and they kind of, you know, have to work together. For me, it makes complete sense why there was a need for another kind of chain, like part in the chain. And the reason for that is because the DevOps engineer kind of emerged. First of all, DevOps engineer was not even an engineer, right? It was a culture originally that was supposed to be

for bringing developers and operations together so that existing professions could collaborate. And that didn't happen because there was just too much space in between them, so there was a dedicated profession, so to say, necessary for that. However, the DevOps engineer profession also just became too large because when you think about it, sure, DevOps engineer has to know developer stuff, right? It has to know really well

how the Git workflows work in the team, how are the CICD pipeline design working. But on the other hand, the operations part as well, right? Configuring the, like, not administering the service, but really configuring, preparing the server environment and stuff. In addition to those two parts, they had to now learn

a lot of technologies that wasn't responsibility of either developers or operations, right? So, at the end, it is just a lot, right? It is too much so i personally see um uh that it's very logical and makes complete sense to have another uh part there that kind of is more towards the operations and another one more towards

developers because then at least we can like uh draw clear lines between those responsibilities and it's not one person who has to do like 80 percent of the of the stuff and to also share responsibilities um i still think it's too early in terms of like how it's actually implemented because i don't think there are many teams and many companies who have DevOps engineers as a team, but not just one person, and have the developers, operations, and SREs. So as I said, it makes sense, but probably we'll need some time for us to see that in real projects.

Do you have any plans to talk about site reliability engineering in your tech world with Nana? Probably. Probably. Yes. I mean, I like to, like, I realize that a lot of my subscribers and people who are viewing there, like, there are people who are interested in new stuff, right? Because, you know, when you come to learn, I don't know, Terraform and Kubernetes and stuff like this, like you are interested in new stuff, right? Because when you come to learn, I don't know, Terraform and Kubernetes and stuff like this, you are interested in new technologies. So I want to cover all the new concepts

and kind of keep track of what's new and what's coming. Definitely, yeah. It's a no, because I think the world needs content, especially in this new profession and somebody like you that can really deliver complex topics in an easy to understandable way are people that will

help our community to just adopt this faster and I really understand what this is all about alright Brian did we forget anything or did we i think we covered quite a lot there um you know it's funny i was just thinking about youtube today as i was watching some more of your videos nana and i have a lot of other not a lot but several other channels that i subscribe to for you know some like analog instrumentation or learning midi which is a computer interface to keyboards and all this.

I was just thinking, where would we be without YouTube? I mean, there's a whole other side of YouTube, which I'm not even tapped into, the whole dark side of it, right? But from the educational point of view, what an amazing tool, and the content that people like you are putting out is just so amazingly helpful.

So for you and everyone else that's doing all this great stuff, a real big thanks for me because I'm learning all the time from them. So I'm sure tons of others are. Thank you. Thanks. Well, I learned a lot of,

like when I started in programming, I learned a lot of stuff from YouTube. So same for me. It's replacing the call to your parents to say, how do I do this? Because you always used to ask them. Let me just look it up on YouTube. So yeah, for me, well, it's replacing the call to your parents to say, how do I do this? Cause you always used to ask them, let me just look it up on YouTube. I don't feel like talking to my parents. One last thing, because Brian and I keep talking about this. One of the cool things about running a podcast is you actually get to talk with somebody in a field that you would like to learn more about, right?

And then you have this person there for an hour and you can actually ask questions. So it's, it's actually, it's great for our listeners that they learn about you and stuff that you do in DevOps. But I think it's also very selfish from us because we also want to invite people that we want to learn from.

Do you feel the same way about your YouTube channel that you actually big things that you actually want to learn and therefore, and then get time and Fortunately, it pays off. Yes. Definitely. Yeah. So most of the content is definitely like, oh, that sounds interesting.

Let me try this out. And then, yeah. But then that's what actually makes it fun as well because it has to stay fun for you as well. Yeah. All right, sir, should we wrap it up?

Sure thing. Yeah. I don't typically, I do a summary, but it's hard to summarize everything, which is. We haven't done a summary in a while. That's kind of falling off.

I know. So Andy was the summer Raider to take off on the Terminator because he's Austrian. Right. So, but we haven't done that in a while. So I guess we'll just wrap up. So you mentioned, we mentioned, I think before the show started, some cons you were going to.

Do you want to, any that you want to plug that are coming up? Or any other thing that you want to plug that you have coming up soon? The next one coming up is docker con there is actually a german room a dedicated german room for the german speakers if they want to attend yeah and

that's it awesome alright well we'll put a lot of links to the stuff in the show notes I want to thank you very much for being our guest today thanks again to all of very much for being our guest today. Thanks again to all of our listeners for listening to us. And we hope to see you all next episode.

Thanks a lot, everybody. Bye-bye.