TechWorld with Nana | DevOps 🚀

There are stories that move you professionally. And then there are stories that hit you somewhere deeper — because you've lived a version of them yourself. Moya's DevOps journey is the second kind for me. When I moved from Georgia to Austria, I started from scratch. New language. No money. No work permit. No connections. I know what it feels like when everything you built before simply doesn't transfer. Of course — it's not comparable to what Moya went through. But I know just enough of that feeling to understand what it costs. He came to Germany for a short vacation. Then, because of his involvement in music, he couldn't go home. For eight years, he waited for a residence permit. He worked jobs far from his background just to survive. He kept a quiet goal alive — DevOps — even when daily life left almost no room for it. No documents. No recognized credentials. No safety net. At some point, he resigned from his job, gave himself six months to study in our DevOps bootcamp, learning for 12 hours a day. And then — before his permit even came through — he landed that DevOps Engineer role. He now builds smart city infrastructure across Germany 🏙️ What makes this journey special isn't the happy ending. It's the honesty about what the middle actually looks like. I hope it reaches whoever needs it today 💙 → Read his full story — and how he actually did it here: bit.ly/4neLWlr

Most DevOps engineers can deploy to Kubernetes. Very few can explain what happens on the network when they do. That gap is why debugging networking issues feels like guesswork — and why so many engineers avoid infrastructure problems they don't fully understand. But the good thing is: you don't need to know everything about networking. You need to know the 20% that covers 80% of what you'll actually use on the job. In my latest video, I break down exactly that — from physical servers, VMs, cloud, Docker, all the way to Kubernetes networking — using one real-world example the whole way through. No dry theory. Just the concepts that actually come up when things break in production. If you work with containers, cloud, or Kubernetes — this one is worth 40 minutes of your time. 🎥 Watch the complete guide here: youtu.be/w0SQGCt-6Ro What was the networking concept that confused you the most? Drop it in the comments 👇

Your environment shapes how you work. More than most people realize. I finally made some real changes to my office last month — added plants (okay, maybe overdid it a little 🌿😁), adjusted the lighting, made the whole space feel less like a room you sit in and more like a place you actually want to be in. And it made a difference. Immediately. When you're doing deep work — really sitting down to think through a complex topic, write, research, build something — the space around you is not neutral. It either supports that state or it fights it. There's no in-between. For me that looks like: good lighting, plants around me, no clutter, and a setup that signals to my brain "this is where we create." The morning ritual with coffee before the laptop even opens helps too. It sounds small. But these things compound. 𝗪𝗵𝗮𝘁'𝘀 𝘁𝗵𝗲 𝗼𝗻𝗲 𝘁𝗵𝗶𝗻𝗴 𝗶𝗻 𝘆𝗼𝘂𝗿 𝘄𝗼𝗿𝗸𝘀𝗽𝗮𝗰𝗲 𝘁𝗵𝗮𝘁 𝗺𝗮𝗱𝗲 𝘁𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗳𝗼𝗿 𝘆𝗼𝘂𝗿 𝗳𝗼𝗰𝘂𝘀? ------------ This week we also reached out to some of our most committed graduates to share their engineering journeys. Many don't even realize how much their path can help someone else who is at the exact same starting point — what worked, what didn't, how they navigated upskilling while still working full-time etc. And you can't imagine how diverse these paths are: - a software engineer who used her maternity leave to upskill, - an IT student who went through every single TWN program while doing his apprenticeship and landed a permanent role, - and a cybersecurity SME with 30 years of experience who decided to cross into DevSecOps. Some already agreed - so excited to share soon 🙂 ------------ And while I was deep in all of this, one message caught my attention. Feedback came in from one of our students, who just started his journey. He spent the last 10 years in HR as a Technical Recruiter hiring for engineering roles. So he spent years hiring for technical roles, gained deep insight into what companies look for in strong engineers, and watched the hiring trends evolve up close. Nobody understands the market better than someone who lived on that side of the table. At some point he decided he didn't just want to recruit engineers anymore. He wanted to become one 💪 And with everything he knows about the industry — he chose DevOps and Cloud as his path: "𝐒𝐭𝐚𝐫𝐭𝐢𝐧𝐠 𝐏𝐡𝐚𝐬𝐞 𝟏, 𝐈 𝐝𝐞𝐜𝐢𝐝𝐞𝐝 𝐭𝐨 𝐟𝐮𝐥𝐥𝐲 𝐜𝐨𝐦𝐦𝐢𝐭 𝐚𝐧𝐝 𝐟𝐨𝐥𝐥𝐨𝐰 𝐍𝐚𝐧𝐚’𝐬 𝟔-𝐦𝐨𝐧𝐭𝐡 𝐭𝐢𝐦𝐞𝐥𝐢𝐧𝐞 𝐩𝐥𝐚𝐧 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐨𝐯𝐞𝐫𝐭𝐡𝐢𝐧𝐤𝐢𝐧𝐠 𝐢𝐭, 𝐚𝐧𝐝 𝐢𝐭 𝐰𝐨𝐫𝐤𝐞𝐝 𝐩𝐞𝐫𝐟𝐞𝐜𝐭𝐥𝐲 𝐟𝐨𝐫 𝐦𝐞." He printed all the materials, spiral-bound them into books, built his own study guide — and just follows the structure without overthinking it. Love seeing students with such commitment, because I know - no matter what obstacles - they will always succeed 💙 Have a great Sunday and productive week ahead! 🙏

