0:00 Introduction and Missing Co-Host

0:00 Hey, everyone. Unfortunately, Laura couldn't join us today for this episode. So, obviously, there's about 200% less snarky comments. Well I'll let you decide if that's a win. Sorry. I sent an AI ducky instead. Speaking of ducky's, if Karai looks like a statue for the last five minutes, don't adjust your screen. The machines let us down. We tried to fix them with AI, but David's Linux machine is about as useful as a ducky at fixing video. Enjoy this episode. Welcome, and thank you for joining me on today's episode of Cloud Native Compass. Hello, Karai. For anyone who's not familiar with

0:25 Meet Koray: Background and Experience

0:31 your work, could you please take a few moments just to tell us a little bit about you? Yeah, sure. So, yeah, my name is Karai. I'm Turkish. I live in Istanbul. Nowadays, for the last almost four years, worked for a company called Kubernetes, where we help people or help companies with their cloud native and Kubernetes journeys. Prior to that, I worked as DevOps engineer, operations engineer, SysAdmin. So I was always on the operations side. I would say I've never worked as a developer. I mean, from Unix Linux background, but yeah, nowadays it's Kubernetes mostly. I

1:12 married, I have two kids. Life is fun with them and also with cloud, everything. I was selected as CNCF ambassador since last year. I have also bunch of certificates now. I'm a cube astronaut. They will announce a golden cube astronaut soon, I think, which is for the old CNCF certificates. But I don't think I'll go for that one, but yeah, we'll see. Awesome. Yeah, that's mostly it about me. All right. Thank you for sharing all that. I am also married with two kids and fun isn't normally the word I call it. Yeah, want to say fun, that's yeah, yeah, because they are

1:52 my kids, they are my kids, I say fun, but bunch of other descriptions for that I totally agree. Alright, awesome. Again, thank you for sharing. So let's dive into that a little bit. Cloud native and Kubernetes for four years now. Yep. Now as a CNCF ambassador, and congratulations on that. It's a fantastic tale to hold. Thanks. I'm assuming you've been in this space for a while. So could you maybe share and let us understand how did you end up in this whole Kubernetes cloud native landscape? You need to be lucky to start working for a company like Kubernetes where

1:59 Journey into Kubernetes and Cloud Native

2:25 their main work is Kubernetes and cloud native. So there is a job opening and a lot of really qualified people apply for it, but then you somehow go through the path and take the job. But for me, at the beginning of my career, I was mostly on the telco side, telecoms IT side, about working with the rating charging applications, billing applications, that sort of stuff. That space is, you just work with mainly closed source, that software from companies like Ericsson or Huawei, and that's the main thing. But I always wanted to work for more on

2:59 source side more and more. My initial more DevOps like work was at Ebank in The Netherlands. I was part of DevOps team, we were actually having those really CICD pipelines and everything, so more like edge work. And then I joined the company here in Turkey where all the infrastructure was on Google Cloud, on GCP, which also contains some GKE clusters as well. I had started to work with OpenShift before while I was at ING. So some initial, let's say, or introduction to Kubernetes containers more. But then after I changed my job, so I just had to work

3:37 with the containers, GKE clusters, also a lot of other services from GCP, which was fun. And I learned a lot there. And later on, I joined Kubernetes. So you only work with managed services like Cheeky or EKS. You learn some part of the Kubernetes. Mainly you learn to run your applications, run your workloads. But of course, there are more to actually manage the cluster itself with its upgrades and stuff. So when you work on a managed environment, someone else does it for you or makes your life easier about that point. But later on, I also started to work more on

4:20 managing or not design, but architecting clusters, the environments, infrastructures. So back to the question, how I ended up there, I really wanted to do this, but I was also lucky that it was after pandemic, like towards the end of pandemic, looking for a remote job and found it there and somehow passed the old interviews and got it, I don't know, luck somehow. Of course you find your way, of course you show that you are capable of doing the job, etc. But in the end, I'm quite happy with that. Yeah, what is it they say? Luck is just, you know, where

4:53 skill meets preparation. Yeah. So I'm assuming when you were working for ING, was no Kubernetes there, right? No, there was a project to move towards OpenShift a little bit. Not there yet. At least my team, we were preparing our applications to move containers at that time, but then I left. I think they continued. But my first introduction to Kubernetes was there with OpenShift. Well, they're probably not there yet. I mean, no disrespect to ING, but all banks seem to move at a glacial pace. And that's because the sensitivity of their product and their data and all of that stuff is governed

