LIVE DevOps Career Workshop

LIVE DevOps Career Workshop

TechWorld with Nana 46 195 просмотров 1 703 лайков

Machine-readable: Markdown · JSON API · Site index

Смотреть на YouTube
Поделиться Telegram VK Бот
Транскрипт Скачать .md
Анализ с AI
Описание видео
Learn what it really takes to level up your career with DevOps | Make 2026 the Year You Go DevOps We'll cover: - The actual skills companies are hiring for right now - How to read between the lines of DevOps job descriptions (we'll decode them together) - How to bridge the gap from where you are to where you want to be - Real talk about certifications, projects, and what actually matters - The roadmap that's worked for people who've made the switch - Q&A - Answering your questions ▬▬▬▬▬▬ Connect with me 👋 ▬▬▬▬▬▬ INSTAGRAM ► https://bit.ly/2F3LXYJ TWITTER ► https://bit.ly/3i54PUB LINKEDIN ► https://bit.ly/3hWOLVT

Оглавление (49 сегментов)

Segment 1 (00:00 - 05:00)

So uh I think we are live. This is the first ever Tech Forana live actually. Let me see if my camera is perfect. Uh all right. So let me open the chat here. Okay. Now I see hello from Usbakistan, Canada, US. Awesome. Okay. Um, I have some really cool stuff prepared for you guys. But before we get into it, I really want to kind of get the energy from the community because I saw a lot of people have registered, which is amazing. And it is not surprising for us because we see exactly the interest and demand for the type of information that I'm going to share with you today which is basically DevOps career. There's so much happening in DevOps world. So many things changing all the time. Um that sometimes we engineers think how you know it's probably time to standardize everything and not kind of keep everything uh changing all the time. Um but it is how it is and let's use this session to kind of get some clarity about the next steps, career um steps, career goals, how to navigate this complex jungle of DevOps. Um I'm super happy for all of you guys who are joining. Um hello from Uganda I think. Hi from Georgia. Hi Beck India. Wow. We have the whole world. So, uh I'm right now in Vienna, Austria. So, in our time zone, it's 6 pm. Um so, I think I'm going to be going to bed right after the session because I think my approximate estimation is probably going to be like 3 to four hours including Q& A. And by the way, um I have a lot of slides prepared. I have statistics prepared. Me and my team research a lot about the job markets. uh we prepared a lot of uh data to give you some compressed knowledge but I think the most exciting part for me uh but also probably for you is the Q& A part because I want to hear your questions. We also received some of the questions before um that you guys submitted on YouTube community. So I'm going to try to cover as many of your questions as possible because I think that's you know the core of the content today because I want to make sure that all of your questions get answered. Okay. Um so that means um we have people from again India, Greece, Tunisia, all over the world. That's amazing. Um hi from heat sink. Um via Austria. Awesome. Um yeah, so including the Q& A, it's probably going to be three to four hours. That's an estimate. It could be shorter. Um probably not longer because then it's going to be like midnight here. Um, but we can get started already. Awesome. So, I'm scrolling the live chat and it's basically a lot of Okay. Um, so I'm going to tell you guys exactly when you can start posting questions so that your questions do not get lost in the chat. And Nicole is also on the live call and she's going to basically um immediately copy your questions. We're going to, you know, have bunch of them. So, we kind of we are going to try to categorize them so we can cover all of that. I have my water here in case I talk too much and my um my voice gets uh dry. So, I have everything prepared. Let's get started. Okay. Awesome. So, hope the slides are working. All right. Let's get to it. So, what are we going to cover today? What am I going to talk about? Um mostly we're going to focus on DevOps market the job requirements but also I'm going to do everything in a context of what's going on in DevOps what are the changes what are the trends what are the things that have become have remained constant because not it seems like everything is changing in the DevOps world because so much is happening and we're bombarded with this news but there are a lot of things that are staying stable and constant okay and it doesn't feel like this but in reality a lot of things like for example um a lot of the things that I was talking about five years ago on technology channel are still relevant sometimes even more relevant today um which means a lot of things are actually staying consistent so we're going to talk about that as well so you don't have the anxiety that you constantly have to keep up with the changes of course we're going to address the impact of AI and again it's not as crazy as we uh are made to believe or it seems um from the outside. It's actually way more chill than it is and I'm going to dive

Segment 2 (05:00 - 10:00)

into that. Um I'm also of course going to talk about uh career steps because we got lots and lots of questions from people who are junior engineers who want to transition into DevOps. You know how to uh what path to follow because I understand I was at zero as a DevOps engineer at some point and I remember looking in the future how overwhelming this whole thing was. So I'm going to try to dive into the road map and again answer a lot of your questions specifically about that. Uh and I also have some bonus tips about job hunts, how to prepare your LinkedIn profile, everything basically uh to make it useful for you uh so that you can so basically by the end of this call uh I want you to have much more clarity about your specific next steps. Okay. Um, and I'm starting with DevOps market and some major numbers, but at the end of the day, you don't care about the market trends. You care about what is it that you as an individual contributor, as an individual engineer have to do based on the data to um basically prepare for your next career step, right? What does it mean for you specifically? So, that's what I'm going to try to focus on and use all these data uh to kind of feed into that. Uh so that's my main priority because I know that's what is the most interesting for us. Uh we still have a lot of people joining seas service a lot of uh people from Europe, India, uh US, Canada. Awesome. Um okay. I try to keep the statistic as simple as possible because there are few number there are a lot of numbers but again let's narrow it down to what is the most important thing I'm pretty sure that a lot of you have seen these clickbaity videos on YouTube where people are like is devops dying you know is everything you know going to towards uh reduction in terms of devops should I still learn devops and this like kind of making people anxious because it's a clickbay title right people want to kind of get that um intrigue uh from people and this is just one very official and a lot of people have shared this specific statistic uh from the official source that just in one graphic I mean look at this it shows in very clear terms that DevOps is not dying I mean we 2024 right that was last year um the DevOps market forecast right and think of it what does DevOps market mean right think of all the DevOps platform forms all the technologies uh all the platforms that companies are using in order to implement DevOps and all the tools that they're using. So the glo the total market share of all of that right the estimate of how much that is worth all these technologies and all these combined and look at the prediction in so this is nine years right not even 10 not even decade like 81 billion I mean look at does that look like devops is dying and people are needing less devops and obviously this trend is fueled by companies demands right because if a lot of companies it's like a chain reaction or like a domino effect. If a lot of companies see value in DevOps and they um in the practices of DevOps um regardless of the tools, they are going to keep implementing them. They're going to keep uh you know investing money in upskilling their engineers. There are going to be more startups in DevOps space who are going to offer resources because they see the demand. So that's kind of the domino effect of that trend going up. that means develop skills for those technologies is going to increase directly proportionally because obviously that demand needs to be met somehow. So that this statistic should just show you DevOps is not dying. Okay, the trend is actually uh upward and uh because of AI it's even AI kind of fueled it and I'm going to get into that later. Um, so even though AI affected other engineering roles and kind of diminished their value, it actually did the opposite for DevOps and I'm going to tell you exactly why that happened. Um, and again tying it back to what does it mean for you as an individual engineer, right? Because you're not a company, you don't care about market forecast, right? So what does that trend actually tell you? Um and I remember like when when I think about me myself as an engineer whether I'm you know I was working at engineering pro projects or consulting companies and you know software engineering teams on different projects of course I need to reverse engineer from what is it that companies are looking for right so what is it that uh the IT leads the managers at companies are actually putting their focus on and again very clear numbers I Let's start actually from here. So 2023 we had uh 25% of organizations that uh

Segment 3 (10:00 - 15:00)

actively tried to bring like bring in DevOps in their companies and that means just think about this thought process. So you have these IT managers uh not all IT managers are technical so sometimes they don't understand these terms right. So back then most of them didn't even know what DevOps was or they didn't really understand the concept. So it was more like you know the other company's doing it so maybe we should do it too right? So it was kind of copypaste um type of approach. So by 2027 there is an estimation again based on official sources that 80% of organizations will basically say we need DevOps in our companies because we need to streamline our processes because it makes us uh competitive because our competitors are doing it so we need to implement this and that alone tells you that even those IT managers who have no technical knowledge they don't even like who don't understand DevOps even they already know that DevOps is mainstream and it's not kind Oh, should we do it? Should we not implement it? It's kind of like yes, we should do it because our competitors will be doing it. It has become so mainstream. It's not even debate anymore. And again, I mean, you can like you can find all this type of um data online uh where you have a very clear comparison of how it was few years ago when I started uh teching on a channel and I started sharing my knowledge on DevOps technologies. Um like a lot of company even my project that I worked at there was usually one DevOps engineer in the entire company most of the engineers themselves like not even engineers actually understood what DevOps was. they heard of the term but the concept was still like a little bit niche and now if you talk to like just think about your colleagues think about people who are not like deeply technical everybody knows DevOps already right it has become this mainstream concept and it's not a niche anymore so we're not like we're very far away from you know devops being so mature that it now diminishes and the demand is decreasing so we are in a very high maturity like we're going towards high maturity layer of DevOps. Um and um this leads to and this is actually probably statistic that is most relevant for you as an individual engineer because very simply put if companies put so much value in adopting DevOps because they have self-interest right they know that DevOps will make them competitive uh they can ship faster uh they can uh reduce the waste of their you know kind of manual work that engineers have to so their engineers can work on more productive stuff. Um so if companies are so convinced that they need DevOps but there is a shortage of talent that supply demand gap basically creates a tremendous opportunity for you if you really know DevOps skills right because that means that you have this massive opportunity because of the gap where companies are desperate for DevOps skills but there is way less people or fewer engineers who can fulfill this gap right who have this um talent and look By the way, look at this number here uh or these statistics. This was a survey where companies were asked what is your biggest challenge. So you want to implement DevOps in your company. What is holding you back? What's the biggest challenge? So we had you know we have legacy architecture. It's really hard to implement DevOps processes when you have a monolithic legacy architecture when everything is kind of running on bare metals. You're not on cloud. You don't have the knowledge so to say in operation side. So first you have to kind of lay the foundation uh you know have a cultural shift where you explain to CIS admins you know you shouldn't kind of uh keep your secret scripts on your laptops and machines maybe we should collaborate on this um you know operation side and introduce infrastructures code. So you have all these issues but look at the number one DevOps challenge that they have for implementing DevOps which is skills shortage which means let's say everybody's ready in the company everybody has signed up for it. Uh the the engineers are uh basically ready to implement DevOps but who's going to do it? Like DevOps is not something that you just learn in a weekend and start doing it the next day, right? So the skill gap of someone who actually looks at the process and say how can we migrate our legacy architecture to the modern one. How do we move to cloud? How do we uh you know streamline our release pipeline? How do we even create a streamlined CI/CD pipeline? What tests do we need? You know how do we operate and run Kubernetes cluster? So these are skills that are missing in so many companies. And by the way, I remember

Segment 4 (15:00 - 20:00)

um you know a few years ago when I was consulting uh companies, the managers would constantly come to me and say you know we are have been looking for DevOps cloud engineers for a year and we can't find anyone so we need to upskill our existing engineers. That's how uh high the skill gap was and as you see it hasn't changed because the demand is growing much higher and there are not many engineers who are become who are learning DevOps skills. Um and then we're going to dive into that who are those engineers what those profiles are and so on. And I see some questions are perfect. So keep the questions coming. Uh Nikki is gonna actually filter them out. We're going to categorize them because we want to try to make sure most of the questions get answered. I will try my best to answer all of those. Perfect. All right. Um, so let's go to some interesting more interesting stuff. And this is where it gets really um juicy and interesting for all of you and where most of the overwhelm probably uh comes in. And by the way, write in the chat if this resonates with you. Okay. Um, so you start learning different DevOps technologies, right? So you start with Kubernetes and Docker um and uh AWS cloud and you know GitHub actions docker whatever and then you think first of all do I know enough to apply for the jobs and second of all which roles do I apply for right should I go for devops engineer then there is platform solutions architect then there is uh you know cloud engineer then there is s sur and then there are software engineers who are asking to do DevOps. So what do I what do I apply for? There is an automation engineer. Um I think you guys see my mouse. I mean look at this uh array of DevOps jobs. Um yeah. So look at this like this is a list of all the job titles that cover some set of DevOps skills. And when you know these bits and pieces of technologies dev technologies and you look at this picture or this list uh I understand why you get confused because you don't know what to apply for they are expecting and the interesting thing is that if you think about the perspective of companies and organizations they are just as confused as you are because they are looking for a specific set of skills but they don't know very often what title to give that uh skill set. They have the same problem where they're thinking is this a DevOps engineer role? Is it a cloud engineer? Is it an S sur? Should we hire software engineer who has uh these skills? Should we hire a test engineer who can build a CSD? So they basically just randomly put out these titles, right? And as I said, I've consulted a lot of companies who um have put out those titles and I know how their thought process works and what their um point of view is. Um so let's clarify some of these points. Okay. And uh this could be part of your DevOps job market analysis which is by the way something that you should absolutely do. Um so let's put it in two categories. Okay. So think of DevOps uh in general not DevOps engineer but DevOps in general as like a umbrella term. Okay. um like ve similar to when we had this fullstack engineer that was supposed to know every everything. So we have DevOps and then we have specializations within DevOps that emerged from DevOps. Okay. So DevOps engineer was one of the specializations. Uh there was not meant to be as a role but it's that's how it happened. Cloud engineer became another specialization of DevOps role. Dev sec ops engineer became a specialization. platform engineer SR. So think of this as under the umbrella of DevOps. So DevOps is much broader broader. Okay. So for example in uh in our DevOps boot camp we teach [clears throat] it's called DevOps boot camp right a lot of people who do the boot camp they can apply for DevOps engineer job cloud engineer they can apply for platform engineer and for S sur because the tools that you learn are very like they overlap in most of the cases. Um but because DevOps is so broad, you know, back then when I was uh when I was designing the curriculum for DevOps boot camp, I basically just put everything that was back then part of DevOps and that included um for example administration part of all the tools

Segment 5 (20:00 - 25:00)

which is part of platform engineering. That included monitoring S sur job. for example, it included the cloud platform and the cloud infrastructure automation tools which is part of cloud engineer job. So all of that uh basically was automatically included and then it kind of emerged into the specializations where you have more like niche knowledge uh for example with each specialization so to say. So think of DevOps is one category with those specializations and then but that's probably like if you look at job market that's probably like 50% of the DevOps job or DevOps skill related job descriptions. Okay. So like basically the list of this uh job titles is just 50% of engineering roles that demand DevOps skills. So what the other 50% come from is this right here. So in many cases uh in lots and lots of companies because they are obviously more software engineers than DevOps engineers, right? What happened was kind of as a natural evolution was companies said we need to automate CI/CD pipeline. Uh we need to deploy to Kubernetes. Um who is going to do that? Software engineers. Right? We have software engineers. they're writing their application code already. So they should uh kind of extend their responsibilities and build an automate automated pipeline to deploy that application that they coded, right? And then they were like but where is that being deployed? Oh, on cloud and on Kubernetes. So they should extend their responsibilities and they should learn how to deploy their application that they wrote on Kubernetes uh and on cloud platforms. And who's going to manage that infrastructure? well they should manage it because that's their job to deploy it there right so very naturally it happened that software engineers um had to learn DevOps skills including Docker Kubernetes CI/CD and a huge amount of DevOps skill set is actually attributed to software engineer job titles okay so now if you actually search for software or let's say mid to senior level software engineer jobs you're going to see a lot of DevOps jobs DevOps um technologies listed in the job requirements. Um then you had another probably not as big of a proportion but very large portion of CIS admins um or network engineers who suddenly um were out of job for from those companies who said we're moving to cloud. So what is a network engineer who is you know kind of um working with the cables on an on-remise system need to do right so they had to naturally move to cloud or you had CIS administrators who basically now had to work with DevOps practices to automate infrastructure provisioning uh to move to cloud and learn cloud infrastructure automation. So this became the second biggest section and by the way uh if you have any of those backgrounds so if you're a software engineer CIS admin network engineer and you had to learn DevOps at your work uh as an extension of your existing skills please write in the chat and also share like what was your experience like and how that transition happened because we like we know from the data that we have actually like majority of our uh of the people who join our DevOps uh programs since the beginning like the number hasn't changed were software engineers and CIS admins like those were the biggest groups and the third one that emerged in the last two years I would say were test automation engineers um and here it's a little bit more specific because with test automation engineers or QA engineers what happened was that uh AI came and AI was like I can write automated tests much faster much better than do so you know they it kind of reduced the responsibilities and tasks of test automation engineers by half and there were a lot of QA um test automation engineers who were saying 50% of my job is now automated so what happened is that kind of got cut off so they had to stack on additional skills to stay valuable and to kind of keep their um futureproof careers so the natural ext extension was uh the CI/CD specifically CI/CD because uh they were already writing automated tests running them. So it was where do I integrate those tests? How do I spin up a quick uh infrastructure to run my automated tests? Right? uh you know there are tests that you run in the on a static code but there are tests which are more important that you run on running

Segment 6 (25:00 - 30:00)