There are 2 types of new DevOps engineers: Type 1: Immediately suggests Kubernetes migrations, pipeline rewrites, tool replacements. Type 2: Spends the first weeks understanding the system, talking to the team, finding improvements that genuinely help. Guess which one becomes trusted valued team members? Here's what I see happening: New engineers come in enthusiastic. They've learned all the tools. They want to prove themselves. So they start suggesting changes immediately. And the team shuts down. Because tool expertise ≠ understanding the system. Your first 30 days set the tone for your entire time at a company. I created a detailed video breaking down the exact approach that helps you exceed expectations, build trust fast, and set yourself up for long-term success - without making the mistakes most new engineers make. Watch here: youtu.be/2oBYYZ5nWK0 Hope it's helpful! 🙂

@StMoser Yes, if you create a post for one platform, you can just cross post 🙂

@Njuchi_ Between X and LinkedIn, which platform you think we should use to share our knowledge and learnings? I think that maybe I should create posts in LinkedIn and then cross post in X

I call this The Invisible Engineer Problem 👇 One of our students, who was a sysadmin at a mid-sized company. He went through our DevOps program. Learned Kubernetes, CI/CD, Cloud, Ansible, Monitoring - the whole stack. Then he went back to work and applied everything. Automated their backup processes. Reduced deployment time by 70%. Saved them thousands in cloud costs. His team loved it. His team leader was happy. But nobody above them knew. Not the engineering director. Not the VP. Not the recruiters who could've offered him better opportunities. He was doing excellent work in "private". Then he started posting on LinkedIn. Nothing fancy - just updates on what he was implementing. A simple diagram of his CI/CD setup. A post about a Docker networking issue he solved. Within two weeks: His VP commented. A recruiter from a Fortune 500 reached out. Another bootcamp grad at a different company asked if he was open to opportunities. Same skills. Same work. Different visibility. But here's what bothers me about the "build your personal brand" advice... Most engineers hate self-promotion. It feels fake. Like you're showing off. I get it. I felt the same way. But here's how I reframed it: You're not bragging. You're teaching. Share the Terraform module you debugged for 3 hours. Post the monitoring setup that caught a production issue. Write about the CI/CD mistake that cost you 2 days. Someone else is struggling with the exact same problem right now. Your "basic" knowledge is gold to someone earlier in their journey. And while you're helping others, you're also: → Building proof of your skills → Creating content that recruiters can actually see → Differentiating yourself from 100 other "certified Kubernetes admins" The job market is becoming brutal now. And if you're not marketing yourself while you're employed, you're setting yourself up to panic-apply when the layoff hits. Start now. Not when you're desperate. 💬 What's stopping you from sharing what you know?