4:55 Challenges in Adopting Kubernetes

5:26 so much so that it slows it down. Yeah, exactly. It's quite hard for telco companies, for banking to move towards. Definitely, they can't move to public clouds, at least for their core services, maybe their websites or like some other stuff might be some, I don't know, not data driven services might be running on the public clouds, but definitely not their core services. It's also issue here in Turkey as well. There are, yeah, they just can't use AWS or GCP because there is no data center here. You are not allowed to send the data out of

6:01 the country, like call records or bank bank account records, etcetera. Either they have their own data centers, their own on premise cloud, or there are companies who do that for them, of course. But, yeah, it's not the same scale comparing to the other ones. Alright. Well, I'm curious about I love the fact that you're a trainer and a consultant. So you're seeing multiple angles here. You're helping individuals and companies and teams level up their their skills. But as a consultant, you're also navigating architect and guiding, etcetera. And now that we are over ten years and

6:17 Training and Skill Levels in Kubernetes

6:33 to this Kubernetes thing is is ten years old as a project. Yeah. What is what is the skill level like? What is the knowledge of people that you're working with these days? Have they had have they ever worked with containers before, but they want Kubernetes? Have they just decided Kubernetes, even though they've got monoliths, like what does that look like? There are both of them. So exactly some people get the training. Some people even we had some companies where they get even Linux fundamentals training because all they do is on Windows all the time. So we just tell them, yeah, let's

7:06 start with Linux because you will need it, at least some basic understanding of how it works or what you do. And then we go with the container fundamentals and then Kubernetes fundamentals, etcetera, that sort of stuff. So there are still companies who have never used containers before, or they're on the way to start migrating. Those are the ones that get the training, right? So they want to migrate to containers or Kubernetes in general. So that's why they get the training. But there are also other companies where, I don't know if it's right to say, but for example, they want to get away

7:41 from VMware to some other solution. They've already using Tanzu, but due to the So they know Kubernetes, but they need some other sort of solution because of yeah, licensing or whatever. Those are also there, but both of them exist. And for us, for the people, probably for you as well, Kubernetes is kind of not boring, but yeah, we learned it and we know how it works. But for some people, it's some brand new technology. Sometimes I get surprised when I see on LinkedIn, there are posts like, Hey, here's how you can best practice for Docker files. I'm like, yeah, for me, this

8:19 was like ten years ago. I'm not ten, five years ago, six years ago, but for some people it's brand new. So both of them exist. And another question or another angle is that does everyone need to move to containers? Everyone need to move to Kubernetes? That's also another question. I mean, I think it's not for everyone like- Definitely. Not for their use case. If their use case is supporting it, then it's good. Again, multiple parameters, some parameters are based on the regulations like having data centers, local data centers, etcetera. But some of them are just, they are

8:55 too big companies to make changes easily. That's also other case, I think. Or they are just happy with their current infrastructure. It works fine and they just don't want to change it. That's that's also there. Yeah. So two things there. The VMware Broadcom is causing hysteria and mass migrations across our industry. I I see it in the limited capacity that I work with other companies. Yep. But I I I ask curious about that question because I go to a lot of conferences and at those conferences, occasionally, do three Kubernetes trainings or half days or or whatever. Mhmm.

9:29 And it's hard for me to gauge how many people are just gauge. Gosh. I don't even know what that word is now. It's hard for me to understand. People are just there because the training happens to be a conference they're at versus the people are specifically looking for Kubernetes Because I often find the people in that room and again, it's Kubernetes trading. When I ask them, have you used containers before? It's still rare for more than half the room to have their hands up. Right? It's still the minority of people that have played in used containers.

9:57 Yeah. Forget even asking if they're using containers in production because it's still usually one or two hands. Yeah. Yeah. And then you say, who understands container technology and Linux primitives? And, again, almost zero hands are going up. And I never know if it's just because these people are just using the training because they're there, or maybe they're just being told they need to learn Kubernetes because let's face it, we're now in 2025 at a point where Kubernetes is this huge project with so much momentum powered by the CNCF, biggest conferences we've got and people just feel