application right so how do I spin up an environment where the application starts running and basically I run the test against that and all of that skill set became a new extremely valuable add-on um extremely valuable add-on for test automation engineers and going back to the pointif like almost 50% of job market requirement for DevOps skill set um actually comes to those traditional engineering roles and only the other half is actually the specialized DevOps roles which means um if you only take the DevOps specific uh or DevOps specializations as a market analysis you can multiply that by two and that's going to give you the real um perspective of how much demand there is for DevOps skills. And that leads me to the next point which is if you take one thing from this um live stream I want this to be one. Okay. A lot of people and I see this in questions as well uh in general think which role should I prepare for? Should I become a DevOps engineer? Should I learn from plat for platform engineer or I have all this um knowledge and skill set. Should I apply as a s sur or what is my knowledge um applicable for which job title? And as I said job title usually does not reflect properly the skill set. So forget about the job title, forget the roles, okay? Just forget that they even exist. Think about the DevOps skills in the first place. Am I able to create a fully streamlined end to-end CI/CD pipeline for a software application that takes the code that was just committed and deploys it all the way to at least development environment and then promotes it to staging environment right let's say not all the way to production but at least that if you can do that is the valuable DevOps skill of creating building CI/CD processes is that has a tangible value. Okay. Um think about another use case which is can I spin up a Kubernetes cluster configure it with proper security um with because you know you guys know that Kubernetes by default in many cases is not production ready right it is working it is functional you can deploy your applications to Kubernetes but it's not production ready there is a lot that out of the box Kubernetes configuration does not have which is by design by the way um I had an interview with uh with Kel Kelsey high tower kubernetes was meant to be um a flexible simple tool and then we kind of complicated it by adding lots of stuff on top of it but per se it's not production ready so think ask yourself am I able to spin up a cluster a kubernetes cluster configure it with production grade best practices um that I can deploy my applications to automated way from CI/CD pipeline so Those are the DevOps. So that's the question you should be asking yourself. Do I have those skills? Right? Not do I know Kubernetes, do I know Terraform, can I build those processes? Uh or if I join um a company that is working with legacy systems, can I introduce an automated CS8 pipeline in the process migrating their you know basically mapping what they have to the modern tools? Can I spin up an infrastructure on AWS? Um can I do it in an automated way with Terraform? Right? Can I spin up a thousand node currency cluster? Can I spin up uh a thousand EC2 instances that are all connected uh but with backups in different regions? Like that's the valuable skill that companies are looking for there. Again, think about company's perspective. They don't care if you have a DevOps engineer job title. If you don't have the skill sets behind these, then even if you have that as a job title, even as a in your experience, it's not going to help you get the job because companies want the skills. But even let's actually go even further a little bit further than the skills. Companies don't even care about your skills. Um, companies have their systems, they have their um, you know, software that they're building and they want to get it to the end users, right? with buck free, you know, secure and all this stuff and they have current systems. What they care about is an engineer joining the team who can uh optimize their processes, make things faster, uh reduce the manual effort, automate things in most cases, automate any anything that

Segment 7 (30:00 - 35:00)

can be automated. Uh automate observability or implement observability. So you guys, your team knows basically that things went wrong before they actually go wrong and the users, you know, knock on your door and say, "Hey, your app just crashed. We can't use it. " So basically be being proactive and finding those um issues faster. That's what they care about. The companies care about can you help us optimize our processes, speed up things, automate stuff, uh make our engineers lives faster because, you know, they don't have to do those manual things. That's what they care about and that then translates to DevOps skills and DevOps skills then companies try to at their best ability match to some random DevOps roles. Sometimes they get it right, wrong. So always focus on what is the skill set required to solve what problems for the companies and um actually and this is another interesting statistic uh which goes back to where we had it. Yeah. Uh as I mentioned most of the or at least half of the DevOps skill set actually is hidden in the software engineer job descriptions. And this is super I found this statistic actually um super interesting. The job role that required or that ranked the highest in terms of needing Kubernetes skill set was software engineer compared to look at the difference and again it tells you that there are way more software engineers than DevOps engineers which makes sense. Um but the DevOps skill set is kind of hidden here. Okay. And that's why when people say DevOps is dying, you shouldn't learn DevOps anymore. [snorts] Again, forget about the job title. The DevOps skills which obviously are becoming more and more demanded, they are in all those um in all these job titles that you're seeing here, right? They are in the software engineers have to know DevOps. DevOps engineers not need to know DevOps obviously and all these other um you know traditional or modern engineering roles need to have the DevOps skills. So I want to change your perspective from thinking about do I need to learn DevOps uh you know engineer skills to what are the DevOps skills that I need to learn but also not technologies but what is it that I should be able to build. uh most of the employers does not understand DevOps role. I know uh that is absolutely right and I um they don't understand DevOps role because it's not entirely their fault because it has changed so much and it was so broadly defined from the beginning that they were you know it kind of had to go through few steps to standardize and as I said those specializations was actually one of the good ways to define okay now we have a cloud engineer that has a little bit more specific skill set. We have a platform set than this broad devops. But that means if you are like a full rounded DevOps engineer uh and like me you had to go through the pain of learning all these technologies and skills because you had to at the beginning because there was just one DevOps engineer uh role then you are basically you cover all these specializations automatically because you have you had to learn this these skills um and that's what I mentioned when I created DevOps boot camp I basically just put everything in there that now translates to you know platform engineering to uh s sur to um cloud engineering because you were just a requirement back then uh for a devops engineer. Um [clears throat] so and that basically just gives you another set of statistics of um uh so we actually have a survey of um we have started this like four years ago in our programs and because I wanted to know like who are these people who are learning DevOps or who have to who are forced to learn DevOps and all the time like without exception software engineers were always top uh on the list in the rank uh who needed to and who were learning either voluntarily or nonvoluntarily those DevOps skills. So it remains till today that this is the largest group that has to have those DevOps skills and um I'm scrolling through your chat to see I think we do have a lot of software engineers uh in the session as our subscribers as well. So just some of you please write in the chat if you are a

Segment 8 (35:00 - 40:00)

software engineer that was forced involuntarily to learn DevOps skills. Yeah, sis system administrators are um I would say second largest group um after software engineers yeah and I mean you can basically find so many yeah that's and I remember when I was uh either consulting uh software development teams or when I was working myself as a DevOps engineer with um you know microservices teams. I remember how uh how much software engineers hated Kubernetes because they had to work with it um in addition to their like software engineering tasks and they were really forced to basically work with this tool that was too complex. There was no abstra abstraction of Kubernetes. Um and um you know there was the times where software engineers were kind of forced you need to you know you need to learn cubectl how to deploy to kubernetes you need to now learn how to you know automate CSV pipelines and I know it's not it was not the most um it wasn't the favorite thing for those software engineers to do um okay so now that I hopefully changed your perspective from thinking about uh job roles and asking yourself should I learn that was engineering should I learn cloud engineering should I become this or that uh to what skills do I should I learn and th this is going to help you long term because what if let's say five years from now there's no DevOps engineer title let's say it all dissolves into the specializations and DevOps engineer title disappears there is no single job description you know of DevOps engineer which is very unlikely but let's say it happens right theoretically the skills underneath that now you know are part of DevOps engineer uh skill set they will remain right they will just be part of like different roles different engineering um uh yeah different engineering roles because what companies need to do in their IT systems and in their um you know um with their applications that they need to release to the end users that remains So the challenges and the problems the companies need to solve technically they will remain and the tools that are going to solve those problems also remain. Uh AWS is not going anywhere. Terraform There is a reason why these tools became so popular and so demanded because they solve real problems. So even if you remove the job title entirely the skills underneath remain right. So now it's just a matter of uh thinking what are the tools that are most demanded and I learn um those skills those technologies and concepts and skills that allow me to solve specific problem which is can I build an entire CSD pipeline and what are this what are the technologies involved in that can I um administer and manage Kubernetes cluster or let's say it's already administered and it's already managed can I use configure um manage an existing Kubernetes cluster. Can I uh set up you know forget those two skills let's say you don't have those can I set up monitoring for the entire application ST uh infrastructure ST so and what are the skills or technologies involved for that use case so think about use cases that are valuable for companies and they're not even so many of those like what I just listed are probably like half of those right u and then what are the skills needed for that and you learn those skills and if you're if you as a selfch check. Like if you're able to build those end to-end projects with those skills, then you are automatically valuable and you can apply for whatever role uh the company um publishes as a job application that will basically build that process, right? And this is a really interesting statistic which was um based on an analyzing 400,000 job postings and look at these statistics here. So we have AWS which is very reflective of so many companies now moving to cloud. Uh because again when I started uh creating uh videos on tech roomana I remember so many companies were still on premise they were not even hybrid like they were literally they had their own private

Segment 9 (40:00 - 45:00)

clouds or they were completely on like you know operating on bare metals. Uh my first DevOps job I remember we deployed Kubernetes cluster on bare on our own um uh servers in Vienna in data center on bare metal uh virtual servers where we were literally installing the b the docker binaries for the runtime the kubernetes binaries like every I needed to configure the networking everything directly on bare metal because we were not using any abstract we were I wasn't even using the CLI to like the you know um what is it the AWS CLI or EKS control like these type of abstractions it was literally just Linux commands and installing all the binaries directly on the servers um and that was not an exception like a lot of projects actually had that type of infrastructure I remember a company I was consulting for they had hardware load balancers they were not even using software load balancers so there's A there has been a clear very fast shift to cloud which of course increased demand for cloud engineers and for those who wonder what is the difference between cloud engineers and DevOps engineers there's so many companies who are just using those terms interchangeably like practically if we really dive in there is a clear difference because cloud engineer means you are basically uh more focused on you know cloud platform like infrastructure ure you know let's say you specialize in one cloud obviously so you know all the services they're uh important for setting up infrastructure for your application but guess what DevOps needs to know how to create infrastructure on AWS how to automate provisioning and how to you know um deploy your applications um on that infrastructure so there is a lot of overlap actually so as I said DevOps is like an umbrella term and then cloud is like a subset of it which is just the cloud part. Okay. Um Terraform this actually surprised me a little bit but uh these two go hand in hand. Okay. Because if those companies who at some point later decided to move to cloud they also because Terraform was becoming so popular they obviously realized okay if we are moving to cloud let's do it properly. So let's use uh infrastructure as code to move to this cloud infrastructure so that uh we're not just taking our on premise mechanism or framework of doing everything manually and just moving that to cloud. Let's do it properly with automation as well. Okay. So Terraform and AWS uh demand at the same level makes sense because Terraform is basically used for infrastructure automation. Um, [snorts] and considering AWS is still the most used, the most widely used by far, um, cloud for most projects, it makes sense that the use of or demand for Terraform, um, you know, followed suit basically. Um, and another interesting thing on this statistic is look, Terraform is an automation tool, right? Python is an automation tool. Bash Jenkins is also an automation tool because it automates the release um of applications. Um obviously Enzible is automation. So on the top you have just one after another you have so many automation tools and the you know it shows very clearly that it [clears throat] wasn't just that companies moved to cloud or move to Kubernetes but it was that companies were seeing obviously a lot of value in automating things instead of engineers doing things manually which was a very standard way of doing things before um and I mean Kubernetes and Docker I think we're not surprised to see that on the list. And Azure is second largest and mostly used uh cloud platform. You also have GCP. Um the good thing about cloud platforms I would say in general is if you learn AWS like if you let's say if you specialize in AWS um as a DevOps engineer cloud engineer whatever if you switch to Azure and GCP like 70% of the underlying concepts are the same the names are different the UI looks different but like if you know the concepts you will know exactly when you switch to Azure Okay, where's the virtual machine? Where's the equivalent of VPC? whatever AWS service? Because they have literally the same services or same storage uh and compute services. Um

Segment 10 (45:00 - 50:00)

and yeah and then you have you know GitHub actions which is you know in DevOps boot camp I at the beginning I included Jenkins and we had in the last years we had so many people who were asking why Jenkins you know there are so many new tools you know why not GitHub actions which I know I agree with you GitHub actions is cooler uh GitLab CI is cooler than Jenkins is outdated um you know you have these plugins that are maintained by some people and you have to you continuously maintain that um well there is a market demand okay so Jenkins I mean look at the difference Jen GitHub actions is extremely popular and widely used especially anyone who is um starting who's creating their own first CSV pipeline I'm pretty sure in 99% of the cases they will not use Jenkins right if they have the choice they will not go for it but it is still the number one most highly demanded skill right or technology in DevOps because CI/CD being the core of DevOps and Jenkins is the implementation of the CI/CD. So it is still extremely widely demanded mostly because of these large companies who still use Jenkins um you know and obviously it's working for them. So the pain of using Jenkins is not higher than switching to an alternative tool. So it remains and I believe I personally believe that it is going to stay uh like this for a foreseeable future. Um, and obviously if it doesn't, if at some point everybody just, you know, moves from Jenkins to GitHub actions or some other coold tool uh comes along that replaces Jenkins, obviously we would completely scratch everything and update the entire curriculum because and that's the thing like I like maybe with an exception of Kubernetes, but I don't really care about any of these tools like that a lot of people get attached to like I love Terraform or I love whatever GitHub actions like they're means to an end, right? They have a purpose. They solving a specific pro problem. So I don't really have any attachment on any like super crazy preference of for any tool. If something better comes along uh or very pragmatically if something is extremely highly demanded uh because of some obvious reasons then that's the tool where you know you should put your focus on and attention uh to and there is no nobody who is telling you not to learn alternative tools and I think actually uh learning Jenkins and then learning GitHub actions or gitlabci those two are very similar gives you a much richer overall knowledge of CI/CD concepts than just learning uh GitHub actions and especially just learning the most abstract uh abstracted um version of GitHub actions, right? Uh only using I don't know the built-in or out of the box features and not actually doing the little bit low-level stuff. So, I like starting with the complex low-level stuff because just enriches your knowledge and gives you much more depth and more layers versus just going to one tool and just saying this is the best one. I'm just going to stick to it. Especially if that tool is easy because of an abstraction because you don't know as much what's going under hood under the hood and it doesn't give you as deep of a knowledge. So some sometimes those you know painful technologies are good because they force you to learn a little bit more under the hood. Um before I move from this slide I want to I wanted to highlight two uh tools Linux and Git. Okay. Uh do you remember I told you software engineers are the ones who are uh who need to learn DevOps the most probably uh sometimes even more than DevOps engineers like in terms of numbers they're they actually outnumber um when I was so I have a software engineer background when I was working as a software engineer in multiple projects um 90% of software engineers in my team including me by the way did not know Linux um I don't know if that's your experience as well. By the way, if you were a software engineer, you did not have to work with Linux and most of them didn't care about Linux or learning Linux. Now um if you think about Linux in the context of DevOps like I think this should be actually put uh even higher in the context of things because best scripting you need to learn uh Linux uh if you're working with Jenkins like you want to install tools um uh you know on the Jenkins agents you want to manage Jenkins agents uh you want to

Segment 11 (50:00 - 55:00)

configure or run commands in the Jenkins pipeline you need to learn Linux because most probably you know it's going to be Linux based the entire cloud is you know mostly based on Linux right the EC2 instances um I mean Kubernetes docker like you know if you're working uh with Kubernetes if you're working with Docker uh yes I mean there are some desktop tools and abstractions but in most cases you're going to need Linux knowledge enzible modules you're executing Linux commands in many cases right so I think Linux is kind of became non-negotiable already and uh and this is interesting so the Linux was the became the non-negotiable for software engineers and git which was a software engineering tool became non-negotiable for CIS admins and the reason for that was CIS admins um we again have I saw in the chat we have a lot of CIS admins actually which is not surprising because I know they're they are second largest group that moved to DevOps. Um they basically um so put it to put it in context uh they were very used to um just having these scripts on their uh you know laptops or in their not just laptops like they would have these machines that they like when I was for example managing the Kubernetes nodes and directly sshing into them. I remember I had like scripts and you know uh when the colleagues would log in like we would share those uh scripts and you know it was like very um decentralized right uh and there was no like there was no coll culture of collaboration on code and scripts between the CIS admins. So when we were managing the Kubernetes nodes, uh the servers, the virtual um computers, you know, the or the infrastructure configuration, there was no culture of collaborating on those configuration changes. It was like everybody just executing their own commands and scripts. So with the infrastructure as code, with the Terraform, we're basically saying, you know, you're not sshing into servers. You're not executing some weird scripts from your own machine. You're not even executing commands. Everything is coded as a script in terraform, python, enzible whatever bash scripts and it's shared with git collaborated on just like application code and we are working on it as a team and all the changes go through the you know automation process like CI/CD pipeline which by the way gave us githops right so it was like a reverse of the so CIS admins now they had to work same way as software engineers so they had to learned git for example. [snorts] Um all right so enough of those stuff. So I have um actually I think this probably would be interesting for a lot of you because I saw it in the questions before that you guys submitted um the DevOps uh like in general uh jobs across countries you know across continents across companies um that require DevOps skills. I specifically focused on DevOps jobs, but as I explained, um you can if you search for the skills like if you search with CI/CD, Kubernetes, whatever, you're going to find jobs that do not only include DevOps engineer in the title, but also other ones, but we can focus on those ones. Um let me check some of the questions here. Yeah. Uh the I just exposed the CIS admin live. Yeah, I'm going to talk about envelopes and some like new trends. Um by the way. All right. So let me Oh, that's what's coming after impact of AI. So, and by the way, um we can keep this quick, but I just wanted to show you I mean I encourage everyone who is attending um to do market research in terms of like it doing this what I'm going to show you right now gives you so much data and so much um so much better understanding of like what's going on the on the job market in general. Uh like just analyzing and comparing like 10 different um uh job descriptions. You could be devos engineer, could be cloud engineer, could be software engineer that requires DevOps skills. you're gonna get so much data and so much deeper understanding of things and

Segment 12 (55:00 - 60:00)