Watch the full tutorial here: youtu.be/IQZPC0sFqMk

The first time I heard "multi-cloud", it sounded simple. Use AWS for this. Google Cloud for that. Azure for something else. Best tool for each job. Easy. Then I actually tried to make it work. Suddenly I was dealing with: ‼️ Three different credential systems ‼️ Cross-cloud networking that nobody talks about ‼️ Infrastructure I had to maintain in two or three places at once And a cloud bill that made no sense. Here's what you should know: Netflix, Spotify, and Uber use multi-cloud. But not because it's simple. Because they figured out the right architecture to make it manageable. So I made a full video breaking down exactly how multi-cloud works in practice: youtu.be/IQZPC0sFqMk Not the theory. The real problems. The real solutions. And a live demo deploying across AWS, Azure and GCP. If you're working with cloud infrastructure — or want to — this one is worth your time. 💬 Are you already working with multi-cloud at your company? Curious to hear where most teams actually are with this.

My first KubeCon is coming to an end and I'm sitting here trying to process everything 😅 For me conferences are never about the talks. It's always about the people. And KubeCon delivered on that in a way I didn't expect. Yesterday I spent the whole day at the AWS booth — interviews, talking Kubernetes with amazing AWS engineers, and just... meeting people. Fellow engineers, educators, open source contributors — people who are just deeply passionate about this space. Every two seconds someone came up to me — bootcamp students, YouTube subscribers, people who've been following TWN for years — to talk, take a photo and share their story. I barely had time to eat 😃 And I wouldn't have had it any other way. Honestly, I'm so grateful for every single one of you. AWS made this whole experience possible and I'm really glad we partnered up. Well organized, great team, and topics I genuinely care about. It also started earlier than planned — KubeAuto Day on Monday, where I gave a talk and joined a panel on short notice 😅 That kind of set the energy for the following days. I couldn't make it to a single presentation the whole time. Not one. And honestly I have no regrets. Seeing the impact in person — engineers coming up to tell you how your content changed their career path — that's the kind of thing that reminds you why you keep going 🙏 Photo dump from the last days 👇 — hopefully gives you a sense of the vibes. Thank you to everyone who came to say hi. This one I won't forget 🙂 #KubeCon #Kubernetes #AWS #CloudNative

QA engineers have a hidden advantage for DevOps that nobody talks about. 🔥 You already understand quality gates, testing strategies, and failure scenarios. That's exactly what DevOps needs. ✅ Your transition path: • Test automation → CI/CD pipelines • Scripting → Infrastructure automation • Test environments → Infrastructure as code Your edge? You think about failure modes and edge cases. You don't just build - you question. That's the DevOps mindset developers learn from scratch. 8-10 months to job-ready if you're consistent. 📅 Want a personalized roadmap for your transition? We now offer free orientation calls to map your QA skills to DevOps requirements. Grab your spot while it's still available 👇 bit.ly/4rOwSeY