10:27 like I have to learn this thing. But they've not been through the struggles and tribulations to understand why that thing is important. And I I was just curious from because you do a lot more training and consulting of whether that is something that you're seeing as well. Yeah. Yeah. Is definitely. From what you said, I think you are right. You're this is the same at least at some at least to some degree, this is the same journey that people are taking with your treatment and consulting. Yeah, exactly. Again, there are people who have already been playing with and they

10:56 just want to change their tooling to something else. But there are a lot of people, it's true. So there are people who have never done it or never worked with containers before. That's fine. Maybe their company was not, they didn't need to. But there are also people who have been working with it for a couple of years, but they haven't understand what's happening under the hood. That's also, I think, I mean, people can argue that it's not important for a developer to understand. They just need to run their code. Someone just packages it, like packages it as a container

11:31 and deploys it. In the end, the application is running. But I think to make use of the whole platform in the right way, I think everyone needs to understand how it actually works. What's happening there? What the container is? Why it's there? Or what the pod is? What you can do with the pods, what sort of configurations or options you have there. I think these are all important stuff. So I've seen many cases people running their pods or containers in privilege mode. Is there any reason for that? No. There are some pods that needs run-in the privilege mode.

12:06 Yes. But not probably your normal workload, right? People just copy paste stuff. And then if it works and then they continue with it or they just take it for granted and just use it. But I think learning is important about how it's going. And there is also a fact that the Kubernetes is quite complex system. So yes, it makes it easy. I mean, if you only want to do a deployment of your application, it's easy. You just write some YAML files, you have your container, it just works. But there are a lot of different stuff

12:20 Tools and Best Practices in Kubernetes

12:41 going on happening in the background. So for any system, I think also if you are Linux admin or if you are Java developer, you need to understand how the whole stuff is happening, how the garbage collection is happening. So I also in the past worked with some developers that they have no idea about the garbage collection or how it works or how it can be configured. So that's, I think, general problem that people don't care about this, but I think that's the important part which makes the difference whether you are a good developer or a

13:13 good IT person or do things right. Yeah. I think you're right. Learning is it never stops. Yeah. Yeah. That's true. Kubernetes is certainly not slowing down in the last ten years. Yeah. It's practice changing more now than it ever did. And I love what you said there, right? Everyone I think all online content is guilty of this, and I'll put my hand up sometimes to say I do this. Yeah. Giving someone a YAML to do a deployment to Kubernetes cluster doesn't teach people how to run workloads on Kubernetes as 1% because, of course, we've got the substrate. There's a

13:44 control plane, the API server, the Kubernetes, all that. Now a lot of people can avoid that. They can use managed services. But even even that little bit on the top, a little bit, the massive bit on the top, you know, to let me rephrase this question. When you're teaching people Kubernetes, do you teach them to work with deployments and services and endpoints and stop? Or do we set aside twelve days and say, okay. Now we have to learn get ups. Now we have to learn observability. Now we have to learn continuous delivery. Now we've got to do progressive rollers. Now we've

14:15 got to do automation within the cluster. Like, the land the surface of knowledge that people need not just to deploy to Kubernetes, but to be successful with Kubernetes is a volatile landscape itself. I'm curious how you tackle that. The trainings, we have some agenda and talk about those, but not like in deep, to be honest. So it's also, for example, the GitOps question always comes in, how do we do this or can we do that this way, etcetera. For the trainings, we do or I do in general is that we talk about the objects, at least the

14:51 core objects and some extra ones like additional ones like ingress, etcetera, about what they do, why they are there, the relation between the pod and the replica set and the deployment and why stateful set is there, why we have daemon sets, etcetera, that sort of stuff, to understand how they work, why they exist, etcetera. But then there are a lot of other topics. So these are like mentioned on the surface. Yeah, because of time limits, of But I try to direct people to those topics. You need to maybe look at the service meshing. You might need it. You don't have to

15:27 have service mesh, but you might need it for this and that. Yeah, you may need to use, you should use GitOps approach. Which one, it doesn't matter if ArgoCD or Flux, whichever works for you. I like Flux more. ArgoCD is great. But yeah, in the end, it's about the result, right? So if you have your manifest somewhere and then managing your cluster over those manifests, it's great. Doesn't matter which tool you are using. Yeah, I like that approach. Like teach people the primitives. Yeah. Teach them everything that they need to know and then give them a map of