get some kind of vibe of like what's going on generally uh on the market and how are companies thinking about this. And always when you do this type of analysis, please always think that companies usually in most cases when they post the job descriptions, they probably don't know for sure that the job title is right. Maybe an HR manager wrote the uh entire thing and they just copy pasted some template. uh probably the job description uh and requirements are way too exaggerated and the title may be misleading. Okay, so always assume this is not the perfect job description. The companies don't always know what they're doing. Um and it will put things a little bit in perspective. Okay, so let's just go through um a few of them and I want to show you um this is actually great news for you guys. So imagine if you were an engineer and you learned a specific technologies and set of tools and uh in one company let's say and you got practice and you got experience in that and now you were looking for another job and you were browsing through different job descriptions and every company requires completely different stuff that you have not used. Let's say you know one company has Jenkins another one has gitlab and there let's say there were like hundred other tools for CCD and every company just wanted something else right it would make your skills very difficult to transfer from one company to another but we're literally in the most luxurious position as DevOps engineers specifically as DevOps cloud you know the deal right the specializations that Most like these are literally just random picks that I that I chose from the research in most of the DevOps engineer job description you will find 70 to 80% of the technologies which are the same like they don't they literally do not change genkins AWS GitHub actions terraform and then you have like cloud form and this is like for every single category let's say CI/CD uh AWS you usually have like one alternative. Okay, it's not like 10 or 100 alternatives. You usually have one alternative like cloud form is an AWS alternative like AWS service as an alternative for Terraform. I personally think Terraform is great because I'm not a big fan of company specific um services and technologies because it still binds you. For example, Terraform you can use with every cloud, right? you could use hybrid platformation you know it's an AWS service um but as I said for every category there like maximum one alternative that the company requires and as I said like if you learn Jenkins and GitHub actions you have a much deeper understanding of the CI/CD concept itself because you know two tools which are relatively different from each other so it kind of enriches your knowledge but like overall the tools like Prometheus graph A um Cloudatch again is uh is like a observability tool for uh from AWS specifically which you know just lets you monitor the AWS uh infrastructure and then Promeththeus you can install inside um uh Kubernetes plus you can monitor the underlying infrastructure as well. Um let's check the other one and you have some compensations and salaries. Let's see what they require. um Kubernetes um well they have security stuff uh which by the way and this is also an interesting point whenever you have security requirements it's usually a senior level engineer so the more senior the the level of engineering is um the more probable that they require security and monitoring. So those tools are usually those two are usually um for senior level and they become very optional for like mid-level or entry level which is an observation that I did by analyzing like tons of um tons of job descriptions. So observability and security are usually for uh like seniority level and obviously this reflects the uh price right the salary. But let's see what else do they have here. um AWS, Terraform, Kubernetes, again usual suspects here. Uh GitOps, which as I explained is basically CI/CD for infrastructure is code. Okay, so you have CI/CD for application code. Now you have CSC for um infrastructure code and there are like different tools you know

Segment 13 (60:00 - 65:00)

the GitHubs concept itself did not introduce anything new as I said it was CCD for um infrastructure as code or like XS code but there were different ways of doing that right for example they uh fluxid for example which was a difference or conceptual change from Jenkins or GitLab CI or GitHub actions which was instead of a pipeline pushing the changes to the deployment environment it was a tool that was sitting in the infrastructure or Kubernetes cluster and pulling the changes whenever they happen right on the trigger but conceptually it's the same um GCP alternative to AWS um and then we have some uh what do we have here kubernetes terraform uh terrant which is like a wrapper of terraform helm which is uh you know I teach it with in combination Kubernetes in the boot camp vault fluxid because of uh githops um some software development skills but yeah as I said this is a senior level job description but even like the tools are like the DevOps tools are literally mostly the same um let's see this one where is it uh Um okay so this is where is this job? This is in India. Uh you guys need to translate this into uh dollars. I have no idea how much that is. Um but let's say the key responsibilities. This is interesting. I mean gitlabci as I mentioned alternative easier alternative like if you learn Jenkins then learning any alternative CI/CD is going to be a piece of cake because Jenkins is probably the most difficult one. um monitoring and observability Kubernetes um containerization helmch create uh health chart helm chart creation uh deployment to kubernetes what do we have here terraform enzible helm I mean literally like it's like every company copy pasted each other's um job descriptions here you have the skill requirements like terraform docker enzible kubernetes and that's what I mentioned at the beginning like when I created did the DevOps boot camp curriculum five years ago and I I wish I could copy it from someone but there was no curriculum for DevOps so I had to create it from scratch myself from my experience and every year me and my team sit down and we look at the we do this literally we analyze the job descriptions we analyze you know across the globe and we analyze the comments that you guys are leaving on YouTube because we take them as feedback and input and we do this analysis and we go through our curriculum and so we do we is there something thank you Nicole is saying that I need to zoom in larger awesome okay um uh what was I saying so yeah so we basically ask ourselves do we need to update something in the curriculum change anything uh add any new tool remove any tool replace anything and as you see this is the curriculum I created five years ago Uh let me show you like these projects literally this we cover a little bit more than what um most job descriptions want because I wanted to include a little bit more so that to make sure that we have everything there but literally like 80% is always the same. So the when we see when we have these discussions most of the question is no Jenkins is still number one AWS is still the most demanded uh like we later I did create GitLab CI because I wanted to have like an alternative for people who wanted to learn you know something similar to GitHub actions or GitLab CI um other than Jenkins but these tools remained the same and it is good because I think we all have this perception of DevOps constantly changing because there are new concepts and tools emerging. But the core requirements and skills they have remained very stably consistent for the last five years because we we always question this like not even once a year but like almost every quarter, right? We whenever we have team um team meetings uh the engineers are basically saying so you know we have these questions and about these tools so we have discussions about new technologies in DevOps but it always remains that what like this core skill set of technologies and concepts are the core and they have stayed and they like there is literally no um visible like there's no signal of that changing anytime soon because I showed you the statistic of the most requirement required skills was AWS, Terraform, Kubernetes, Docker, uh, Linux, Enzible

Segment 14 (65:00 - 70:00)

right? It was literally the same things that you see here. Um, yeah, and this is, yeah, we can like we don't have to zoom in into every single job description, but just so these are remote DevOps jobs, by the way. Uh, write in the So, I've never had a remote DevOps job. I was not as lucky. Uh but drop in the chat did like all of you guys who are actually doing remote uh DevOps engineer jobs like you were sitting somewhere else and you were working for an American company or for an Singaporean company or whatever. Um like fully remote. Uh when I was an engineer, I had to go off to the office every single day and have standup meetings in the office. Um so tell me like uh what is like just drop in the chat. um whether you guys have remote DevOps or like DevOps related jobs that you work for another company and how that's working also. All right. So what I wanted to do is I basically just wanted to go through so here you have this uh there's a list view where you have just you know uh tags of technologies that are required. First of all, I mean, junior DevOps engineer, this is in Deutsche Telecom. Um, they just have I mean they have a very low bar of hiring. Uh, they just need one cloud platform, JavaScript, not even a framework of JavaScript. Python which I assume is uh Python for scripting not like Python frameworks for web development and Terraform like no docker no Kubernetes no you know um enzible no other stuff that's and I see this consistently uh when I do analysis because I always look at junior DevOps engineer jobs and the bar like entry bar for junior DevOps engineers is so low and it surprises me to be honest when people tell me I can't find a you know I can get interviews or find junior DevOps engineer roles because I'm like they their requirements are so low like you literally like it's so easy because they usually require like very basic stuff and the major difference is that as a junior engineer like whether DevOps or whatever uh whenever you check the job descriptions compared to more senior or mid-level The difference is not just the tools, it's the level of responsibility. So for example, in the senior role or mid-level, you would say you are going to build a complete CI/CD pipeline and you're going to own that. in junior levels engineers gota there's a pipeline built and you're just gonna support that or you're gonna be working on like one step or like so you have like very low responsibility [snorts] and again as I said like in when I created the curriculum I was like how do I take my knowledge which was like you know whatever knowledge I had like the maximum and how do I put that into um into the boot camp and I didn't think about I'm gonna prepare people for junior devos engineer role. I was like how do I prepare them for the same with the same level of knowledge that I have because why should I hold anything back. So that's why it turned out to be huge. Maybe that was a little bit of a mistake because maybe some people just want to learn to the certain point to just get a job. Um but we literally just included like all the like little bit more advanced uh stuff. So like we I think we're covering like 14 to 15 technologies and then look at what junior engineers are required just four of them. Um and then you have cloud operations engineer which is another term by the way another engineering role cloud operations engineer. Again you learned from me ignore the job titles. Okay, literally they are just whatever random um check the job description and look for like literally scan for and you can take the job description put it to the AI and say based on the job description what processes what DevOps processes do they want me to build or do they want the engineer who applies to build and then what skills are required to do that and you have your answer and again AWS cloud EC2 I think that's it let's actually check this one where is I'm interested to see what they actually require. Configure, monitor, maintain application services in AWS cloud environments, virtual servers. Okay. So, this is a little bit uh yeah, this is this sounds a little bit legacy system type of um thing. So, they're not using like many modern tools.

Segment 15 (70:00 - 75:00)

tools. uh which by the way is that's an interesting topic. So, um I had uh so we had one boot camp graduate that I talked to and um he told this is actually an interesting or valuable advice for you guys and I use this in my career all the time when I applied for jobs or when I was switching from one company to another or doing the consulting work. I didn't so obviously they interviewed me but I just the same way I interviewed them because I was like what tools are you using in your company because I didn't have interest to work uh in a project that used some legacy tools that I would never use anywhere else or that would not learning them would not uh advance my career because you may be working in a company and spending uh 20 hours a week basically of your engineering work um learning their like internal tool that nobody else uses and that is a wasted 20 hours that you could be learning uh like an open source tool that is widely used like Terraform or working with Kubernetes because when you switch or when you look for another job that internal thing that this company is use I mean you can put it on your CV but it's not going to be as valuable right as saying you know I've automated the entire infrastructure with Terraform. So always, this is going to be my advice for you because I've used this myself all the time. Always choose projects that you work for. No matter how desperate you are for work at the beginning as a de as a junior engineer, always um select the companies that work with uh technologies that are going to be valuable for you to add on your profile. Okay? So if you see some type of a legacy um infrastructure legacy tools just look for something better. For example, this one look at this enzible AWS Docker Graphana looks perfect. They're working with microservices. They're using Open Shift. Um again just you know that statistic obviously reflects uh the one I showed you about the most required um tools AWS terraform lot of automation stuff Kubernetes is everywhere uh it was Kubernetes was not as demanded um even three years ago like you see Kubernetes in almost every job description where you see Docker and uh there was a huge discrep like it was not a case because Kubernetes [clears throat] was more optional tool and docker was a standard and now it has become the standard as well um yeah which basically just means that you need to learn Kubernetes whether you like it or not all right um I think it's enough with the job description but as I said I really highly suggest you know uh if you're looking in your own region um just look for uh DevOps jobs or you can even say uh DevOps uh related jobs or Kubernetes jobs or Terraform uh or infrastructure as code jobs in whatever region. Okay. And do the analysis to compare junior mid-level senior um and also one thing and I think this is super important for you guys. You see this two to four years experience, six years of experience, whatever, right? Like companies put this experience number. Um, I think I can give you one piece of advice that will completely change your perspective of how you analyze job descriptions. In most cases, they just randomly put a number. In most cases that will be absolutely okay for you to have zero years of experience if you can demonstrate to them that you have all the other skills that they require. Like if you say I can show you I can demonstrate to you with actual projects that I know all these tools and I can build the systems that you want me to build. I can optimize your processes but I have zero DevOps experience. They will still take you. So when you let's do something else. I don't like this job description. Um okay, this is junior. They don't they have a very low bar. They don't require anything from you. Um yeah, let's put this one. Two to five years exper experience in DevOps roles. Whatever. Whenever you see this, ignore. Okay. Just look through everything else. If you do not satisfy the other stuff like if you have no idea of CI/CD pipelines obviously yeah that's a problem but if you satisfy everything else because you have learned everything yourself you're confident that you can build CI/CD pipelines you have done uh those you know the little bit more complex

Segment 16 (75:00 - 80:00)

projects and you know you can build the CI/CD pipeline you can build a Kubernetes cluster you can administer and manage it then ignore this like if you have self-taught yourself or done actual projects projects, you know, build some stuff and put it on your g profile, git portfolio, but you don't have experience, you can still apply because companies will take you if they see that you can actually do what they require. This is literally an HR manager saying how many experience should we put there? How many years of Let's put two to five years. That's how it's done. Okay? So, do not put so much like they don't treat it as seriously. So do not treat this as seriously either. I hope that makes sense. YL is also one of the important skills that you should know. YL um uh I mean YL syntax itself is easy. Yes. Um I don't think you need to learn as much. But for example, if you're learning Kubernetes, you need to know Kubernetes specific syntax for YAML, right? Um, so it is I would treat it more like a subset or like sub um skill of another skill like Kubernetes for example. Um, all right. Interviews. Yeah, I'm going to talk about interviews as well. Okay. Um, oh my god, I have so many slides. Uh, maybe, you know, let's see how uh fast I go and then maybe we can take questions already. Let's see what comes after the impact of AI. How many of you have this question or have heard other engineers um uh other engineers ask this question anxiously? Does AI replace DevOps? And you know these clickbay uh videos where people are like AI is going to replace DevOps and it's going to take all our jobs and DevOps is not uh important anymore and so on. Um well very clear answer is the reality is extremely different from the hype. uh at least for now if something changes then yeah maybe we should get worried but right now it is like from the practitioners themselves and I've actually exchanged and talked to people who are literally just going like from one team to another and asking are you implementing AI is it actually uh you know um doing most of the engineering jobs uh engineering tasks and devops tasks and the answer is no um but and this is a very uh important distinction Let's look at this. So it seems like in IT or engineering roles in general there is a net positive impact from AI right so because of AI now we have more demand for engineering skills than before AI. Now that net impact obviously is the overall number right. So let's put it into two categories. There are engineering jobs that clearly got impacted by AI because AI started automating their tasks and they are very at a very risky and vulnerable position because yes they may get replaced by AI. they may become um obsolete and redundant because of AI and some of these roles are clearly test engineers. Um specialized software engineers. For example, if you have been a JavaScript developer or um I don't know specialize on one specific programming language. Um yes you are affected by or if you're a data analyst for example who was manually analyzing um and putting data and doing the analysis and generating reports. So where does the net p so obviously there's a very clear reduction of demand for certain engineering skills. Again let's talk about skills and not roles. So where does that net positive come from? because there must be higher demand somewhere else that compensates not only compensates for that reduction but goes even further right uh I don't know if I can zoom in no yeah the the thing is oh okay I can do it some work around of zooming in um yeah

Segment 17 (80:00 - 85:00)

the screenshot is just too small uh so where does that surplus come from and I have to zoom out again and this is the this is where the surplus is coming from. So because of AI, so what happened is every single AI project, all these ML and AI startups popping up because they get funding and because everyone is jumping on the AI uh trend means they need an infrastructure to run those AI and uh machine learn AI tools and machine learning models on right. So increase in cloud engineering skills in infrastructure automation skills. Um that infrastructure needs to be managed, automated uh properly uh configured which increased again cloud engineering and DevOps engineering skills that machine learning those machine learning models need to be released just like application or software needs to be released right which means MLOps right or which is DevOps for machine learning models basically. uh then you have you know all these different tools uh like let's say you have um a company that is implementing AI everywhere which means all those teams now need uh common uh practices for deploying them with CSC pipelines using kubernetes cluster to deploy those different models so you have need for platform engineering so basically that pushed the demand for those specializations s as you see here, cyber security or security around or compliance around um the AI projects that pushed it extremely high. Which means while so if we put this in into categories people who sit at their computers and write code or scripts their value decreased because logically what they are doing is automated or can be automated done much faster by AI. But on the other side, the demand for skills which is managing infrastructure where machine learning models will run um or platforms that host those AI tools will run. Um demand for managing the infrastructure you know most there's a the statistic that shows that most of the machine learning models are running in Kubernetes. Okay, OpenAI So that increased the demand for like imagine what that did to Kubernetes, right? And that's why it's demanded in every single job description. So there's a clear trend of what skills decreased in terms of value and demand and what skills increased. And um again like this one is literally DevOps for machine learning models. And this actually shows the uh the skill gap or basically organizations who are underststaffed in those technologies. Right? There's 70% of companies who basically say we are looking for MLOps or DevOps engineers who can manage these infrastructure and operations and we can't find them. There are literally not enough people in this world to fill these roles. And now imagine how willing they will be, how much they will pay and accommodate in terms of whether it's relocation or you know taking your entire family with you if you're applying from another country to get people who actually have those skills because of the like 70% that's actually crazy uh in terms of skill gap considering I mean sure MLOps is a new thing but DevOps is not new and this is like 80% DevOps and that is actually our next slide I think. Yes, I remembered correctly. So, um I saw some questions of people asking about MLOps and I know when we hear these hot buzzwords, you know, we want to understand because are we missing something? We get this FOMO of what is MLOP? Should I switch to Malops and jump to it? I'm going to um calm you down because the good news is if you have been learning DevOps, if you again talking about skills and not the titles. So let's forget about MLOps and DevOps. What are the skills under the if you have learned these skills and let's actually zoom in again. Look at this docker containerization right uh I think Kubernetes missing here but um as I said most of the machine learning models are running on kubernetes so um docker kubernetes continuous deployment um csd uh we have sage maker which is AWS service basically for like one-stop shop for um machine learning models continuous integration uh Jenkins

Segment 18 (85:00 - 90:00)

GitLab GitHub action So except for like one or two tools here and others everything is the stuff that we know from uh DevOps right um like the fundamental skills are the same and this is even not including everything like um do we have AWS? Yeah, there's not even AWS here, but obviously you need to like all those models are running on AWS and all the platforms, these AI repper platforms basically are also running on AWS and when you're creating a AWS infrastructure, you're using Terraform to automate that literally the same tools as DevOps. Okay, the only difference so let's say you are a DevOps engineer. Let's say you did our DevOps boot camp and you have like all these DevOps uh skills. You probably have a little bit more than what you need. So you will not be using all of that all of this stuff. But let's say you want to move to uh MLOps, right? You want to become an MLOps engineer because you see higher salary because companies are crazy and uh you know desperate and they want to uh attract you. So what would you need to learn to close that gap of that 20 20%. Um the easiest way to understand the difference is with DevOps you are taking a software application and releasing it to the end environment and managing the whatever that environment is. Right? With envelopes, you're taking a machine learning model instead of software application and you're releasing that to the end environment and the end environment looks exactly the same uh in the both scenarios and you have to manage that. So the only difference is uh so the question would be how much as a devops engineer how much of software engineering do you need to uh know um you don't need to know programming even know um I mean you're not going to be writing code right programming as a devops engineer if there's a company who asks you as a do devops engineer to write code and program new features then they clearly don't know what devops engineer is um but in general you only need to understand the integration point between when I take the code that software engineers wrote how do I then deploy it all the way to production so I need to understand build tools uh how to package the application how to build a docker image out of that how to run tests so obviously you need to understand how to execute tests on the code um you know maybe do security scans and so on uh so you need to understand generally how software is written, how it's configured. Um meaning uh if I have a software that talks to database like a back end obviously I need to understand how that connection works and how do I uh give my backend application credentials to talk to database to talk to vault to talk to APIs to talk to other services. So that's the part of software development you need to understand as a devops engineer. So with the same logic as an MLOps engineer that integration point of how do I take machine learning models and how do I dep how do I test them how do I run how do I validate them and how do I deploy them all the way to end environment that's the part that you need to learn you don't need to become an AI engineer you don't need to learn how to build machine learning models how to um you know validate and feed data that's a different skill requirement. Again, if company asks you to do all of that, obviously they, you know, they don't know what they're talking about, but that's the difference basically. Um, but as I said, it's just a different title. The underlying stuff is the same because when you think about it, the environment where this the software or machine learning model is running is the has stayed the same. It's Kubernetes. this containerized environment which is on cloud which is managed by you know terraform because of the um you know modern concepts of infrastructure as code um githops in terms of yeah how do I say this quickly? So basically um infrastructure that is automatically provisioned configured updated right not by humans with executing certain scripts. So that part has remained exactly the same. Uh and that's why 80% overlap. Um all right. Um this is actually a really interesting um snippet of the