Entry-level hiring at big tech is down roughly 50% compared to pre-pandemic levels. Junior roles are getting absorbed into smaller, more senior teams. Here's my take 👇 The job market is really harder right now. If you've been applying and hearing nothing back — you're not imagining it. But it doesn't mean that the opportunity has disappeared. It has simply shifted. The reason companies are hiring fewer engineers, is NOT because they need less done. They're hiring fewer engineers because they need more from each one. The times of getting paid to tick off a task list are ending. What they actually need — and can't find enough of — are engineers who understand systems deeply, take ownership, and make real decisions. A quick note on DevOps specifically: DevOps is not an entry-level path. Most job postings implicitly target mid-level or senior people — because a strong DevOps skillset means you already understand software development, operations, cloud, K8s, CI/CD, and observability. In many companies, DevOps isn't even a separate role. It's just what a senior engineer looks like. Now about AI. Because I know everyone's thinking it. Nobody actually knows what it means for jobs in 5 years. Not me. Not the LinkedIn thought leaders. Not the tech CEOs doing podcast rounds about it. Both extremes are wrong: "AI will replace all engineers" — wrong. "AI won't affect engineering at all" — also wrong. The roles that are under real pressure the most are ones doing narrow, siloed work — low-context, repetitive. AI is very good at those tasks. Including some of the specific DevOps automation stuff actually. The engineers I believe aren't going anywhere? The ones who can connect code, infrastructure, security, and business outcomes. And who can look at what AI produces and say "that's wrong — here's why" or "that's correct - and here's why" So what do you actually do right now? Not this → wait and see how it all turns out. Not this → skip fundamentals and just learn AI tools, hoping that's enough. Both lead nowhere good. My honest take: Broaden your skillset. Understand how the full system works — not just your piece of it. Cloud, CI/CD, K8s, observability, security — these keep showing up in job postings for a reason. And here's something people keep forgetting: every AI model you use runs on infrastructure that needs to be deployed, scaled, and maintained — that's Cloud and DevOps. Don't learn these things just enough to copy-paste from a tutorial. Learn them properly, to the point where you can design, debug, and explain what's going on. And yes — learn AI tools too. 🟢 Powerful when you know what you're doing. 🔴 Dangerous shortcuts when you don't. The best thing you can do in an uncertain market is become more skilled than the people around you. But skill alone isn't enough anymore. You could be the best engineer in the room. If nobody knows you exist, it doesn't matter. Visibility is part of the job now. That's what LinkedIn is actually for — and it matters more than ever right now. Bottom line is: the door hasn't closed. But it became higher and more competitive. What's your take?

Finally releasing my Seattle Amazon HQ vlog from this summer! I met several lead engineers from AWS teams and recorded in-depth technical podcasts during my visit. These full conversations will be shared with the TechWorld with Nana community over the next few months. 🎙️ Topics we covered👇 Kubernetes architecture deep dives, serverless use cases, security architecture best practices, spec-driven development versus vibe coding (this sparked great debate!), and business insights from inside AWS. The highlight? 💙 Meeting TechWorld with Nana community members who came to say hello at the event. There's something special about connecting IRL with people who've been part of this journey online. ☀️ Watch the full vlog here: youtube.com/watch?v=8nRHaB… What topic are you most interested in hearing more about? Drop it below 👇

Something exciting is happening next week — I'll be at @KubeCon_ EU in Amsterdam. And this will be my very first KubeCon ever 😀 I honestly can't believe it took me this long to get there, but AWS made it happen. I'll be hanging out at the AWS booth #700 all day on March 25. Throughout the day I'll be hosting some cool sessions with industry experts right at the booth — here's a taste of what we'll be covering: 🟢 𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝘀𝘁𝗮𝗿𝘁𝗲𝗱 𝘄𝗶𝘁𝗵 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 — a beginner-friendly conversation about the simplest path to running your first app 🟢 𝗥𝘂𝗻𝗻𝗶𝗻𝗴 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗮𝘁 𝘀𝗰𝗮𝗹𝗲 without the operational burden 🟢 𝗛𝗼𝘄 𝘁𝗼 𝗼𝗽𝗲𝗿𝗮𝘁𝗲 𝗔𝗜 𝘄𝗼𝗿𝗸𝗹𝗼𝗮𝗱𝘀 𝗿𝗲𝗹𝗶𝗮𝗯𝗹𝘆 𝗼𝗻 𝗞𝟴𝘀 — because what works on your laptop rarely survives production 🟢 Perspectives from CNCF board members — 𝘄𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝗰𝗹𝗼𝘂𝗱-𝗻𝗮𝘁𝗶𝘃𝗲 𝗲𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗵𝗲𝗮𝗱𝗶𝗻𝗴 🟢 And the one I'm most looking forward to: a 𝗽𝗮𝗻𝗲𝗹 𝗱𝗶𝘀𝗰𝘂𝘀𝘀𝗶𝗼𝗻 𝘄𝗶𝘁𝗵 𝘀𝗼𝗺𝗲 𝗮𝗺𝗮𝘇𝗶𝗻𝗴 𝘄𝗼𝗺𝗲𝗻 𝗳𝗿𝗼𝗺 𝗔𝗪𝗦 𝗮𝗻𝗱 𝗔𝗪𝗦 𝗛𝗲𝗿𝗼𝗲𝘀 𝘀𝗵𝗮𝗿𝗶𝗻𝗴 𝘁𝗵𝗲𝗶𝗿 𝗷𝗼𝘂𝗿𝗻𝗲𝘆𝘀 and what actually accelerated their careers 💪 So if you're there this year — come find me at the AWS booth on 25th of March. I'd love to meet some of you in person. So many of you I only know from socials, and it would be really cool to finally put faces to names 😊 And yes — there's also swag 👀 Of course @awscloud has much more going on at the conference - like hands-on K8s workshops, interactive mini-theater lightning talks, and a keynote from Jesse Butler you don't want to miss. Check it out here 👉 aws.amazon.com/de/kubernetes/… Hope to see some of you there! 😊 Drop comment if you'll be there.