16:01 the landscape for them to follow their path after that, because everybody, what they're trying to get out of Kubernetes is gonna be different depending on their use case and what they're trying to do with Exactly. And also the landscape is like too broad. There are too many stuff that we can talk about. Yeah. It's also hard to keep up with what's happening, what's new tools. So you probably heard there's a new tool, Krow, Kubernetes resource operator from AWS, GCP and Azure. They will be supporting that project. So it's like cross plane to some extent, but not exactly

16:37 cross So you can simply create CRDs and create another object like, I don't know, test environment, which consists of some deployments, maybe some database on GCP or AWS, etcetera, that sort of thing. But it's quite in early stage when it's new. Every day there is some new project, new things happening, and it's really hard to keep up with. And also sometimes there are very powerful tools which is supported by that huge company. And then another huge company says that, hey, we have this one, which is faster or it is blah, blah, blah. And then you need to know both of them because

17:14 especially in our case, sometimes customer says, yeah, we are on this platform. We want to use this. And then they are on that platform, they want to use that. You can't, my job is not to mandate to or tell people to use OPA or Kiverno. I say like, hey, if you have OPA already use it, but if you want to have a new policy engine, Kiverno is more Kubernetes native. Okay, it's that one, but it's your decision. And then they say this and that. So too many things to follow, not easy. Yeah. When I go to conferences,

17:44 Choosing the Right Tools for Your Needs

17:46 occasionally people will ask what cloud native database should I be using or what message queue is the best right now. And I hate those questions because one, my my default answer is what day of the week is it because this stuff changes all the time. But secondly, asking what the best is comes down to actually understand what you're trying to get out of it. The best database is okay. Do you want something stable that never changes, but it is performant? Go with Postgres. But do you want something that's future phasing and doing cool stuff with rust and IO urging?

18:13 Oh, then maybe you should go see SeqStorm or something. There's no right or wrong answer here. I think it comes down to just giving people that confidence and the ability to explore this landscape in a way that makes sense for them because the tools I pick are not gonna be the tools that you pick. And the tools that you pick are not gonna be the tools that someone else over there picks. And that landscape document is just wild, isn't it? Yeah, exactly. Yeah. Just like I said about Flux and Argo CD, I like Flux more because for me it's

18:39 more GitOps style than Argo CD, but Argo CD is also great. It's not a bad product or something. It's doing a great job and a lot of people using it. I also use it for with clients and projects, whichever works for you, whichever you feel like is better suited for your case. I think that's fine. But again, you need to follow many things and I totally agree. There's there's no answer for which one is the best. Which one suits you best is would be a better question. Just like you mentioned, like what you want and

19:11 then based on your requirement, this would be the best option. I think that's but again, to be able to do that, you need to first know what you want. And second, which tool provides that for you. All right. Now, just to put you on the spot, go against everything you've just said now. I'm gonna ask you to see what is your preferred, not best, preferred C and I? To see you. Choice. Alright. What's your preferred flavor of managed Kubernetes? GKE. Alright. Alright. Silly and JKE, that is the best because we both agree. Everyone listening, that's

19:23 Preferred Tools and Final Thoughts

19:44 the one you should be using. Thank you very much. Alright. No. But serious talk. See this talk again. Now, obviously, some people listening to this are gonna be hearing us talk about the complexities of Kubernetes, the evolving cloud native landscape, and maybe be a little bit worried about do they even want to be in this industry anymore because how the hell can they keep up? There is a time and a place to learn all the bets underneath the under the water of the iceberg. And sometimes you could just skate along the top and have the managed service. And you're training

20:10 and consulting. What is there any heuristics you've got to understand or help people understand? Are there any heuristics that you have came up with that help people understand when to make that decision of just managed service versus getting into the weeds of Kubernetes and cloud native? In our case, to go back a little bit, product, Kubernetes product is simply to manage multi clusters on multi different clouds or multi different providers. So simply when we have, when you install KKP, you kind of have, you are able to provide managed Kubernetes to your clients, internal, external, whatever on different clouds. In that sense, what

20:35 Introduction to KKP and Managed Kubernetes

20:47 we are providing is like our customers become or are able to have or provide many services to many Kubernetes classes to their customers. So in that sense, that's my go to part mainly because we either sell this product and then working with it, or we are doing POCs, etcetera. But to your question in general, I think the first thing is about the experience and number of people or the team size of how you can manage the infrastructure in general. So you will probably not have one Kubernetes cluster, but you will probably have a database or some other infrastructure