Segment 19 (90:00 - 95:00)

conversation I had with Brett Fisher. Um if you guys know him, he um actually he has been teaching about all about Docker and containers. um he is now doing really good content about AI for DevOps and um I had an interview with him or I had a conversation with him which is which we're going to post actually on our YouTube channel. super interesting and we literally just zoomed in and talked about all the aspects of AI for DevOps, DevOps for AI like what does it mean and all this stuff and this was super interesting for me because he basically mentioned that historically like whenever you had these changes in like the next step breakthroughs in terms of how much the productivity of a single engineer was unlocked because of a new tool or technology or platform um whether with automation or whatever. And historically speaking, whenever h let's say one engineer was suddenly able to manage thousand servers instead of 10, the companies didn't go like oh so we need 10 times less engineers now because one engineer can manage you know 10 times more servers. Instead they were like cool now we can have more infrastructure now we can uh build more apps now we can deploy faster we can deploy copies. So the demand for engineers did not go down. the companies uh just became more hungry basically and they were like oh we can do more with the same number of engineers so let's go with scale and we actually see that because we have like uh I talked to an engineer at AWS um in Seattle and he was working on this interesting project where they were helping a client deploy or create and manage a 100,000 node Kubernetes cluster and Kubernetes uh I don't know if you guys know this limitation but Kubernetes per se like does not support I think the maximum number of nodes that like one single Kubernetes cluster supported was 10,000 I think that was um the last time I checked so obviously they had to do like certain modifications and uh you know expand the whole thing for that to be uh possible but that like five years ago or even 10 years ago like you could not imagine companies or teams would not even think about having a cluster like one unified unit that would have 10,000 uh 100,000 virtual servers underneath within the same network. So that's the level we're talking about and prediction is and I also think it's super logical that if AI unlocks your productivity as a single engineer it doesn't mean that they are going to fire everybody else all your colleagues it just means that the companies maybe it's a good thing that companies are hungry and uh little bit greedy because they're going to be like oh we can you do more with the same uh amount of engineers or one engineer can do so much so let's hire another one because then they can add even more value uh to whatever we're trying to achieve. Um so I thought that perspective was interesting because it should take away the fear of people thinking that companies will suddenly just scale down because uh you know because one engineer can do 10 times more or uh is more productive than uh before and uh let's see what the yeah one thing that I wanted to mention here and actually let's go to the next slide which is the road map um because I wanted to address an important this ties to whatever I talked about in the previous slides. Um I've heard many times from people um you know a lot of people have this perspective of there are enough DevOps engineers already out there like do I still need to learn it like clearly I you know now because I showed you all the statistics and data instead of just opinions uh that there's a skill gap um but a lot of people still had this perspective of you know there is there are already so many people who know DevOps So what you know there is no supply demand gap anymore. So it doesn't make me safe or secure anymore to learn DevOps or and that was confirmed by situations where uh and I've heard this often as well where someone said um I had a you know friend who got a DevOps engineer job and they were fired right or I've heard so many DevOps engineers who were let go and that contradicts with the statement of if companies are so desperate for DevOps engineers if there's the the gap right

Segment 20 (95:00 - 100:00)

thank you okay so there is such a if gap and demand and there's 70% of um supply demand gap basically how come that there are DevOps engineers who get fired by companies right it doesn't make sense well it makes sense if you think about what's under the hood because there are many people who have devops engineer title in LinkedIn uh or um or they even work as DevOps engineers in their current work who don't know DevOps engineering and it was a surprise for me at the beginning but it is a very realistic scenario where there are people who basically are given this title because probably the IT manager or the employer doesn't know what the DevOps role requires so they are given this title or junior DevOps engineer who just doesn't know DevOps and they're sitting there okay I need to build a CI/CD pipeline but I have no idea how to do that because I don't have the skill set but I have a DevOps engineer title and of course it makes sense for a company to um basically at some point see okay you know that person is not able to build CI/CD pipeline and we don't have uh engineers in our team to either validate his knowledge or teach him or her so that they get to the point where they become productive for the company because there's no one who can actually take over that role. So those engineers get fired because company now needs to look for someone else who can actually build those things. again the title versus skill set and what you can actually do and that is the explanation for this seemingly mysterious thing of why you know why are DevOps engineers getting fired if there is so much demand for it and that's literally the let's go here that's literally the um supportive claim of like if the company like if you have the skill set and if you are so much more productive because of AI no like company's not going to fire you doesn't make sense because you are now 10 times more valuable as a single engineer and um yeah so to tie that back to the road map um because I think it comes down to the pro problem of a lot of people again who have the devops engineer title they don't know how to self- validate their knowledge like I've learned all these technologies and I have done docker and containers and g and whatever but am I ready like am I ready to apply for the uh devops engineering role if or many people they work as devops engineers and they feel like an complete imposter because they're like actually don't know what I'm doing or I know these technologies but I can actually build those processes um so that comes down to how much you need to learn and to what level and [clears throat] okay I see a question of whether there's a road map for two months instead of six month um let's talk about this so this was so as I told you guys um when I created DevOps boot camp there was I couldn't find a road map or like a structured curriculum for DevOps so I basically just sat down and I creating This road map took me probably 20% of the time of creating the entire program. That's how um deliberate I was about this because um the question of like if you want to learn DevOps in two months just think about this DevOps is one of the most complex set of skill sets uh if you want to learn it properly and I would argue that yes it could be that you are a little bit impatient because you want to get a job and you could get a job as a dev junior DevOps engineer [clears throat] but going back to what I just I highly suggest you not to learn just enough to become a junior DevOps engineer. The job requirement that I showed you where they required like four things that you knew four things. Yeah, you could learn this in two months. But like what is the ultimate goal? Like if you become a DevOps engineer or join a company with whatever the DevOps skills that require, you want to be able to walk into your job or if you're working remotely to log into your computer and from day one be able to, you know, look at their systems, look at their CI/CD pipeline, look at their Kubernetes cluster and know exactly where to configure what, what to optimize, how to

Segment 21 (100:00 - 105:00)

do it. you know containers, you know Kubernetes, you know how to troubleshoot and debug, you understand the networking concepts behind it. If you know basics of things and if you learned in two months, I would argue you cannot learn as deeply um the complex level of DevOps, then you're going to be sitting there feeling like an imposter syndrome. And yes, you did a shortcut and you got to you got your job in two months, but it doesn't like the state that you're going to be in is not going to be satisfactory. Like you you're going to feel like there's still so much that you need to learn in order to feel confident. And I would argue that it's way um it's much worth or how do you say it's much better to invest that additional four months so that when you actually start working or sit at your computer and log in you have this clear understanding in your mind where you look at the Kubernetes cluster you know exactly what to optimize you look at the CICD uh um or a set you know set of tools that they have and say okay we need to uh speed up this process and I know how to do it. We need to refactor this part. Let's add a state file to Terraform because that's not a best practice. Let's secure this part of Kubernetes because that's not a best practice. Like just the difference between these two levels of understanding. And again, do you want to be just good enough to get the junior DevOps engineer role and then constantly have a fear of company uh firing you because your skill set is not good enough or do you want to be like I can build CIC like again the concepts are not like endless right you just learn how to build a complete CI/CD pipeline not just like one or two steps you understand how to configure a production grade cluster, how to use terraform to set up a complex a proper infrastructure and if you master those things like you're set for life. So I always argue for like in ter like from the perspective of like promising people and kind of luring them in and I could be like yeah let's do it in two month or three month but it's just not realistic because I genuinely want to give you advice to learn slowly deeply properly uh invest the time because That's the shortcut. Like that's literally the shortcut. I am a slow learner. Like if I when I was learning Kubernetes, I literally did like broke down like every single part of it. Even the parts that I was not using uh myself, but like the control plane components. I just wanted to understand how the architecture worked because the deeper your knowledge is the more confident you are about your skills and the more valuable your skills become. And when you're learning new stuff on top of that, it just stacks easily because you have so much surface level knowledge. um not surface level knowledge you have so much knowledge that the surface level um surface of your knowledge is so broad that you can fit any new tool on top of that right you don't have these skill gaps where you're like okay I have this new tool and I don't know where this fits because I have some gaps here um so that is a very long answer to your question of two month to six month road map yes you could squeeze it you know and move some parts away from here. But I want to kind of influence you and change your perspective to be like, you know, you know what? Let's not try to shortcut our way to learning DevOps properly if you're really serious about it. Let's take our time. Six month is not as like if you're comparing it to university degree. like um my studies my university studies for uh engineering were um I think it was uh three years and like three years to six month and in university you're not learning DevOps that's for sure because you're learning some uh outdated curriculum that they have. So I would argue it's six month is not as much time actually if you really think about it. And um by the way I forgot to mention so this is considering uh 15 to 20 hours per week dedicated to learning. Okay. So it's not like five years. Yeah that's another college but um so this is not full-time because obviously understand that most people have jobs who want to learn DevOps. So this is the calculation of this is um for 15 to 20 hours per

Segment 22 (105:00 - 110:00)

week of net learning. So actually dedicated to learning um okay so what do we have here? Um yes what I was saying is that let's say you have the curriculum you know what to learn. Um and this is probably the biggest problem that I see. U okay so let me try to explain to you how to learn the most effectively so that you can still save time because um you also don't want to be learning two years and be in like a going into cycles and circles of learning different technologies and after two years realizing okay you still cannot build those processes. So what is let's reverse engineer. There's a lot of text here but I'm trying to I'm going to try to summarize it for you. Let's reverse engineer what are you trying to learn. So what is it that is the most valuable for the company's most hirable but also uh not just hirable but once you start working as an engineer what will make the company go you are the best engineer that we've ever had because you are bringing so much value to our company. We never want you to leave. uh if you ever decide to leave, come to us and we'll give you everything that you want, right? So, how do what is that level of value that you can give the company as a DevOps engineer specifically or DevOps related role that you want to learn? So, what is that? What problem are you going to be solving with DevOps skills? Again, just a limited set of concepts, right? If you go to a company and you look at their C CI/CD processes or automated automation processes and you can tell them this process has so many bottlenecks. Uh it has these problems. It needs optimization. Uh let me design a clear strategy of how to change this step by step. So it's 10 times faster, much more efficient. the test coverage is f is larger and we have a continuous deployment instead of whatever manual processes we have here. How valuable do you think that skill set is for a company? And so that's one uh use case because CI/CD is the is kind of the backbone of DevOps, okay? Okay. Or DevOps processes in general. Or let's take another example of again like infra. So that's the release side and we have the infrastructure side, right? Let's divide it into Kubernetes and infrastructure. Let's say you go to a company and you see that they're um they have created this AWS infrastructure by clicking around or executing some AWS CLI commands and you go there and you're like guys, we need we have three environments or we need three deployment environments. Why don't we create a Terraform configuration um project that acts as a blueprint for all the environments that we have and then we can automatically create them, we can configure them, we can adjust them. Um, and we can basically do that with best practices and you offer that solution or plan to your team or to your company and you say by the way I know I also know how to implement this because I have all the skills. So you guys the software engineers whoever is in the team I'm going to teach you and guide you how to how we can move there. Right? Again, how valuable do you think that skill set will be for a company? Especially considering the statistics the statistics I've been talking to long already. statistics um that basically show how what the supply demand gap is between DevOps engineer DevOps engineering skills required and people actually having those skills and now let's reverse engineer from that. So we're not learning Docker, we're not learning Kubernetes, we're learning how to actually build that process uh end to end. So can I take um can I look at any AWS infrastructure and map that into a Terraform uh configuration? Do I have skill set enough to understand what the current um infrastructure looks like and basically just uh create a blueprint on Terraform? Do I have enough knowledge to make sure that we know how to collaborate on Terraform configuration? Do I have enough skill set to go into any project that has a CI/CD, look at their tools, understand the concepts and design a

Segment 23 (110:00 - 115:00)

system that optimizes their CI/CD pipeline and basically creates a continuous deployment. And what are the skills required for that? Right? So, what do I need to learn? And what you don't need to learn is those tools in isolation. If you learn Docker, how does that fit into any of those uh use cases that I mentioned? If you just know Docker, you don't know anything else. If you or you just know how to use Docker in isolation, Kubernetes Terraform in isolation, how do you like how do you combine those tools together to build those processes? Like if you can't map them to now I'm this is how an end toend pipeline should look like then that level of knowledge is not enough for you to be valuable enough and because you're not able to build those processes. So always think about am I able to uh create a specific build a specific use case? What are the tools involved and how to what level do I need to learn those tools in order to be able to build that process? Okay, I hope this makes sense to you guys. Please tell me in the chat if you have any yes questions regarding that because I'm I've really passionately explained this to you but I don't know how this resonates. Yes. So building use cases actual real use cases versus learning docker and kubernetes. Okay. Because it's like you're you are starting top down. So you're starting what is the use case? towards the high level use case that I'm trying to achieve. Now let me see what are the all the tools involved in building that use case and tool what level do I need to understand them to combine them together to have that use case right versus okay so I have all these tools that someone told me that I should learn because they you know just suggested that so I learned a little bit of this but I don't know why like why am I learning how to create a docker file why am I learning to how to write a uh deployment file for Kubernetes like what's the purpose right so you are completely detached from the use case that you're trying to build okay so I see this is an interesting question what are the I think wait a minute I think I can show the question on the yes Hello. Okay, it's a feature of our streaming software. So, what are the chances of the these tools get getting replaced in six months? Uh, so you have to start all over again. As I said, guys, think about okay, so let's think about use cases and reverse engineer to okay, these are the tools. Now, there's another layer between that and this is super important for me. If you've uh in some of the videos I've mentioned this concepts before tools, right? So uh concept of containerization. So every tool is implementing a concept, right? The tool did not just come out of like nowhere. Every tool was created to implement a specific concept underneath. So you have the containerization which existed long before Docker. Docker just implemented it in a such a user-friendly way that containerization concept uh became widely adopted right because of the user friendliness of docker uh container orchestration again existed before kubernetes uh kubernetes was just one of the implementations cicd is a concept and jenkins is just one of the implementations and let's say first of all uh I have two-part answer to that let me show that again actually on the screen. Okay. Yeah, there you go. Um, two-part answer. First of all, I showed you in the statistics. Um, fi I designed this curriculum five years ago. Five years after we go, we went through the job descriptions. The same tools are used and repeated and listed in most job descriptions, right? like 80% of the tools are same for every single job description that um is under DevOps engineer title. So these tools have not changed in the last five years. And the again the other statistic that showed you the most demanded skills currently which were the same exact uh tools. So that's one part which is there is no signal like there is no nothing that show is showing us that those skills are

Segment 24 (115:00 - 120:00)

going to be replaced because it is like logically why would uh industry want to replace the tools that already have become standard because now all the companies and all the teams would have to do the work the hard work of changing to migrating to new tools and as I said there's so many good alternatives to Jenkins but it still remains because the pain of moving to a new tool is much higher than using the existing one which may not be as good. Let's say in the extreme case they get replaced. Let's say something else comes up which is a replacement of Kubernetes and nobody uses Kubernetes anymore. The concept of container orchestration. Let's say you learned Kubernetes starting from the concept which is my absolutely important approach because you first start with the concepts to understand why you're using this learning this tool in the first place. If you understand the concept of CI/CD why it's important what is it doing if you understand the concept of container orchestration if there's a new tool that replaces it the concepts make up probably 70% of a knowledge of a tool. So you already have the knowledge and now you just need a new tool which is like 20 to 30% additional uh knowledge uh versus someone who doesn't understand the concepts who needs to learn everything from scratch. So again, githops was a new concept, but it didn't introduce anything new. You just CI/CD for application like software, CI/CD for infrastructure is code, right? Just like application code. Uh DevOps was a new concept, but it didn't it did not introduce anything new. It was like how do we plug out or remove the manual steps and automate things. So it just used automation everywhere. that was like just a new flavor of an existing uh set of concepts. So concepts do not change. Um, and if you understand the concepts, if you learn the concepts when you're learning the tools, and this is again my highest priority, like every tool that I teach, I want you to understand why was this tool created, like what is the underlying concept? And if you have that knowledge, then you would not care if tools change or not. Um, again, a long answer to your question, but I hope that helps. — [clears throat] — So awesome. So I I'm seeing that it makes sense. It made sense what I was talking about, which I'm happy about. Good. Yeah, we're going to talk about certifications uh later. But yes, so when you're learning stuff, please keep this in mind top down, okay? Do not start wi with a tool and do not start with the syntax because if you don't know why you're learning a tool then you should not be learning it. So first understand what is the reason behind it. What do we have here? Okay. Um and this DevOps road map again this is this could be a little bit misleading because it shows the technologies right. So it shows git build tools uh artifact repo containers. Let's talk about this one cd pipeline. Okay. So it seems like you're learning just Jenkins, you're learning just AWS, you're learning just Kubernetes. So this is actually road map that we use um that I used to build Devos boot camp and this is misleading a little bit. Uh maybe we should change this because uh it Jenkins is an orchestration tool that orchestrates multiple tools, right? Um, it's literally like imagine a pipeline and then you have like a line here all these other tools that integrate on that which automatically means that when you're building something production grade with Jenkins, you're automatically using all of these other tools in the ecosystem. So every um technology that we have uh that we're in the DevOps boot camp or that you are learning in general um you need to learn with the combination of all the other tools okay and the sequence is important here because let's look at this um let's look at uh container orchestration right let's say you get to kubernetes if you don't know containers if you don't understand the concept of containers and if you don't know docker you're going to be missing a huge piece of knowledge that is needed for you to like how do you know how do you learn container orchestration if you don't understand containers um if you learn if you're learning Kubernetes why are you learning Kubernetes because it's a the deployment environment so you need to deploy something to Kubernetes and it doesn't make sense to learn Kubernetes without