"You need to learn Kubernetes for DevOps." 👉 Terrible advice for most people. Why do I think so? 70% of DevOps jobs don't actually need deep K8s knowledge. They need cloud fundamentals, CI/CD pipelines, and infrastructure as code. But recruiters throw "Kubernetes" into every job post because it's a buzzword. Interviews test container basics, not custom operators. What to do: ➡️ Master Docker first 🐳 ➡️ K8s basics (pods, deployments, services) ➡️ Covers 80% of roles ✅ Advanced stuff? Platform Engineering at $180K+. Tired of guessing WHAT to learn? Book a free call with my team → for YOUR exact roadmap. Use this link below before the slots are gone: bit.ly/4cNm6lB And watch my full breakdown in this short video 👇

Want a personalized roadmap based on what you already know? 🗺️ My team offers free orientation calls currently where we: • Audit your current skills • Create your specific 6-12 month plan Limited spots available 👇 bit.ly/4ljYDdK

Here's the mistake everyone makes when learning DevOps: ⚠️ Learning linearly. ❌ You should be applying each phase to a real project, building on it continuously. Theory without application is useless. Who else has 50 unfinished tutorials saved?

But here's the mistake I see a lot of people making: learning linearly. ⚠️ You should be applying each phase to a real project, building on it continuously. Theory without application is useless. 💡

So here's the order that actually works if I were starting from zero in 2026: 👇 Phase 1 - Foundations: 2 months ⏱️ Linux fundamentals, bash scripting, Git. Without this, everything else is shaky. Phase 2 - Cloud basics: 2 months ☁️ Pick AWS or Azure, learn compute, storage, networking. Not certifications - actual hands-on labs. Phase 3 - Infrastructure as Code: 1 month 📝 Terraform or Pulumi. Learn to provision infrastructure through code. Phase 4 - Containerization: 1-2 months 📦 Docker, then Kubernetes basics. Phase 5 - CI/CD: 1 month 🔄 Jenkins, GitLab CI, or GitHub Actions. Build actual pipelines. Phase 6 - Observability: 1 month 👀 Prometheus, Grafana, ELK stack basics. That's 8-10 months to job-ready. ✅

After 8 years as a Senior Manufacturing Engineer in medical devices, Ana walked away from a stable career to start over in tech - with zero IT and DevOps experience. Now she's a Cloud DevSecOps Engineer deploying production systems with Kubernetes across AWS, Azure, and GCP. She's achieved Golden Kubestronaut status and is now helping others make the same transition. I sat down with Ana to talk about the reality of career switching → the fears → the interview process → the day-to-day work → and what actually got her hired over CS graduates. This conversation is full of real insights for anyone thinking about making a similar move. Watch the full interview here: youtu.be/q6x8J7QIakI If you're thinking it's too late to switch careers or you need years of experience to break into DevOps - this one's for you 💙