21:10 Public Cloud vs On-Prem Kubernetes Management

21:29 as well. And if you are already on public cloud, then I think with a small team, it makes sense to use a managed service because you get some help already for the upgrades, for the maintenance or health of the cluster in general. But if you're on prem already and you have to do things on prem, then you don't have many options. Yeah, that's it's there. I mean, you will have to deal with but it's also okay, I think, if you want to have more freedom. For example, when you have a GKE cluster, you have a certain CNI installed there. So

21:56 Customization and Freedom in Kubernetes

22:06 if you want to use Cilium, then you have to do a lot of extra stuff to make it install. I tried it once. I wasn't successful. I didn't care. I just tried to do it. I think it can be done. It's documented. But yeah, you can't make that choice. Or the choice to have some other control plane tools, or you cannot, for example, open feature gates on the API server because you just use whatever is provided by them. But if you are experienced, if you need those kind of stuff, I mean, if you have the team to be

22:38 able to manage things, then just creating a few on the cloud using Kube ADM to create a cluster is also fine or some other tools to have a cluster is there. But I think my main concern would be the experience again. And also if you really need to make customizations to that clusters. If you don't need it, then yeah, I think it's If you only want to run a couple of workloads, then I think you can just go with the managed service, which would make the life easier for you. Yeah. I think that's a pretty solid answer.

23:12 If you're a one or two person team, the operational complexity of Kubernetes and managing that is gonna be tough. Right? Yeah. I'm not even talking about bare metal, even running that on the cloud is going to be tough. Upgrades don't always go seamlessly. I think managed services are probably the the best approach for most people, but I liked your caveat as well. Kubernetes is a fast evolving project. It does have feature case. It does have things you can configure at each level of the control plane. And if you need that level of, I don't know, configuration to a point, if

23:41 you're doing HPC, then yeah, you're going to have to go alone and you're going to have to configure it this way. And then if you are on bare metal, good luck because storage on bare metal is such a huge problem. True. There are also not many solutions there and they all have issues, let's say. They're all expensive either is your time or is money expensive? I agree. All right. So I'm curious then, you're a well versed person in Kubernetes and cloud native. I'm assuming you're always looking at new shiny technologies. Is there anything in the future that you

24:04 Future Technologies in Kubernetes and Cloud Native

24:13 think is gonna play a bigger part in our industry? Any technologies that you're interested and excited by playing with experiment with anything like that? I'm not very good at about to predict the future, about technical stuff. Yeah, nowadays AI is the whole buzzword and everyone is talking about it and also- We almost made an episode without saying AI. Yeah, sorry about No, I will not say, but the thing is that CNCF is also pushing it to run the AI workloads on Kubernetes as well to make things together. So I think things are going on this

24:47 direction, at least they are pushed on this direction. But I also can't predict that every day on that side, on the AI side, are some new, some something new. It's also hard to follow there. But other than that, I think for Kubernetes definitely will stay for a few years. Again, there are people who recently moved there and especially for enterprise companies, which means that you'll get five years support for whatever products, three years support is already there. So I think Kubernetes will be, will stay here for a long time. There was a talk in one of the conferences

25:07 The Complexity of Kubernetes

25:27 a couple of years ago. The idea was simply that we make some new things. They are like great, they do the job, they're elegant, nice, small things and then we make them complex. And at some complexity people say that, hey, it's too much. We need something like something that does the job, something small, something easier to manage, then we create it. And then again, it becomes complex because of everyone wants to do something extra. So I think Kubernetes is in that stage now. Initially it was still doing a great job, but it was like just to run the containers in a

26:03 more production like environment with peeling and running multiple nodes, etcetera. But nowadays you can even manage your infrastructure through Kubernetes with tools like Crossplane and others. Yeah. It again became complex. So probably at some point someone will say, yeah, that's too much. I just want to run my workloads and here's a new tool. It's faster, it's blah, blah, blah. But I don't know when this will happen or how this will happen. I really can't predict that much. But I think it will come to that point because again, Kubernetes is a great project. It has now