Segment 25 (120:00 - 125:00)

actually deploying something to it and if you want to deploy something to it with the best practices you should do it with CI/CD so here in this module Um I think we should really change this. So in this module in Kubernetes module for example um I wanted to I was like how do I use everything else that we learned from here Linux git uh build tools the cloud concepts containers registry basically every single tool in combination with Kubernetes. So how do we build a automated pipeline that uses that builds a docker image uh you know connects with git u which is configured with uh linux um and deploys to kubernetes cluster on AWS that's how you need to learn okay not kubernetes isolation not AWS Udemy course how do you take all the technologies and basically combine them with each other to build a streamlined flow of things if we move uh where is it terraform for example example. So it makes no sense to learn Terraform before AWS and I've seen this then this is crazy for me people who learn Terraform because it is a demanded tool before they understand cloud or AWS because you are automated you are automating AWS cloud infrastructure provisioning with Terraform. So if you don't know AWS and cloud services, what are you automating or like you need to understand what the services are what not only what you're automating but why you're automating it right so deployment part of it and then you can layer Terraform on top of that and once you have that again how do I now configure um provision and configure an EKS cluster as a deployment envir environment that CI/CD pipeline deploys to, right? That uses all of these tools here. Okay. So, every single tool should be like enzible, for example, it only says enzible, but in this module, for example, here we provision Terraform uh AWS um I think it's EKS cluster with Terraform and then we hand it over to Enzible. So the servers are there and Enzible then configures the servers uh once they are provisioned and it basically has the best practices of you know we need to wait until the servers are not only provisioned but initiated and then how do I integrate enzible into CI/CD pipeline and basically do all this more complex stuff basically. So I hope this again makes sense. Do not learn things tools in isolation. So this should actually be like here for example here it should be all these tools in one section next to inible that's how you should learn things all right how AI so I covered uh how AI is impacting DevOps you guys are going to get recording so please check that section it's I think I kept it short I'm not sure but um yeah we covered that completely. Good question. Very common question. So that was important for me to cover. Um let's see. Yeah, we're going to talk. So do I need software uh engineering before DevOps? We're going to cover that you need some type of IT knowledge, but um we're going to get to that actually. Um and again to this is actually this is an interesting story. So please tell me in the chat because this is also a very common use case. Um and I probably honestly with transparency I probably would have done the same in um if I was in the shoes of many other engineers. So uh Patrick so he was basically a network engineer and he told me that for one year one whole year he was learning uh doing different tutorials and learning basically these different DevOps um technologies and after one year he said he did have like a theoretical knowledge like he learned Terraform he understood like how you know cloud concepts and a little bit of kubernetes and docker and after one year he was not able to build a single proper DevOps process after one year of learning and please tell me if this also resonates with you because that is a crazy uh result for a one year of and he was he was like properly learning like you know using all the you know crash courses and doing Udemy courses and stuff like this. So, and I was genuinely interested. I was like, what was missing? Like why were you not able to build like a complete DevOps process after so much so many

Segment 26 (125:00 - 130:00)

tutorials and so much knowledge and the like the biggest disconnect is the problem is when you're doing a crash course, it's like one hour and then you're doing a Udemy course which is like two hours and you're learning different technologies. There's just no depth for you to understand how you take that knowledge and combine it with all the other technologies that you also learned in bits and pieces somewhere else. And that's the problem like if you cannot combine technologies together like if you don't have this high level understanding of I take it's like a building with Lego stones right I take this thing uh I take docker I take uh kubernetes I take jenkins and I combine or gitlabci whatever combine this in this way and it gives me this perfectly streamlined thing if you don't have that big picture understanding which a crash course will not give you and if you don't know then practically how to combine those skills then you are gonna like you're going to know feel yourself that you don't know how to build DevOps processes and that's the missing piece. So, you know, I don't I really don't care like if you do our trainings, if you learn by yourself. I'm a self-learner, okay? I learned most of the software engineering myself. But if you like you need to use a really uh correct approach because it's really easy to waste a whole year doing all these tutorials and thinking you're being productive, but at the end you don't have any skills. Like literally just from day one if you're just like if it's your day one learning DevOps engineering skills in general start building something take one of the use cases that I mentioned like the complete CI/CD forget about Kubernetes for now and start building that complete CI/CD okay do not just write like test and build and that's it like really think about like what is the production grade CI/CD what it looks like and how do I and implement it step by step. It may take weeks, it may takes take a few months, but once when you're done with that, you have automatically learned everything that you need for each tool at the level that gives you that depth of knowledge. And it could be four months, uh, five months when you, um, reach that level if you're learning alone, for example. But you're going to be way a more ahead than someone who has been doing tutorials for a year. Okay? So you're still gaining a lot of time. So if I can give you this one piece of advice about learning properly, this would be it. Just build stuff from the from day one. And this is also something that you can like that's what you can when you're applying for jobs. Uh as I mentioned, just ignore this two years and five year job experience. If you can send a company along with your uh CV a GitHub or GitLab portfolio of the projects that you have built in order to learn DevOps skills that you uh are applying for. They're going to consider you as a very strong candidate because that's that is demonstrating to them this is the skill set that I have. You don't have you only have to convince them in interview because they see okay you have built an end toend CI/CD project while learning you know how to build the um how to while learning these DevOps technologies. Um yeah, I mean I can stress this 100 thousand times and I repeat this will do it because I think it's super important under like two parts. Understanding why each tool exists. So I really don't understand when the you know either content creators or educators when you start a docker crash course and it starts with how to write a docker file or you know how to execute a docker run command like that's not where you like as I said if you don't know why you are learning a tool you should not be learning it you should first be understanding why that tool exists what problem it solves and how that fits into this use case that we're trying to achieve and only once you understand that big picture then you're like okay I know Docker is a tool that lets us package our application in uh like an artifact that has everything packaged into it the code and the dependencies and everything and then that gets basically because it's a movable artifact it gets stored somewhere in a central place from where I can download it to servers to different environments as many times as possible so it kind distributable. Okay, I understand the concept of why Docker exists. Now I can

Segment 27 (130:00 - 135:00)

be like, okay, how do I build a Docker image, that artifact to package everything? Now it makes sense why you're writing a Docker file, right? Now it makes sense what Docker registry is. Now it makes sense uh when you execute a Docker command to push an image, a built image to a Docker registry, how to pull an image from a do like all of these make sense because you understand why you're doing each step. Okay. So like again if this is the second thing that you can take from this live session is before you dive into any tool please first understand why the tool exists why it was created uh why it was adopted so widely and then start learning the syntax and you know how to do uh each of the concepts that it covers. Um yes and these are and I highlighted this because I know these are the biggest pain points that people have had. Uh I don't know why the these things are blurry like literally like look at this underlying stuff big picture the combination of tools um where is it already? Yeah, we we've had this a lot. We have this was a really surprising statistic for me when we started gathering data on our DevOps boot camps. I uh basically asked people what their engineering backgrounds were uh and why they enrolled and we s on the second place we saw DevOps engineers and I was like why are DevOps engineers enrolling in our DevOps boot camp and learning DevOps? Aren't they supposed to know DevOps? Like they they're working as DevOps engineers. what are they doing here? So we realized that there are a lot of DevOps engineers either okay mostly juniors so that's understandable but DevOps engineers who were kind of given the title or kind of you know forced or or you know just appeared into that role that did feel like they were missing skills they felt like an imposter syndrome uh why because they could not build the processes that the companies wanted them to build. So the skill gap is always resulting from uh you not having the big picture understanding of things. So they knew how to use Terraform. configure CI/CD pipeline but they didn't have a big picture understanding of things and that the things that click it's like looking at a like zooming in into a p like part of the puzzle but not seeing like what the entire image looks like. So that's how we kind of felt for them this uh entire knowledge. And honestly I did like my purpose was not like oh let me give people like big picture understanding of things. I just try to reverse engineer from what is it that you need to learn to have the skills that you need like a deep level of knowledge uh basically the level of knowledge that I had I just wanted to put in into the program and it was kind of a side effect um or byproduct of it that we needed to build those tools uh use those tools in combination which automatically resulted in uh having a big picture understanding of how everything combines because that's how I always learned everything to understand okay what is it doing why is it um why was it uh created and then how to learn it um yeah this was the survey actually that we did so we had software engineers so most of them we still have it um I think this was two years ago or so uh statistics or maybe it's the latest I'm not sure so Um yeah 24% and then the second biggest one was DevOps engineers uh CIS admins and then we have nonIT are by the way are there any nonIT uh background people here for the um who are transitioning into DevOps. Let's see. [snorts] Uh we don't have a plan for MLOps boot camp yet. The reason is because we are currently uh using all our resources to um you know update like continuously uh update all the programs. uh most like 80% of our focus is always on devops boot camp and then on devs boot camp because those are the most important pro uh platform um trainings or programs for us and uh we just don't want to distribute uh the focus too much on envelopes uh but it is definitely planned so as soon as um we have resources because like this may be like my perfectionist personality but if I do something that I want to do it like

Segment 28 (135:00 - 140:00)

with full focus with uh as much resources as possible. So as soon as I feel like we can dedicate uh a lot of time to like extensive research and everything then we're going to start working on MLOps as well. So let's say yeah we have a lot of nonIT people. Perfect. Let's see. Dental hygienist. Yep. We've seen a lot of different backgrounds by the way. Uh yeah data science without it. Yeah. So you see this other here this is where am I? This is nonIT 23% which is actually the biggest group here. So, which was a second surprise for me because I was like, what are nonIT people doing in our DevOps boot camp? Because DevOs is not an entrylevel um position. [snorts] But um yeah, I guess when you are motivated, when you're ambitious and when you're willing to learn and I'm happy that it was uh easy enough for them to kind of uh I mean I would still argue that you know it is going to be of course it's going to be a little bit more difficult for you if you don't have any IT skills uh than for people who have some kind of background but clearly it is it was possible for them as well. And we have like some of the biggest success stories of like PE our uh boot camp participants who are working at like MLOps engineers or like senior uh DevOps engineer roles they actually came from nonIT backgrounds which surprised me because uh the non- tech background people actually uh cr like completely crushed it compared to like I mean not compared to but like they were they're doing extremely um well like in terms of getting to the seniority level very fast which obviously shows how motivated and committed they were. Um yeah we I saw some questions about uh time as well. What's your advice for nonIT transitioning into DevOps? Um it's honestly it's the same as for everybody else with only exception that um so obviously if you have like zero it you just have way less context to start learning any devop like any engineering uh skills right so for example if a software engineer is learning DevOps they have they don't have any knowledge of this mostly of the operations side. So all of that is like new area for them. If a CIS admin is starting DevOps, they have completely missing skills in the software engineering part, right? So that's a new area for them. So they need to feel whatever skill set they're missing. As an IT nonIT uh background person, you just have to feel both um skill levels basically, right? from operations and software engineering side. Um and you know obviously the you you get that prerequisite knowledge also in the devil's boot camp. Um but by the way this was the reason why we create why I created back then the IT fundamentals course which I did not want to create because I wanted to focus on DevOps uh specifically but you know I just saw that there needed to be some type of fundamental understanding conceptual understanding of software development life cycle in general like how is software created like what is software like who are how do engineering teams work what is uh agile style of work. So a little bit of prisite knowledge so that you can actually tie the DevOps concepts or learn the DevOps stuff on top of that um little bit of context. Yeah. So like uh the road map for someone who is known it for us uh like from our perspective has always been uh do the IT fundamentals which is it's not software engineering I didn't want to teach like software engineering course it was what is it uh what are the fundamental concepts you need to understand so that learning so that devops make sense for you. Okay. So, it again comes back to uh if you don't know why you're learning something, you should not be learning it, right? So, if you don't know why DevOps is important, why it was created uh then you should start

Segment 29 (140:00 - 145:00)

by co by completing that gap and the way to complete that gap is understanding why was dev DevOps concept created because there was a certain way that application was developed. So software engineering teams worked in a certain way which was you know uh creating application code and then basically um shipping it along with some uh checklist to the operations engineers who were then uh kind of managing the deployment environment, the servers and stuff like this and making sure that new version of application would run on that uh deployment environment, right? And it was kind of like a back and forth without any um how should we like common language between them two because software engineers and uh operations engineers had such different set of responsibilities language um just set of tools that they were working with that there was literally no overlap between them. there was no interface. Um, and that's what you need to understand before you learn DevOps because then you will understand why DevOps um is important and why you should learn it in the first place. And that's what I tried to cover in the IT fundamentals course um which you know obviously is like way smaller and then that would give you enough foundational knowledge or exactly the foundational knowledge that you would then go ahead and learn DevOps basically. So that was the thought process for us to be like okay how do we there was a step missing basically. So if you imagine a staircase and you are making this huge step because there is something missing. So we edit the IT fundamentals course as a okay now there's a middle step so that you don't have to make such a big leap so to say um on the way to Davos boot camp yeah and it's like if you're a non if you have if you come from a nonIT background uh it sounds very trivial but it's important to understand how software development teams work. So it's not just the technologies like you need you like in the IT fundamentals course I actually teach how do you create Jira tickets and how to track them and I kind of role play with okay you have a product manager and you are a test engineer and you assign your uh and you are a software developer so you know write your feature and you assign it to a test engineer because if you've never worked in this type of environment it's going to be um and if you join a new team and suddenly they're working with agile and they're using Jira boards and you're like I've never seen I know like I'm a professional in like Kubernetes administration but I've never seen a Jira board and I've never seen like heard of agile. That would be like a very weird um discrepancy. So um I thought even if it's easy to learn, I thought it would still make sense to familiarize yourself uh about the way software engineers work. So you understand you kind of understand their perspective as well. [snorts] So all um show this software engineer students, people need this. IT um everyone who has no software like no IT skills fundamentally. Um they need this because again like you need some kind of layer or context to learn DevOps or to start learning DevOps because you need to understand why you're learning it in the first place, right? Okay. Yeah, we're going to talk about certifications as well. Um, okay. Every DevOps engineer has the same skill set. How to differentiate the resume with each other? And what's your opinion on certifications? Yeah, we're gonna we're going to talk about that. This is a good question. Uh I can't pin this. Um generally speaking, you remember this gap that I showed you between supply and demand. So there are DevOps engineers. We have the title but not the skill set. So if you are in the same camp, um then it's going to be really difficult for you to compete. uh like actually you're not even competing with anyone because if you generally don't have the skills that are hirable um it doesn't matter

Segment 30 (145:00 - 150:00)

because the the gap still the demand gap still exists but you are still not hireable because it's like you have so many nonIT people and there is a demand for DevOps engineers so there like it doesn't match the requirement right so uh if you have DevOps skills that you're not even competing against anyone because there is a huge like a massive gap. So you're already standing out. The problem is uh let me see where the question was. Yeah. So the problem is how do you um not differentiate yourself but how do you prove or demonstrate to the employer that you have those skills and uh it is not through certificates like I can tell you um certificate is the most common way that most people go especially ones who don't have the devop skills so they try to compensate it with so it's not it's definitely not the way to differentiate yourself or to feel or to demonstrate your actual skills. Um the thing that helps you demonstrate your actual skills is your portfolio. If you have a DevOps portfolio that shows your whoever uh you know you're sending a application to if it shows that you have built a complex CI/CD pipeline um in Jenkins GitHub actions whatever tool set if it shows that you have um configured a complex um AWS infrastructure with Terraform and I'm saying complex explicitly because if you send them a project that has like 50 lines of Terraform that is provisioning an EC2 uh instance or two EC2 instances on AWS cloud with a basic networking configuration. That's not proof that you can build DevOps processes. That's a that you probably have done a crash course on Terraform and you know can do like the basic simple stuff. And again I I try to I like to reverse engineer all the questions from like what is the end thing and then how do we think like top down if think about this if let's say what the next slide is maybe it fits it. So if you um if you have a skill set that many people can acquire in a very short time, how valuable do you think that skill set is? So for example, uh I don't know, let's take um I don't have anything against Udemy. Uh we actually had a Udemy course ourselves, but I'm just taking it as an example. If you take a um Udemy course that has 100,000 enrollments, which means 100,000 people basically uh did the course, maybe half of them completed. Uh if you have a project from a course that 50,000 people completed, you know, you are now in the pool of category of 50,000 people who did like a two or three hour course with like basic understanding of a tool. Now compare that to how many people do you think will genuinely sit down take um like a a complete CI/CD pipeline or do a like a training as extensive as our DevOps boot camp for example because yeah you it's a that commitment of six months that's a lot of time that you have to dedicate right um next to your job. So how many people compared to that do you think will sit down and take an actual use case and you know um try to learn by building this stuff every single day you know for multiple weeks tirelessly troubleshooting when things break uh instead of everything just working uh in the with the happy path and easily and building really complex scenarios and then uploading that as a git portfolio. The difference is huge, right? So you have maybe 100,000 people here and you have thousand people here. So that's how you really differentiate yourself because if you are in that pool of so many people who are doing basic stuff and have basic portfolios that's not going to help you demonstrate anything if also maybe another perspective that helps always think if you are an employer and you received your CV as an application or your job application whatever you send them right you may be send sending them your LinkedIn profile your uh portfolios would you hire yourself for that position, would you be

Segment 31 (150:00 - 155:00)