26:40 you can do a lot of stuff with it. But yeah, it's also too complex and hard to learn. People will start over at some point probably to run their workloads. I don't want to say easier, like in a more, yeah, easier, but in a less complex environment. All right. I'll allow that. Thanks. All right. I have two more questions for you. One of them a few minutes ago, mentioned having one cluster or multiple clusters, and I think this is a problem that a lot of people struggle with is should I have one huge cluster with all my work loads or should I

27:01 Cluster Management Best Practices

27:13 be running many small clusters? What are your thoughts on that? What would you consider best practice? As a consultant, my answer will be, it depends if you have like doing multi tenancy, if you have different type of workloads or running many namespaces or different environments like dev test in one cluster, maybe it makes sense to separate them just because it would be easier to manage that cluster. Manage meaning like to do the upgrades, etcetera. So I mean, putting everything into one cluster is like putting all your eggs into one basket, I think if you can separate things, makes

27:51 more sense to have more availability or like managing things easier. But that doesn't also mean that instead of one huge cluster, have a hundred clusters. That's also probably not the best approach. But clusters with one pod each. Yeah, yeah. For example, yeah. That's also not the Then just run back around, right? In a VM. You don't need Kubernetes there. Yeah, if you can separate things to different clusters, I think it makes sense to me because then if you lose one cluster, then the others might be running. Or if you are doing an upgrade to one of them, things fail, then you can

28:29 get the knowledge and then do things. You have different environments, right? So you have dev tests, staging, production, whatever. If they are on separate clusters, then something fails on dev and you'll see that, yeah, okay, I need to I should do things differently on test and staging, etcetera. But if you put all of them at this not the production, but the others into one cluster in different namespaces, then if during the upgrade if things fail then you'll lose all your environments. So in that sense separating them makes sense to me, But again, if you have the resource to

29:06 be able to manage those, etcetera. So it's, I don't know if there's a right decision there or the right answer to this. Yeah. I think you've gave it. So I'm gonna try and present it back to you at one sentence. What I heard you say there was that Kubernetes at the container workload level gives us redundancy through horizontal scale. And then depending on your company or teams, risk appetite, at some point, you're gonna need cluster redundancy as we're maybe splitting your workloads across Split your workloads horizontally as well. Your clusters horizontally as well may be the appropriate solution. So,

29:37 yeah, I think definitely a good message in there for people listening. Oh, alright. Thanks thanks for rephrasing. That was even the right message. Thanks. My superpower is to listen to people and Thanks. See what they say back to them and, you know, hopefully make that Yeah. It is. Yeah. It Alright. Let's finish with one last question. Please feel free to take a minute to think about this one, but people who are listening to this, they're going to come away from us with two things. One, Kubernetes is scary and everyone to do this or, oh, there's a lot to

30:07 learn there. How do I get started? I'm going to do this tomorrow or tonight. Yeah. Do you have three actionable tips for anyone listening on how to improve their Kubernetes skills or even get started. Three tips. And please feel free to take a minute if you need it. On on the tree? Okay. Sorry, I've got a book here. Go. No. Problem about learning a new technology, whatever that is, is to have some sort of motivation or a case to do it. So I also struggle. I used to struggle with learning things. So for example, I want to learn, let's say

30:40 Python, but what will I be doing it? So before that, wanted to learn Perl some years ago, beginning of 2000s, but then I was like, yeah, I was reading books, but then I needed to do something with it to actually learn. I did some stuff with Python. So we had many shell scripts to connect to Oracle clusters, which was a command line tool. Scripts were getting the data, like select some things, writing to a file. Then we were gripping from file, all scripts everywhere. And then we were just doing something with those scripts. I was like,

31:18 should be doing something different. And then with Python, with the Oracle client, I was actually just like a normal programming language, getting the data, doing things there in some structures and then pointing. It was running faster. It was great, etcetera. Having a motivation, a use case to learn technology is the, I think, key point. So you set up a Kubernetes cluster. It's fairly easy on your local machine. You can just do it with minikube or kind, but then what? So yeah, running it there, it's running what there? That's also a thing. But in general, for

31:51 Kubernetes, my first recommendation is to follow Kubernetes the hard way from Kelsey Hightower. I think that will make people understand what's happening under the hood. If you like command line tools, if you like Linux and stuff, I think it's a lot of fun. But maybe it might not be so much fun if you are, let's say from Windows background or doing different things than those there. But for a new starter for Kubernetes, I think this is the really first recommendation, I would say. Kubernetes the hard way. There are a lot of online resources. I think the problem is which one is

32:31 the good quality. Your channel, for example. That's what I was going to say. So there are a lot of people doing things, but what you do is perfect. Thank you. Appreciate that. Yeah. I'll send you the check after the interview. Thanks. My Ivan number and the lulls and lowers. No. Yeah. There are a few people actually creating great content in general. I I think if you just do a little bit Google search, you'll people would will find those. Just listen and see what people are doing. That would be my second thing. And the third, I learn things by hands

33:08 on stuff. Most cloud providers give you some credits to try things out. Creditors, just get it. Even if it is a managed service, have it use it. Try to create an NGINX server there with the certificate, with the domain DNS entry, everything. So try to set up a system that actually works because yeah, in the end it won't be only about Kubernetes. You will need to get some SSR certificates maybe with sort manager, let's encrypt or you will need ingress, you will need some static IPs, you will need DNS entry somewhere. People probably can use, make use of those free

33:31 Getting Started with Kubernetes: Tips and Resources

33:47 credits and think hands on experience is hard. I know, again, goes to the motivation, but you also need to try out stuff, I think. Nice. All right. That was fantastic. I heard there was one piece of strategical advice, right? The strategy is scratch your own itch. I think a lot of people do try to learn technologies. They don't have anything at hand to apply that. And it's like learning a language. Right? If you don't go and speak to people in that language, it's not gonna get the skill. It's not gonna work. Yeah. You need to move on. So make sure you scratch

34:20 your own edge and do something. Then you gave us three pieces of tactical advice, which I also loved. One of them, go to kills high towers. Kubernetes is a hard way. If you wanna learn Kubernetes from the bottom up, fantastic resource. It's still maintained. It's still updated. Go check it out. Second piece of advice was to follow the Rawkode Academy. Appreciate that one. Thank you very much. But I also learn with other people. And this is a community effort. I'll shout out Annie East Ehrlich, Sycam, Canal, Victor Farsek, so many great channels that they're teaching DevOps,

34:51 infrastructures, code, Kubernetes. Go learn with them. It's a great way to to follow along and keep up to date. This is a volatile landscape. It changes all the time. It can be hard to keep up Yeah. That other people do the hard work for you. That's that's a great great piece of advice. And then your last piece of advice there was cloud provider credits, which I love. Right? You're right. AWS, GCP, they all offer you $300 to sign up. So just spin up a cluster and scratch your own edge, deploy an NGINX server, deploy a database, deploy a

35:18 WordPress, not WordPress because they're self employed right now. No. Apply something else. Yeah. Deploy stuff and use it. And even with that one workload, which I would never encourage anyone to put one workload on Kubernetes. But stick one thing you care about on that cluster, and I guarantee you'll then start to explore, okay, how do I make sure this is up? What do health checks look like? What does monitoring look like? It'll gauge you the path will write itself, hopefully, and have some fun. Let's not forget that. Just enjoy it while you do it. Awesome. Exactly.

35:45 That was fantastic. I really appreciate you taking the time to sit down with me today and just share your knowledge with all of the listeners. So thank you very much. Do you have any parting words before we say goodbye? I also thank you the invitation. I really had fun with the talk. Was great. Yeah, Kubernetes is there. Again, a lot of resources out there to learn. And again, it's community work, as you said. One more thing that they could join the CNCF and Kubernetes Slack channels where they could also interact with the projects like the in their channels, as well as

36:19 Kubernetes, ask questions, meet with people. That's all that would also be another maybe a bonus recommendation. Bonus stuff. Love it. Yeah. Just reach out to people. This community is quite helpful, and everyone is welcome to ask questions, get help. So be part of the community, and I'm sure people will be you and you'll get to some point quite fast. Awesome. Well, thank you again for joining me, and thank you to everyone listening. Have a great day. Thank you very much. Bye bye. Thanks for joining us. If you wanna keep up with us, consider subscribing to the podcast on your favorite podcasting

36:54 app or even go to CloudNativeCompass.fm. And if you want us to talk with someone specific or cover a specific topic, reach out to us on any social media platform. Until next time when exploring the cloud native landscape on 3. On 3. 1, 2, 3. Don't forget your compass. Forget your compass.