like, "This is an amazing candidate. Let's, you know, let's ignore everyone else who applied. Let's take him because he obviously seems like um he knows the stuff and he's exactly the right fit with his skills for our requirement. " So, if you're honest with yourself and you go through your own application and ask yourself, would I hire myself if someone applied with this application? And if the answer is no, then you can think okay why not you know what is missing um it's not demonstrating the skills enough then you can then go and fix those problems and if the answer to that question comes up to be oh he's he doesn't have enough certifications then sure go ahead and do those certifications but most certainly the answer will not be you know he's missing some certifications it's probably going to be uh he hasn't demonstrated skills uh enough for us to think that he can do the actual work that we want them to do regardless of what the job uh requirements say. Um yeah, I hope that makes sense. That is awesome to hear. And this is Basel. I have huge respect and admiration for people who not only go through um by the way uh can you write uh how um in how much time you completed DevOps boot camp or you finish the DevOps boot camp because uh it is quite extensive and then they go to DevSikov's boot camp which is also like obviously it's an advanced level um after DevOps boot camp. I have huge admiration for you because I know that it's like you need to be motivated, ambitious and you need to be like really dedicated to that. So amazing. Uh let's see. All right. Uh, home. Yeah, that's an interesting one. So, um, there was a question about home lab. Um, it kind of jumped around, so I don't see it anymore. Um, oh, home lab of kubernetes clusters. And there was also where do we find um where do we where do you find real world use cases to build your portfolio? Yeah, that's a tough question because um like if you search for it like on blog articles probably you want maybe you'll find like some uh real world scenarios of people sharing their experiences. Um, you know what? [clears throat] I'll show you a free resource. Uh, you can get this on the on our web page, by the way. So, um, let's see how practical this is. Okay. So, this is the so we have the devos boot camp curriculum. This is not the one. This is demo projects. And let's say you want to build um uh you want to find a realistic uh demo project and you want to build it basically independently you need you want to figure out how to do it. So let's go here. Um so this is the demo projects that we build in the DevOps boot camp. So let's say you jump in. Um so the first ones are so here you see the logos of the tools. So this project basically uses those tools. So let's go to a little bit more complex one. So let's go to the one that uses uh Jenkins, Docker, Linux, Git, um Java, but not like you're not programming anything. There's a Java application already given and you're just using build tools for Java. Um yeah. So let's do this page. So you go here. Should I zoom in? Yeah. Um so it says create a CI pipeline. So this is CI pipeline. We're not deploying anywhere yet because we are building this step by step. Um, and this alone without CD will give you really uh deep knowledge. So here's a description. Um, you are creating a CI pipeline for uh this could be any application by the way. the programming language really does not matter because you should be able to work with any programming language because sometimes we use Java, sometimes I use JavaScript like Noode. js like we mix it up because you should be able to work with like whatever. Um so you are building a CI pipeline on Jenkins that deploys an application in whatever programming language uh builds

Segment 32 (155:00 - 160:00)

as a docker image you see here. So you are installing the tools in Jenkins. You are installing Docker on Jenkins so that you can execute Docker commands on a Jenkins server. Um you then create credentials to connect your pipeline to git where the application is hosted and then create different Jenkins job types. Let's say you create a pi pipeline like a simple or multi branch pipeline um for the project with a Jenkins file right not clicking in the UI you're scripting everything remember DevOps is about X as code so everything is code so you connect uh Jenkins pipeline to g repository where the application code is hosted you package it into you can skip this part let's say you have a JavaScript application you create a docker image and you push the Docker image to private Docker repository. Like if you literally just do this part, you will know more than people who do UNMI courses. I swear like if you take this um if you download this PDF and if you sit there maybe uh it will maybe take you like one to two weeks to figure this out yourself. And if you build a pipeline that takes any project, you can find projects on GitHub or GitLab on or our um profile um package it into Docker file and push the Docker file into a private repository. Just do that. That's one project. And let's move on to a little bit com more complex ones. This one for example. So now we're doing CI/CD. you are doing the same uh where's the CI/CD part there you go so all these technologies combined now because remember I said no tools in isolation you need to combine everything together because we're you're building a complete uh process you're not learning docker you're building a CIC pro process so you build a docker image you push it to repository uh you increment the ver version automatically or you can even skip that part and you deploy that applica that Docker image that you just built on an EC2 server right on AWS creating a virtual machine on AWS is very easy and you deploy that new Docker image or you pull that from a uh Docker repository to the EC2 instance that's it and then you can extend it to the next stages Uh let's see what we have here. Kubernetes. So instead of deploying to EC2 instance, deploy to Kubernetes cluster on EKS. Um and then you know inside Kubernetes again like we I switch between applications. So it's not Java all the time. Sometimes it's like a Node. js JS for example that has a mo MongoDB uh um database back end because you should be able to like you don't need to understand JavaScript code in JavaScript or Java but you need to understand how to deploy any application written in any language uh to the deployment environment as a DevOps engineer. So literally just take these demo projects and choose the ones that have like this um combination of tools and just try to execute them like these are real project like if you want to understand how real uh and production grade these projects are um we had engineers in our boot camp who literally took the Jenkins files that we built and copy pasted that for their projects. Like they literally took the the Jenkins file from one of the projects and basically took the file and migrated it to their own project and made some slight modifications and that was it and that was live in their production. And they did the same with like Helm charts um for microservices uh Terra like they literally took like the Terraform modules that we created uh with the backend configuration the state file and just copy paste it without any changes for their um for their companies. So you can use that as a reference for production grade products uh projects and yeah and then you can use the help of AIS resources in like if you either don't have time or you can figure it out by yourself because it's too difficult. You always have our programs to help you. But as I said like I really don't care even if you I'm a self learner as well. If you're disciplined enough, if you're motivated enough, you can learn this by

Segment 33 (160:00 - 165:00)

yourself. May take a little bit more time, but you can do it if you do it proper, if you approach this correctly, which is building projects instead of just doing some courses, which still feel like you're being productive, but you're not learning anything if you're not actively building stuff. Um, so yeah, that would be again a long answer to your question, but that would be my uh advice. Uh when the new CK course will be starting. Oh, that's a so we took down the CK course from um our website because uh we are going to update it completely. So we're basically going to repeat the CK exam because they changed it um and make sure that the curriculum aligns it. But it's probably going to take a little bit longer because it's not like the biggest priority for us. As I said, we are completely focusing on DevOps. Um, and we just want to use all our resources smartly and you know just have it directed on DevOps because we are so we are continuously updating uh all the programs and the more programs we have obviously the more difficult it is to keep up the updates. So now we have a really good pace and streamlined process of you know making sure that whenever a new version comes out uh for any tool or something needs to change we're immediately doing that and we'll see maybe we'll have some resources free to do the CK update soon. Yeah. So the PDF link um so if you go here where is it so nope there's not one so I think both uh buttons actually give you the both so either this one click here or the demos demo projects or you can even see them here but if you need the PDF just click here and send me PDF. Uh in this email, you're actually going to get the curriculum as well. So, you're going to get both. Uh let me see if the curriculum is going to be helpful for the demo projects as well. Do I have it? Okay. So, this is the road map that I showed you curriculum. Okay. Yeah. Uh I mean curriculum just lists like what you're learning but uh like lectures but you know use the demo projects because if you really want to see like what you what is it that you need to build then you know the demo project is the one that's going to help you not the curriculum. Yeah. Yes. We took uh CK down because we didn't want to offer anything that was uh remotely outdated because uh we don't want anyone to enroll in anything that is not like uh the latest level latest version of the tools that uh are out there. And that's why we want to so we have this strategy basically whenever there's a new version of a tool that is um you know different enough um from the version that I'm teach we're teaching in the courses we take down the course because we want to update it first and then once it's updated completely re-record it basically so update means we re-record the entire thing all the demos uh then we release it because we don't want anyone to enroll role in anything that is not completely up to date. We have a reputation to uphold. okay. So, okay, this is an interesting question. By the way, I switched to questions because I'm taking way too much time with the slides. So I want to cover your questions as well. Um there you go. So this is an interesting question. Uh are we going to have access to playgrounds like uh digital like cloud play playgrounds basically to do the demo projects? Um yeah I've heard this question a lot of times. Again you guys know I'm a big fan of reverse engineering. So let's reverse engineer this. When you um let's say you get an interview, you get hired as a DevOps engineer. when you join an DevOps uh engineering project, what is the real

Segment 34 (165:00 - 170:00)

um environment that you're going to be working with? with real AWS cloud infrastructure, Azure infrastructure, on premise, whatever. There is no scenario where you are going to join a team which is using a sandbox or um why what was it uh playground environments. Yes. So my approach my perspective is this if you're learning something why not learn it exactly the way that you're going to need it in practice once you uh once you're done learning. Right? So when you apply those skills that you're learning in practice, why not make your learning as similar or as close to the actual practical environment as possible? So um I I'll tell you an example when I was uh you know back then when I started in IT and I was learning uh software engineering uh that was my first u skill set. Uh do you guys know the platform called uh what was it? Code Academy. So Code Academy was basically uh a platform that let you learn programming super fast because they had these sandboxes like lab environments and you just went there and you wrote like variable and you know set the value or whatever. And I did like multiple uh courses on code academy uh in order to prepare for my Java and JavaScript courses um in the university and I was completing the course and it was like super fast and you know I was you know flying through lecture after another and then I had to do the actual uh the practical exercise for my uh university project. I was like but I don't know how to you know where should I create the index file where should I put the JavaScript how do I link it together so I was not able to apply that knowledge to the actual examples and I was like but you know I learned all this stuff and the problem was because uh you I wasn't working with the actual file system where I had to create those uh programming files everything was in their environment and now think about this same thing but aggravated like hundred 100 times because of DevOps because DevOps skill set is literally like you need to learn how to build an AWS infrastructure. So if you come to me and I give you a ready AWS infrastructure which I provision for you and you're just interacting with it as a sandbox environment, how much are you learning? Like you're literally just skipping the most important part which is how do I like if you um let let's put it in another way. If you come to me and I want to give you an equivalent knowledge of an actual practical experience. So I want to um tell you okay I lost your name but let's say I want to tell you okay um let's make you build something that simulates an actual work experience. And I tell you in the actual realistic world you're going to be u you know building an ad AWS infrastructure with um you know multiple EC2 instances and you're going to be connecting them with each other. Maybe they're going to be in different regions whatever uh data storage configured to it and [clears throat] basically take you through the steps of how you would do it in actual real world project. Instead, if I tell you, you know, let's make your learning super easy and let's make it super enjoyable and super fun and let's give you confetti every time you uh you know um get a answer correctly. It may be a really nice and smooth experience for you, but what have you learned? Like if you when you go and join a team uh you can't demonstrate or you don't have experience that closely mimics the actual real world scenario. So it may be more difficult and it may be a little bit more uh effort from your side but that's exactly what you need to learn so that you can demonstrate your skills when you're working. And if your concern is the cost like the cloud cost um it's actually like the how do I say the proportion of how much you're learning by actually using the real cloud environment versus how much it costs is just marginal like digital ocean for example and this type of so digital ocean compared to AWS is more like an abstraction layer cloud so it's like very easy to start with. It gives you like if you sign up for a new account, it gives you like $100 credit which

Segment 35 (170:00 - 175:00)

should be enough for you to have all the costs. AWS it costs something but it's you guys know that AWS uh is cost per use. So for example um what we suggest our students is when you are done with learning just delete all the resources so you're not charged for that. And if you're learning for 10 hours and your EC2 uh you know instance is running for 10 hours that's not going to be so much cost right uh so much um money that you get charged uh or let's say um for example uh another thing that you could do is you can uh AWS has services for monitoring your cost right which a lot of businesses need. So I sometimes when I do like demo preparations for the courses I put like a limit um it's called budget alarms or alerts. So I say whenever I cross $100 please notify me because it means I either forgot to delete any resources or maybe I was lazy to delete them whatever. So just notified me notify me so I know that I don't get charged um unnecessarily. But like it's really not that much. Like the cost of using cloud to actually learn it is way less than the actual value that you get out of working with real cloud environment. So um I know it's it sounds fun to learn with um you know sandbox. You're saving um money and time and it's fun but it doesn't give you any value. like it really does like you would be even wasting your time because you feel like you're learning something you're being productive but uh from experience I can tell you that this is not the depth of knowledge that you want to have. Yes. So let's see the DevOps career first. All right. Okay, let's address this one. Um, DevOps career path feels really unclear these days. What does a real growth path in DevOps actually look like? So, in terms of uh career growth, like if that's what you mean? Um, this slide that I showed about uh where was it? Yeah, this one right here. Right. So, I understand your concern. This is how Let's show it again. Yeah, this is the DevOps career path, right? So, um you know, let's say let's make it simpler and let's say you were starting as a DevOps engineer and I highly suggest you don't learn just enough to become a junior DevOps engineer but you learn DevOps properly and then you apply for jobs and you could become a junior or mid-level DevOps engineer with proper skills. So, what is the path from there? Let's say you join a company and you start you know doing um implementing your DevOps skills and optimizing uh your stuff. Um so there is always a level of seniority. So you can become a mid-level, you can become senior, you can become like an architect. Um there is um a level of like upgrading to a new skill. For example, platform engineers are usually considered a more senior role of DevOps. So you can become a platform engineer. By the way to give you a very simplified um comparison of DevOps engineer, platform engineer is think about let's say you have a company that has 10 application teams and each application team has a DevOps engineer, right? So each DevOps engineer is dedicated for making sure that specific application team's application gets released fast to the end environment. platform engineer is basically a DevOps engineer who is responsible for all the 10 teams. Okay. So you extract those DevOps engineers out of there and you say okay you guys are all using Kubernetes CI/CD pipelines. So let me create one unified platform and let me kind of manage the Kubernetes cluster and CSD pipelines for you. So we're going to do this companywide instead of each application team doing it for themselves. So because now you are not so you're an engineer that is not just working for one team you are working companywide. So your value is 10 times higher because your work affects and impacts 10 teams instead of one. So in terms of responsibility instead of depth for example platform engineer is higher level and they're usually paid more a very clear one is deficops engineer and this is my favorite one okay I may be biased but this is so why it is my favorite one because I always think if I learn the skills which are highly

Segment 36 (175:00 - 180:00)

demanded or highest demanded and the least supplied that is a huge opportunity for me to have a leverage like the companies will basically be begging for you to come on board. Uh the salary will be way more different or the edit benefits will be different because you're just irreplaceable. And if you compare the number of DevOps engineers or the gap that I showed you compared to the gap for dev secops engineers, basically companies looking for this um role versus supply, that gap is completely crazy because there maybe a thousand devsops engineers in the entire world that are really devops engineers because DevOps engineering is already complex enough. That's why I said uh you know the message of our DevOps engineer DevOps boot camp student who just finished DevOps boot camp and now is doing DevOps engineers which is actually common path that we see um you know huge respect and keep up the motivation because uh DevOps is already broad enough and now you're basically layering security on top of that but it's not cyber security in the traditional sense but it's so every think about every part of the DevOps process right every piece of the system so you have the application you have the CI/CD pipeline you have the cloud you have the Kubernetes you have um you know Terraform you have all these tools and now think about security in every single tool every single piece of the system so you have you know security in Kubernetes cluster security on cloud security in application code, right? Are you uh allowing SQL injection? Are you, you know, leaking any uh API keys? Um security in the CI/CD pipeline. You're you may be completely exposing all the credentials to various applications, right? You may be exposing credentials to your uh servers, deployment environments. So managing all the secrets, managing security in every single layer that is like a huge um aspect basically that comes on top of DevOps. Okay, I get some notes from Nicole in between. So, uh I would say like depending on what your goals are, like if you're motivated, if you do want to see the path, kind of um grow in your career, I would say platform engineering is amazing. It's complex. You're going to grow and learn even more. And then Devacobs would be my favorite choice because it just yeah, that's like just very highly demanded. All right, where are we? uh career development. Let's see some of the questions. uh Black Friday in the next uh week or two. So we did Black Friday last year and it was uh very successful because we saw a lot of people who were basically you know on the edge and they were just um edge of thinking this is maybe a little bit uh over my budget and then you know because of Black Friday they were able to afford it and I'm very happy about it because you know um I want it to be um accessible for everyone. Um I can't tell you exactly. So we may be um sending out or we may be doing a Black Friday campaign uh this year as well for only Davos boot camp. So we again our full focus is on there. Um if we do we're going to send it out per email. So you're not going to miss it. You're going to be notified. Um uh but I'm not like we're not 100% sure about it, but we're going to definitely um make sure to plan it, okay? At least um if we do it, then we're going to notify um you guys per email. So you're not going to miss it for sure. So, let me see some uh live coding tonight. No, we're not gonna be live coding. Um because you know why? Because well

Segment 37 (180:00 - 185:00)

first of all, we have I mean, we've already done when did we start? We started at 6 PM. Okay. So uh it's been going for a while but generally because I think the biggest value that I can give you is to that topdown understanding okay because before I live code anything and I give you some demo which will you know usually takes a lot of time I want you to understand the concepts I want you understand the wise I want you to you know change your perspective about different things that you may uh see in a wrong way I think that's the biggest value that I can give you um because I'm thinking what is it that you either don't get anywhere else or do not get in this form in this specific form and that's what I wanted to concentrate on. So no live coding thank you. That is always like even though we get these type of messages very often, I still really appreciate all of you guys and I it still makes me happy even I think the Kubernetes and Docker tutorials we uploaded them like four to five years ago. Still after five years it still makes me happy whenever I see someone I meet someone or I hear someone who learned Docker and Kubernetes specifically from us. super happy about that. Uh interviews. Yes, let's uh [sighs and gasps] you know what? Let's jump to the interviews and I'm gonna jump back if um where do we have it? We had Okay, we had certifications and then uh interviews. You know what? Let's Let me see what we have. Um yeah, let's talk about certifications because I saw many questions about it and then I'm going to address the uh the interviews. Okay. Um so people asking like do I need uh certificates? Should I do them? Uh you know are they proof of my knowledge and so on. So first of all I wanted to share this stati stat statistic about um what is so basically this shows you what is that companies value the most uh whenever evaluating an engineering candidate um degree and that's why I think they the companies already stopped including college degree or uh computer science degree in their job descriptions which is very smart and I think if you see it you can ignore it the same way as you can ignore the years of experience. Um yeah, I think many companies will not like my speech today, but it is a reality like you can really ignore it and it is in their best interest because if they are um repelling a really good talent because they have a you know years of experience uh you know versus that person having a really good self-learned knowledge then I think they're missing out on a really good uh talent base. Um okay so then we have these two so certifications yes so certification is number three and the top uh one or two are real hands-on experience and portfolio and these are actually close to each other because as I said uh let's say you working at a uh in a project you working as a devops engineer right you have been working for two years and all you did in your work was uh work with legacy projects. So you have not learned Kubernetes, you have not worked with Terraform because your company's you know using some outdated tools um and some internal weird tools that nobody has heard of. um or you basically just do not get exposure to um uh or let's say you are the only DevOps engineer and you just got the title because you know knew a little bit of cloud uh and there is no one else who knows DevOps engineering skills properly. So no one that you can learn from and you're just doing like winging it basically just configuring whatever and sometimes things work sometimes they break who knows and that's you know you still have experience right on your CV it shows two years of DevOps experience um and let's say compared to that you have you know done one of taken one of those uh real world projects that I mentioned with you know all these tools like Kubernetes and Docker and uh Jenkins and you've built end-to-end uh projects uh pipelines or processes. Again, logically, which person's skill set is more valuable and demonstrates

Segment 38 (185:00 - 190:00)

more the skills that they can actually uh create and build proper DevOps processes, right? One has actual experience of two years, but they haven't learned anything. Another one has learned properly because they built real world scenarios. You know, the ones that I showed you from the boot camp demo projects. The the second one has no experience but has more knowledge. So it always comes down to again reverse engineer. what is it that we want to demonstrate? We want to demonstrate not experience, not some certificates, not some titles. We want to demonstrate am if I join your company as an engineer, am I going to be able to optimize your CI/CD pipeline to manage your Kubernetes cluster to teach your software developers how to deploy to um the Kubernetes cluster. Let's say you are sitting at an interview and they ask you, you know, we have this problem right now which is um we have this Kubernetes cluster and people who manage it and then we have the software development teams and they're messing up the cluster every time they deploy stuff, right? And this is our biggest bottleneck, biggest issue. The commerce administrators are frustrated because you know we need to let the software engineers deploy something to the cluster. But they are misconfiguring stuff and just deploying whatever. And you're sitting there and you can say um have you thought about using policy as code to automate to basically introduce automated uh checks or validation of whatever software engineers are trying to deploy to your cluster. that will demonstrate to your employer that you are able to join their team and you're bringing knowledge that they don't have currently and you're able to implement that and that will be a huge value ad to the team. If you're sitting there and saying, "I don't know, maybe we should um discipline the software engineers or maybe whatever. " Right. If you don't know the concepts and tools, you're not going to be able to give a proper answer. And you may still get hired if you are just good enough, but it's not going to help you stand out from other engineers who do not have this type of uh understanding. Or let's say if if they say you know we're using Terraform to automate our infrastructure um and you know we have some problems which is um I don't know our environments don't look uh same and then we have the or we have a configuration drift for example which means um we create the infrastructure with terraform once and then people just add some configurations and suddenly Terraform does not reflect the actual um infrastructure. How do you how can we solve this problem? How would you suggest to solve this problem? Uh and you can say you know what you can we can introduce a workflow where nobody is not allowed but like technically not able to SSH into any EC2 instances or to uh login into AWS account with a write permission or change permission only read only access. So nobody's allowed to make any changes. So automatically everything should go through pipeline. So we build a CI/CD pipeline for the infrastructure code whatever. So you explain the concept design and they sit there they will sit there thinking this is the person that we want to hire because obviously they can solve our problems. Okay. They're not going to be asking you uh syntax of uh Kubernetes manifest files. They're not going to be asking you how you write docker files or syntax of terraform which is what you mostly start learning with right they're going to be asking you we have this problem how would you help us solve it right so that's what you should prepare for and what helps you prepare that for that is when you actually build those so two parts build those things as I said because you learn stuff while you're building things so you are seeing that's where experience comes from right senior engineer ers are valuable because they built stuff that broke. They had to fix it. They had to troubleshoot it. They go went through the pain and the pain turned into experience. And the second is understanding the big picture, the wise and so on. And again that's exactly why I teach the way I teach because I think you should understand from concepts why you're learning a tool why what was the purpose understand conceptually then understand okay how does that tool implement those concepts and then not only learn the tool like docker but how do I use it with this tool how to combine with tens of other tools to build an entire use case. So, um that was the answer to whether certificates are important or

Segment 39 (190:00 - 195:00)

not. They are look if you have time, if you have resources, sure like it's a it's like a cherry on top of a cake. Okay? So, cake is your hands-on knowledge whether it's from job experience or for building actual stuff. And certification is a cherry. Okay? If you don't have a cherry, you still have the whole cake. But if you only come with a cherry and there is no substance underneath like in latest in the interview there when they ask you okay we have these problems how you do how do you suggest uh us to solve it like most certifications will not prepare you for those questions. So uh it's just what is the purpose of certificate to just get the interview like that's not going to um yeah like if you don't have knowledge underneath that's not going to help and if you're asking yourself right now okay but what if there are other engineers who also have good knowledge but they have certificates and I don't have it going back to this statistic where was it the supply demand uh gap Let's see if I can find it fast. Yeah, this one. Yeah, you see this gap? If they have two engineers who both can answer the questions that I just mentioned, trust me, they're going to hire both engineers because there's no company who be like, you know what, we don't need another great, knowledgeable DevOps engineer in our team. that will probably make place for the second engineer if they're equally good. Okay, so the like as I said, you're not even competing against anyone because if you're a good DevOps engineer like there is so much gap like so much supply demand gap that you're literally just on like just category of its own because there's no competition there. It's literally just empty space. um because companies need to hire way more engineer DevOps engineers than they are available. So yeah, certification is nice to have. You can add it on top of it, but do not use it as a com like compensation um for lack of DevOps skills because they're going to show anyways in an interview. And if you're a junior engineer, if you're uh you know hunting for your first job, focus all your attention here, right here. Okay? Because certifications, it's it may sound good and nice and this is what most people go for, but they cost money, they cost time, like you need to prepare for those certifications, even if it's multiple choice tests, like you need to learn for them, right? So, I would rather spend that time and money right here to be honest because that's the cake, right? So, do not buy the cherry before you get the cake. Yeah, I think that's that analogy works good. Yeah, of course. You get help. So we have so currently we have four senior DevOps engineers in our team whose sole work job is to help um our graduates. As I said we are very careful about what other uh you know programs we create and what other stuff we um add because we want to focus and concentrate all our resources on DevOps devsops like these core things. So our like our DevOps engineers are basically uh answering any questions that you may have. So for example either you were doing a project and uh you know obviously you were following it step by step but sometimes you know uh you have a different version of whatever tool sometimes configuration you know it's technology you know things don't are not 100% identical you can ask it they help you troubleshoot they tell you okay you missed uh this um configuration option you missed this parameter you have a typo whatever like whatever your issue maybe and they just help you uh you know unblock yourself so to say and continue with learning which is like you can literally think of it like you have your own small like consulting or coaching group basically that just waits for your questions until you have any and just you know helps you uh move on with projects. So of course like we like the part of the experience should be that you don't have to do it alone and you're kind of um you know helped throughout. Uh right should we make this slides available to everyone? Yes, I think so.

Segment 40 (195:00 - 200:00)

Yeah, we we're going to send the slides along. Yeah. So we so we're gonna be sending the recording. So, this is recorded session and then um uh I'm not sure if it's already there, but I'm going to ask uh Nicole to send the slides along. Yeah, how would you build a DevOps portfolio? Let's see. This is also Yeah, because we talked so much about uh I DevOps portfolio, which is the most important one. Let me see. Do I have Yeah. Um, okay. So, I have a few I don't have a slide for that, but I have a few um tips or suggestions about building a DevOps portfolio. First of all, most important one, instead of — [snorts] — um you know, you just choose GitLab and GitHub and basically just host your projects there, right? And when you think about okay which projects do I host and what you know how many of them and how do I structure them instead of creating 10 projects that show like basic uh DevOps processes like you know you just configured as I said like Terraform use Terraform to provision two EC2 instances on AWS and then maybe some basic network configuration um or wrote some basic you know deployment files for Kubernetes manifests. Instead of doing that, it's way better to have one or two projects that are way more in-depth. So 10 shallow projects versus one or two proper end to-end projects because again what is the goal of those projects to demonstrate that you have deep devops skills regardless of which uh title you role you are applying for. So we want to prove that I'm able as a de engineer who is applying for this job. Uh I'm able to build you your team your company a complete CI/CD um process. If I send you a project portfolio that shows an N2NC city pipeline in GitHub actions for example or um Jenkins whatever if I send you that project it directly demonstrates that I'm able to do that. If I send you a Jenkins file that has placeholders uh basically just has like this I don't know steps uh for test and build and it just echoes some stuff. what does it demonstrate? It doesn't translate to like it doesn't show that you have those skills. So always try to build like complex projects and show that as a portfolio instead of doing a crash course here and Udemy course here and then having some shallow level uh demo project. So that's one. The second one is uh let's say you have this complex project which is a CI/CD pipeline and you can't com like you can't have everything in code because you know your you can't put the infrastructure in code right the infrastructure is not there you can't send the infrastructure along so what you do is let's say someone is looking at the your uh project portfolio to analyze okay what has this person built and you know what knowledge they have first question they may have is Um, okay. Does he actually understand what this project is doing? Did they copy it from somewhere else? Like it could be like a fork of another project or um they may have questioned looking at the portfolio. Okay, but I don't really understand what this thing does. I need to go into every single file and code and stuff. So, in order to address both of these questions and solve this issue is this is what you do. You put a readme file in this complex project and you document first of all what this project does in your own words like almost like a blog article that explains the person who is viewing this project what this project does, why it does it, what you have built, what understanding you have of what you built like the steps your maybe your learning notes while you were building this thing and things broke and went wrong and what you learned from the troubleshooting. So basically your thought process put into and your learning experience put into this uh document this readme because they might not click into every single file um in that project but they will definitely read your readme and from that they will understand exactly okay this person understand the concepts they

Segment 41 (200:00 - 205:00)

did this troubleshooting they learned this and these concepts underneath this is exactly what we actually need in our company. So that will provide that will make sure that you demonstrate your skills way better than someone who just sends like a shallow project which does nothing or it does something but it's not like production grade. So yeah, I actually forgot what question I was uh oh there was a portfolio stuff. Yeah. So that's those are the two things to focus on when you're building a portfolio which is less but in depth and readme with very clear explanation of what your project does and you send a link along with your um application and third one is when you're applying um for a job make sure to highlight your project everywhere so that they don't miss it. Usually they won't because I know that from our boot camp graduates that every employer that the every company that hired them actually checked their uh projects like nobody skipped skips their demo projects because first of all mo most people don't send them so it's rare and they're immediately uh sparks their interest and second of all they can like they can scan CVS but CV doesn't tell me anything if you've listed all the tool all the DevOps tools in there. I don't know. You say, you know, Kubernetes, Docker, Jenkins, but I don't know to what level and I can understand that from your project. So, it's definitely the first place they look at when you when they evaluate your knowledge. Um, so make sure to link it in your CV, in your LinkedIn, you know, put it in the email. Um, yeah, because that's literally like the door opener to the interviews. And what usually happens and again I know this from uh talking to our graduates is uh in the interviews they usually bring up the projects. So they have looked at the project and they ask questions about the projects. So it becomes a topic of conversation automatically because now they have something that they can talk. So okay so I saw that in your project you built this and this. So now tell me uh you know what why did you do this part for example or how did you do the uh handover from terraform to enzel or how did you um I don't know create an EKS cluster with this specific configuration and what they are testing in interview is that uh your project looks impressive but do you understand like did you write this independently yourself do you understand all the parts of it so they are testing basically your understanding ing of your own project and um yeah and like the project portfolio that I showed you where was it? Yeah. So we by the way we have this for dev sec ops as well. uh we created this for defic because a lot of people wanted to see that again with the tools and stuff but let's say when you have um so when you do those projects uh like in the boot camp when you go through those projects and you build this stuff um and you organize the projects in like for example when you're when we're building out a specific project like step by step from CI to you know adding the C CD um you end up with approximately I would say like six to seven capstone projects like deep level projects that you can group like in GitLab for example you have a concept of groups so you can put them all inside as like individual projects and then you can send them a link to your GitLab group so they can go through all your projects and the good thing is that let's say you have um uh I think this is a complete CI ICD project. Yeah. So this is a this is one of the capstone projects, right? So let's say you have um this uh in the list and you and in in the interview they ask you for example to explain different parts and because you build that project and because you understood the concepts and because we went into the wise and everything you're going to be able to explain them conceptually this is why I configured EKS in this specific way. This is why I use this Docker registry. This is why you know we secured this part of the pipeline. This is why we uh do the automatic version update for example before release. So you're going to be automatically able to um explain to them concepts because you understand your own project inside out because you build it, you troubleshoot it and so on. And that is like the biggest um yeah what's the opposite of like that is the biggest

Segment 42 (205:00 - 210:00)

thing that impresses the employers and literally triggers them. This person knows what they're talking about. I'm convinced about their skills. So to iterate focus on these two okay focus on this one actually because that's where the selfarning part comes in. And you know you remember I mentioned that we have a lot of uh DevOps engineers. We had we have had a lot of DevOps engineers in the uh DevOps boot camp. It's because of what I mentioned before. They they're working as DevOps engineers either with legacy tools or they don't have anyone else in the team who can teach them the actual best practices that they never learned. So they need to somehow fill that gap even though they have hands-on experience because they have the same problem. How can you demonstrate the actual DevOps skills? Have you built a complete CI/CD pipeline that is production grade with best practices? If you haven't done this at work, then it doesn't matter that you have experience, you still don't have the skills. Um so very yeah very important basically to a way to demonstrate and the easiest way to demonstrate your um your knowledge and there was also a question about you know if people have different same or similar portfolios how do you stand out trust me like 80% probably even more of people do not have git projects or project portfolio of devops projects that is complex enough or deep enough for employers to even start comparing them with others. So I think this fear is completely irrelevant because as you can imagine most people do not even take like even if they do the uh build the project they don't even take time to put it in a proper organized way in the git and send it along the job interview. So like if you just do this you're going to be in um rare or yeah few engineers category because somehow I don't know most people don't do this type of stuff. All right. Uh so yeah how do you show I think this was the question about how do you show yeah let's say okay let's say you have a CI/CD pipeline uh project right and it shows that you're deploying to an EKS cluster with some Kubernetes configuration files right of course you're not going to bring your infrastructure and uh bring your uh like Jenkins setup uh but the thing is it is enough to spark a conversation uh on the interview so Let's say you go to the interview and they say, "Okay, I see Kubernetes manifest files that are being um you know used in Jenkins pipeline, right? They are fetched and there's a code that executes that connects to the um AWS um infrastructure EKS cluster basically and deploys those Kubernetes manifest files. So they can of course they don't see the infrastructure setup but they can ask you questions to uh validate that you understand how the implementation actually looked like in uh with real infrastructure. So that's going to be super easy for them to validate if they actually see the code and the code shows you're building a CI/CD pipeline that takes the manifest files. The manifest files are code so it's going to be in the repository. So it's not as difficult to showcase this and to demonstrate your knowledge um even without bringing your laptop with you to show the infrastructure. All right, let's see. Yeah, impact of AI in DevOps. Uh we covered that already. So you're going to get the recording and you can watch it again. Okay, career related. Um so just like I said that five years ago the tools were same that are demanded now it's probably going to be it's most the same in the next five years and the thing the reason is because first of all they have been stable in the past years and second of all there is no indication for any of these DevOps tools that have matured over time which is terraform uh kubernetes docker there is no indication for these tools uh decreasing in demand or being replaced. Uh Kubernetes like what happened with Kubernetes with AI was it literally like most of the machine learning projects AI projects are hosted on Kubernetes. So now all of

Segment 43 (210:00 - 215:00)

a sudden you have this completely new use case for Kubernetes which like skyrocketed the demand for Kubernetes. So there is no indication for those tools um be like being replaced anytime soon or the demand for those skills uh going down. And again it makes sense because if something becomes an industry standard it is very painful for companies to move from that technology to a new one. So why would they do that to themselves, right? They has there has to be a very compelling like completely groundbreaking change for that. um migration to happen because if it's just a little bit better like as I said like Jenkins uh is the worst probably the worst CI/CD uh alternative among all the others and it's still number one because the others are not groundbreakingly better than Jenkins like it still does it its job right the concepts are the same so it still remains in use because you know projects and teams do not want to migrate to new tools. So if you like if you're worried about tools changing like there is no logical foundation for that um fear so to say because data like data indicates that those tools that have matured in the last years where was this slide uh where was it? Yeah, I mean these are exactly the same uh technologies that were like dominant. They were not dominant but they were like clearly uh you know becoming popular five years ago and they're still here after five years and they will still they the demand has increased which means they're going to be around in five years in 10 years 20 years I don't know but as I said how many years or decades have has Jenkins uh been around or Linux or bash so or git for example so you know standard technologies do not change as often concept concepts not change as often. It seems like things are more dynamic than it is. Um, but as I said like DevOps, GitOps, they're not new concepts. They're just different like new flavors of existing concepts that already were there. So things do not change as fast as we have a perception that they do. All right. Where is Yeah, we're still supporting Java 8 in my company. Technologies are slow to be adopted incorporated. That's that is exactly what I mean. Yes. All right. Let's see if uh I have yeah let's go through some of the road maps for like specific uh job roles because I think this may be interesting for you. So um we have yeah so we have as I said like multiple different backgrounds of like software engineering um test engineer CIS admin non IT like we have we had a chess player and we have a blay dancer and we had I don't know like healthcare what many different fields moving into devops but um I actually chose these three uh path So if you are a software engineer and you're thinking about um learning DevOps as part of your software engineering skills, right? You don't want to become a DevOps engineer, you just software engineer who knows DevOps skills. And the most common scenarios that we've um seen and by the way tell me if you can resonate with this is you are a software engineer and uh suddenly because you know your manager or company decided to use DevOps because it's cool and it's um uh you know efficient and it can make the software delivery faster and it has a huge business value for the company. They were like, "You're a you're an engineer. Just do DevOps now. " Um, and there was no one in the team who actually knew DevOps. So, you kind of winged it and you learned it by yourself and you had to do tutorials and you probably watched our YouTube videos to kind of keep up because how do you implement something that you've never properly learned before, right? And it's not like another programming framework that you can switch to or a li library that you can just learn over a

Segment 44 (215:00 - 220:00)

weekend. It's like a completely different set of tools that you've never learned before and concepts like con container orchestration concept was completely foreign to most of three engineers. So you're not learn just learning new tools but new concepts. Right? So this slide is heavy. Yes, I know. Uh I'll try to summarize it or make it a little bit um simpler but basically uh let me know if you can resonate with this scenario where you had to suddenly do DevOps uh work or you know use these DevOps technologies that you've never used before on top of your existing software engineering uh responsibilities right uh they basically just told you here's a cluster just figure out how to deploy it with production best practices right Um so uh the companies started and this is where it started. Companies started including DevOps or DevOps skills or DevOps technologies like they would put Kubernetes and Terraform and stuff on the software engineer or fullstack engineer job posts, right? And you were suddenly thinking, okay, so now I need to know front end and back end and uh cloud and Kubernetes like what else do you expect me to do? And that was the trend basically of software engineers needing to learn DevOps. And again like let me know if you can resonate with this actually. Oh you guys are still talking about the projects. Okay we can go back to this. But um the path from software engineer to DevOps um has been and the the best way to start here is to again start to understand the concepts first because I remember when uh you know when I was a lead engineer uh lead software engineer and I had to work with Kubernetes, I literally did not have enough time to research and understand the concepts properly uh because I had to figure out how to make things work fast and usually it was not with the best practices. So you have this time pressure where you can't even use time properly to research and learn the concepts. But it's really important to understand the high level the big picture and then uh understand you know why you what are the concepts and why you're using the tools in the first place. And the best way best place to start as a software engineer to learn DevOps is CI/CD. It's not Kubernetes because Kubernetes is so far removed from what you're doing. But CSD is literally like the next extension of your work because you're writing an application and your application code when it gets pushed to git repository that triggers the CI/CD pipeline. So it's like the next like a neighbor neighboring set of skills and just focus on understanding why CI/CD pipeline is important for your work as a software engineer and then you can kind of slightly move all the way like to the right side which is operations and Kubernetes and infrastructure and stuff. Um realistically if you are a software engineer you would need to manage your time and prioritize the tasks because you cannot be writing code and then jumping to fix Kubernetes issue and then uh doing terraform update for infrastructure like within hours right so you need to prioritize like what are the areas of focus for you and I would personally just go from what are the tasks that you enjoy the most and what are valuable for the team that most like other teammates are not doing and just focus on that and this is probably the this is clearly like from data the biggest group that we have that is learning DevOps. So this is probably the most important road map here. And by the way, we actually have let me show you this. We actually have a DevOps road map for software engineers specifically. Let me see. Yeah, here. Uh DevOps road maps. Wait, where is it? Okay, I can see cloud engineer road map. I'm going to check I'm going to have to check this. But we do have H. Where is it? Okay. Um, I can't find it anymore, but I can Yeah, I can ask Nicole to maybe send it along. So we actually created a

Segment 45 (220:00 - 225:00)

DevOps engineer road map for software engineers specifically based on so what you already know and how to use that knowledge to basically uh learn the ne like what are the next things or technologies that you need to learn and how you can tie that knowledge on your existing uh skill set or what skills can you reuse for DevOps engineering basically let's put it that And yeah and we have two more path. Let me go through those. Uh CIS admin network engineer. This is a really um yeah this is a very standard one because so CIS admins or network engineers who were working with on premise they had to move to cloud along with the companies that were moving to cloud and uh they were somehow expected to now understand now do everything that we're doing on premise in cloud like in the virtual environment and concepts are similar but you still need to learn the cloud concepts first. So the difference here is that if software engineers next natural step is to learn CI/CD, the CIS admins or network engineers next step into DevOps, the next natural step is actually cloud engineering. So you can start from there because that's where you can leverage your existing skills the most. So you can learn immediately something that is a huge part of DevOps and you can already get the wins and you can understand stuff that you already familiar with to some point and then you can slowly move to towards the left right so to Kubernetes and then to CI/CD and then a little bit of software like the interface of software development obviously you don't need to become a coder um and then containers and so if you're a network engineer or CIS admin you already have a lot of the networking knowledge that is like directly usable for container networking, Kubernetes networking, cloud networking which are like all the uh important things that a DevOps engineer should understand with proper skills of course it's not required from junior engineers but if you again if you want to be a proper DevOps engineer if you really want to build like solid skills then like this gives you a perfect prerequisite for learning the networking side of things in all those tools by the way. Yeah. And then we have junior devils engineers. Again, let me know in the chat if we have Yeah. I'm happy that these slides uh you know some of the stories are resonating. Let me know if you are a junior DevOps engineer who is trying to fill the knowledge gap because you feel like you don't really understand like the big picture. Um yeah uh big picture or you are missing some of the uh you you're concepts or you know a set of skills set of technologies but you don't know how to uh like let's say you know CI/CD but you don't know the Kubernetes part or the operations part or the deployment part of things. Um, and if that's the case, so you basically you have the this like a thin layer of foundation and now you have to kind of go up, right? So you basically need to deepen your skills in every technology. Again, understanding concepts, understanding the high level always top down. There is no exception for this. understanding let's say you're a junior uh develop junior engineer junior devops engineer who knows docker kubernetes I guarantee you that you don't understand the main concepts of those tools because you kind of had to uh learn how to use docker immediately in practical use cases but you never took time to understand okay you know why is docker so important and where does it integrate in this entire thing right because You use docker in a as a container runtime sometimes. Uh now you know we move to lightweight container runtimes. Uh but it was used for that right to understand that part maybe. Uh it is used to build images from the applications to build images. What is the docker registry and repository? Uh what types uh of docker repositories are there? What is the docker networking? Right? So in most junior DevOps engineers cases they know the tools they can work with them but they are still missing some of the foundational concepts behind those technologies and that's the knowledge gap that you have to fill right and then you may know how to use Terraform but or this is also a common use case you know how to work with Kubernetes but when you joined a company as a junior devos engineer the cluster was already set up it was already configured. So what you learned was how to you know uh create a network

Segment 46 (225:00 - 230:00)

policy manifest, how to write a deployment manifest but you don't really know how to set up a cluster from scratch. You don't know how to manage and administer cluster how to create roles and permissions you know what is a concept of arbback. So those are the things that you need to learn as a junior dev engineer if you want to go to the mid-level or senior level right you need to have a back big picture that's what differentiates juniors from seniors understand seniors have this high level overview where they look down and they know okay this is how things combine so they have this architecture overview where juniors are you know down looking up to some kind of maze and mysterious puzzle of things because they know like they're too lowlevel and they don't have uh like a high level overview of things. Yeah, as I said, big picture is missing and the combination of tools because they don't have experience. They have never built like a fully uh like a full end toend processes because usually DevOps engineers join existing teams who have already built stuff. So they're just maintaining stuff or you know writing a little um pull request for a Terraform configuration project which already has uh everything configured for from the senior engineers. So [snorts] that's the gaps you need to fill as a junior devos engineer and this is exactly as I said the projects right here that's when you get the knowledge where you build where you use all these technologies you put them together and then you on top of that understand the concepts and the high level of all of them and that's why I always say it was not by purpose but our DevOps boot camp does not prepare you for a like a for a junior DevOps engineer role like it prepares you for midlevel or up because if it was for junior developers it would probably be two to three like maybe two months but again like please do not learn DevOps to become a junior DevOps engineer. Learn DevOps properly so you can enter the job market as a junior DevOps engineer with mid-level engineer skills. So that's the that should be your goal actually if you're transitioning into DevOps or if you don't have any pre prior experience and then you can go from junior to mid-level much higher uh much faster if you if you're hired at a title which is lower than your skill set because then you can prove at your work. It's like yeah I can do all of this stuff so I should have a title of mid-level engineer instead of junior right? Okay, I think yeah, I think I'm through with most of my Yeah, let's let me go through this slide because I think this is also important and um we still get some questions about uh yes uh about job hunt in general and again how to think about the perspective of the employer and how to kind of reverse engineer from that. First of all, we I kind of broke down what is it that helps you stand out. But I also said you don't need to stand out because there is like a literally uh you know there is no competition if you're good at DevOps. Like DevOps, they're going to hire you. If they have a second candidate that is also good at DevOps, you they're going to hire both of you because there's just enough demand for good DevOps skilled DevOps engineers to satisfy you know the the job how to say job supply or skill supply from all the engineers. So do please do not even worry about that. So worry about actually learning the skills because that automatically means you're hirable. Now the second question is if you don't have experience how do you demonstrate that you have those skills and those was with demo projects number one uh and second one uh I should mention this is LinkedIn so why is LinkedIn good the biggest leverage that you have with LinkedIn because think of it as a search engine so if I'm an employer if I'm a head hunter and I'm desperate for devos engineers because we can't find any what I'm going to do is I'm going to go to LinkedIn and I'm going to search you know the company uh I think the business uh feature of LinkedIn basically lets you search LinkedIn as a database of engineers and I'm going to go there and I'm going to search DevOps engineers or Kubernetes skill set or CI/CD pipeline skill set or whatever and if you have those in your LinkedIn profile you're going to come up in the search results right very simple and now if you're in the search result and your title says whatever your the skills that you've learned

Segment 47 (230:00 - 235:00)

and they click on your LinkedIn profile and they see a git uh link to your project portfolio of let's say DevOps demo projects um and they check that you're and you have all the skills that they're looking for. Now suddenly you're not applying for jobs. you have recruiters and employers and other companies basically actively reaching out to you saying hey do you want to come to uh an interview and if you think this doesn't happen for people who don't have experience you're wrong because we have actual people who like you know when I talked to some of the participants they like they literally they had zero IT experience by the way so they had done like uh the trainings things and they had prepared their LinkedIn properly and they had the G portfolio, the project portfolio from the boot camp projects and they got interviews actively like actively searched by the recruiters and employers. They didn't even have to apply for jobs. So you can use so you can take those projects put it in the LinkedIn and that combination basically gives you appear in search you appear in the search results you get approached by hiring engineer hiring engineers um yeah it's already uh 10 p. m. here. So, um yeah, my um communication skills are decreasing a little bit. Uh so, let me rep wrap this up. So, you get approached actively by hiring managers or employers uh because your skill set suddenly matches their search and they see a proof, a demonstration of your skills with your project portfolio. That combination basically gives you a switch of suddenly you're not applying for jobs anymore. They're actually coming to you because you are with your online presence and with your portfolio you're demonstrating your skills and then if you if there is actually substance behind it you didn't fake all this you get invited to the interview and then in the interview you can demonstrate your own skills. So when I have people who come to me who um send me questions and tell me you know I've learned all this stuff and I can't I I can't get interviews or I get interviews but I don't get hired then these are exactly the steps that are missing. Um I think yeah I think it's it was one of the I think it was Patrick or one of the one of our boot camp studios that I talked to u he said so he was learning uh basically with courses and tutorials and uh he even had certificates and he was invited to interviews but he was not getting hired. So he basically came home after every interview and said okay so what is it that is missing? So they are calling me for interviews but then they are making a decision to not hire me. So that was exactly the things that he had to fill in basically which was demo projects that demonstrated the deep uh level expertise. So just not just shallow projects but like deeper ones that we teach in that boot camp or that I build basically. Um and in the interviews the two things changed right. He suddenly understood the big picture and connection between those tools and wise behind every technology and he was able to explain his own um projects that he built and that was it like he the like he had two interviews um uh I think as I remember he got accept he got uh offer from both interviews. So he got hired basically or he got a offer from both companies and he just chose the one that he liked more and that's the that that's the missing p part. So just look at if you're not getting invited to the interviews look at your LinkedIn profile and your project portfolio because it's not obviously it's not showing uh the potential employers that you are skilled enough. If you're getting invited to interviews and you're not getting hired, then look at okay. So, I'm obviously, you know, I I'm able to at least spike their interest, but my knowledge is not deep enough. I'm not able to show that I understand the concepts. I understand the wise, I understand them deep enough to explain, you know, how to optimize their the different parts of a pipeline, how to optimize a Kubernetes cluster. So, if you feel those two things, then you're not going to have a problem that most people have, which is, you know, you don't have to you won't have to beg for jobs. Literally, you will get offers

Segment 48 (235:00 - 240:00)

immediately. And I say this with so much confidence because I know the perspective of companies. I know how difficult it is to find the skill set at the level that they're looking for. Like again, a lot of people we have on the Kubernetes tutorial alone, the full course that we have on YouTube, I think it has 9 million something views, right? And let's consider, you know, let's say most people watched it twice, right? Let's say that's four to five million people. And there is this huge gap right be between people who know DevOps and people like companies who are hiring for that. which means most people still have to go like deeper and understand the combination of different tools and the deeper level and concepts of those tools because just doing a Kubernetes course or just doing a Docker course is not enough. Um so yeah so that's basically the difference between shallow knowledge and like really um proper deep knowledge and okay I wanted to add something about CVS because a lot of people uh tell me you know how do I prepare my CV how do I um you know do you help for example we get questions about do we help preparing CV is like the simplest thing about and the least important thing about job application like you could literally take a standard like you could ask AI to give you could go to AI you can copy paste a job description that you're applying for and you can say give me a personalized CV which matches like my actual please don't lie my actual skill set and just personalize it to match the job description right so write the list of skills that I have in right order whatever and that will be enough. Okay, you could also tell it to make it optimized to pass all these fil like the filters that they have um in large companies usually they automatically filter out some of the keywords and stuff. So that that's it. You can literally download your LinkedIn profile as your CV like it is the least interesting part because if you we are hiring DevOps engineers right I maybe looked at like one C like I don't usually look at CVS when people apply I look at I usually have test questions so I look at how they can answer the questions uh in terms of like system design and architecture um I look at their project portfolio immediately and if they have any blog articles uh videos like content courses that's what I look at. I think in the last like four years of us hiring DevOps engineers I maybe looked at one or two CVS and I've like we've interviewed and looked at many people's profiles. It is the least interesting part because you can write whatever you want in a CV. such a it's such a static uninteresting uh display of your knowledge. It doesn't tell me anything if you just list their Kubernetes Terraform and AWS, right? It doesn't tell me the depth of your knowledge, the combination of those skills. And anyone can write a good CV, right? A pretty CV that looks amazing and super optimized. So maybe do like the bare minimum that you need to do on CV and then focus all your attention on LinkedIn writing blog articles the focus 80% of your attention on the demo projects themselves and understanding the tools and you're going to like you're going to crush it and yeah the AI you can just use it as I said another use case that um I can give you as a practical tip is because I mentioned that in interviews they're going to ask you questions that demonstrate whether you have understanding of the tools. They're nobody's going to ask you to basically say um how to write a Terraform configuration file, the syntax of Kubernetes manifest file. Nobody's going to ask you that because you can search it online and it's also not relevant. They're going to ask you questions that show that you understand the concepts and the tools and you can solve the problems that they have. So you can go to AI again, take the job description you're applying for and you can tell it tell me the ask me the questions that test my understanding of the tools and concepts that they this company is using in their projects and then just

Segment 49 (240:00 - 243:00)

and as a selfch check just go through those questions and uh answer them and let AI validate and if you if AI tells you okay I'm not really or I'm 20% convinced about your skills, then you can literally just fill the gap and learn those skills or concentrate there. And that's also a way to kind of selfch check because I know that some people struggle with, you know, I've been learning for a whole year with different tutorials and courses, but I don't know, do I know enough to be able to do DevOps work at actual company, you know, should I apply or not? So that's going to be your best way to validate your knowledge. All right. Okay. It's exactly 10 p. m. right now. So on point. I think I said at the beginning that this is it's going to go for 3 to four hours. So this has been four hours exactly. So I'm going to wrap this up, guys. I talked a lot and I I'm going to probably re-watch this to understand how valuable the entire session was. I hope this was valuable for a lot of you. Um please leave your feedback, send us emails, send us messages because I want to understand how much um knowledge I was able to share with you that you probably couldn't get like somewhere else or by yourself. Um I tried to make it as practical as possible, as less boring as possible. I hope I uh managed to do that. Uh there's still some qu You know what? We're going to actually go through the does the chat um uh stay or Okay, so we're going to have the questions. And by the way, it's amazing how many questions you guys are uh putting in there. Uh awesome. So, we're going to actually keep those questions and either I'm going to do like short videos answering uh some of the questions that I didn't cover today or I'm going to do a video like a compilation of multiple questions that you uh that you um put in there. So, in some way, I'm going to make sure or we're as a whole team to answer your questions. Okay? So, keep them coming. Uh and as I said, please let me know your feedback. Uh tell me specifically like you know if it helped you change your perspective on something or if you use some of the techniques that I sh sh sh sh sh sh sh shared with you and you get a job, please share that as well. I would really love to hear that. Um, okay. So, I'm gonna wrap up now and probably go straight to bed because it's literally dark outside already. So, awesome. Thanks everyone uh for participating. Thanks for being so active. I mean, the chat was literally just like exploding the whole time. And yeah, it was an amazing first live stream experience basically. So, take care every take care everyone. uh in all the parts of the world where you guys are joining from and I'll see you in the next video.

Другие видео автора — TechWorld with Nana

Every Networking Concept Explained In 20 Minutes
3 Git Workflows Every Developer Should Know (And When to Use Each)
How AI is Changing DevOps Careers | What You Need to Know
👨‍💻 3 minutes on whether AI will eat DevOps jobs
STOP Learning Kubernetes (Do This First)
Networking Concepts Every DevOps Engineer Must Know
Ctrl+V

Экстракт Знаний в Telegram

Экстракты и дистилляты из лучших YouTube-каналов — сразу после публикации.

Подписаться

Дайджест Экстрактов

Лучшие методички за неделю — каждый понедельник