The best operating system for Kubernetes

Bart: In this episode of KubeFM, I got a chance to speak to Mircea, who when isn't playing drums in an awesome band, keeping up with his master's degree, or his full-time job, he likes to do all kinds of different technological experiments in his home lab. In 2023, he decided that it was time to migrate to Kubernetes. And he ended up not going with Ubuntu, Flatcar, or Bottlerocket. He ended up settling with Talos. So what is Talos? Talos Linux is simply Linux, but it's designed for Kubernetes. It's a minimal distro built specifically to run containers and not much else. Essentially, Talos is an operating system managed by a collection of services running within containers similar to Kubernetes itself. Before we get into the episode, I'd like to remind you that today's episode is sponsored by DigitalOcean. With DigitalOcean Kubernetes, you get a fully managed Kubernetes service, giving you an easy on-ramp to begin your Kubernetes journey. Remove the complexity of managing Kubernetes clusters, and you get to make it easy for developers to deploy and manage their applications without needing deep Kubernetes experience. DOKS, or DigitalOcean Kubernetes, is popular with developers, startups, ISVs, and growing businesses for its simplified user experience and transparent, projectable pricing. And you'll find DOKS consistently more cost-effective than the hyperscale. Get started today with a free $200 credit when you start using DigitalOcean Kubernetes at do.co/kubefm! That's do.co/kubefm to get started. Do you want to learn more about DigitalOcean Kubernetes? All right. So Mircea, welcome to KubeFM. Very nice to have you with us on the podcast. To get things started, I want to start with our first question: which three emerging Kubernetes tools are you keeping an eye on?

Mircea: Hello, at this moment I would say that the first one of them is Rancher Harvester. I've been interested in it mainly to migrate all of my virtual machines and try to get that part as well under Kubernetes. It's been going well so far. I have tried it a bit in the past but I've run into various little bugs along the way, so I haven't been able to fully move to it yet. But it's an interesting project that I'm looking forward to getting more mature and more robust. Another one that I found relatively current lately is Spegel. I think that's how you are supposed to pronounce it. Essentially, it's like a distributed cache for container images in your cluster. When one of your nodes pulls an image, it will then propagate that image to the local cache on all of the other nodes. That way, you can reduce the traffic to egress to other registries to pull down images. That sounds very interesting. Maybe Mayastor as well for a storage solution. I've seen that Rook is very popular in this Kubernetes running at home community and home labs, and it's a very mature solution. And Mayastor promises to be a bit lighter weight and a bit faster, but currently, there are some missing features. For example, we don't have snapshot support as far as I know. So that's something on my horizon as well. And I would also say that I'm excited about Cloud Native Postgres, CNPG. It's one of the tools that I've been wanting to play with for a while, but I didn't really have the chance to do that yet. That's on my horizon as well.

Bart: Very good. You have a very active mind. And once again, this is the beauty of recording. Total aside, in the past, I ran the Data on Kubernetes Community for two and a half years. And actually, MayaData that created Maya Store was one of the companies that was very much involved. As well as OpenEBS and everything related to container attached storage. So it's really nice to hear that someone's using it. Because they were acquired, MayaData was acquired by Datacore, a lot of things on some of the projects have kind of stopped a little bit, which is why you said there's some missing features. But apart from that, actually, with Cloud Native Postgres, I know the maintainers quite well. So if you'd ever like to speak, they would be delighted to speak to you. And one of them actually is a very good rock and blues guitarist. So I'm sure he'd love to talk to you about music. Anyway, that's cool though. Good. Now that we got that out of the way, just want to get more of an introduction to you. Mirta, can you tell us more about yourself? Who are you? What do you do? Where are you working?

Mircea: Yeah, sure. So, hi, I'm Mircea. I'm 23, actually 24 years old at this point in time. I'm from Bucharest, the capital of Romania, and I'm currently working as a machine learning operations engineer. I'm fairly new in this position. I've changed from a DevOps position to this MLOps role about four months ago. So, I'm still trying to see what the differences are. And I currently work at Raiffeisen Bank Romania. Basically, what I'm doing here is deploying the machine learning models that the developers are writing into our cluster, maintaining all of the applications in a healthy state, and migrating the current deployment method to GitOps as well.

Bart: Pretty good. And how did you get into cloud data, considering it's not the most common thing for someone who's 24 years old to be doing?

Mircea: So, I got into Kubernetes and cloud native in my first job, which was at Thales Services Romania. I had an internship there because in our third year of university during the summer break, we are required to have a three-month internship or something like that. I went, got some interviews, and received offers for development positions like C++ and stuff like that, which is more common for students to get. But I also managed to get an internship offering for a DevOps position, and that was something I was really passionate about. During university and also in high school, I really picked up on programming and have been using it as a hobby tool. But I don't really see myself doing it professionally. I was always much more interested in the infrastructure side, in the operations, having a home lab and all of that, so I find it's really a lot more interesting. And before that internship, I didn't really have any Kubernetes experience at all. I was running my services at home in Docker, not Kubernetes. When I got there, I had a two to three-week period where I went through some Kubernetes courses, and then they threw me at tasks and gave me assignments and things to do. And, for better or worse, I think that for me, at least, that's the best way to learn, just banging your head on a problem until you are able to figure it out. So, getting hands-on experience was really helpful for me. So I would say that's my start in Kubernetes and Cloud Native in general.

Bart: Fantastic. And I really dig your style. Like you said, don't be afraid, bang your head against it enough, and eventually it'll come down, something's going to come out of it. It's true. With that in mind, it is an ecosystem that moves very quickly. And if someone is a home lab or a hobby programmer prior to your professional experience, I just want to know what resources have been most useful for you in terms of staying, keeping track of all the things that are happening. Because like I said, things move very quickly. Is it blogs? Is it YouTube videos, podcasts?

Mircea: What works best for me, I would say, are YouTube videos. I follow certain creators on YouTube to keep up to date with new technologies and other things that are coming up.

Bart: Anyone in particular?

Mircea: I think that lately DevOps Toolkit is one I really like. Victor is great. He puts out a lot of good content. He makes very detailed and yet to the point proof of concept videos, and I really find his content to be very entertaining and very informative. I also read blog posts on random topics. I can't say I really have a certain site or blog I go to. I just read what I find. I also browse the trending page on GitHub since they implemented that dashboard that you see as soon as you login. I sometimes find cool stuff there as well. And also, one other thing that helps me stay up to date is having joined the ex Kubernetes at home, now it's called Home Operations Discord community. It's like a Discord server with a lot of people that are running Kubernetes both professionally and at home, and seeing the things that they talk about, problems, tools, solutions, and everything else in that community, it's a good way to stay up to date.

Bart: This is a question that we ask all of our guests. And in your case, you are not the youngest person to be on the podcast. You're the second youngest person. One of our other speakers brought along her daughter, who's I think about 15 years old. So that's kind of a record. But we ask this question: if you could go back in time and give your younger self any advice, what would it be?

Mircea: Honestly, there is not that much time to go back on. I've only been working for like two and a half years or something like that, but I would say that... Don't be afraid to write down things and share knowledge. It's just that we have this misconception that you're supposed to be an expert or a person of authority to be able to share things and to be useful to other people. And I would say that in my past, had I done more of that, had I written more and shared more blog posts, I think it would have been helpful overall to myself and to the community as well. There's a... This cool book I read relatively recently, I think it was called Show Your Work by Austin Kleon. And it's a short book, you can read it in a day. It essentially boils down to, you don't have to be an expert on something to be able to share your process and share your knowledge. If I am one year into my Kubernetes journey, and I share the things I'm learning and studying, maybe it won't be helpful to someone that's like, I don't know, 10 years in their career, but to someone that is just starting, it will probably be a lot more relatable. Than a blog post written by somebody that is a decade in their career. So, I think that sharing knowledge should not be an activity where we are gatekeeping based on the experience or the amount of years you have been running and working.

Bart: Certainly agree. It's because of you sharing your knowledge that we were able to find you and get in touch. So, I think it's a very good example.

Mircea: That's good.

Bart: All right. Now, to move further into our topic of discussion, in 2023, you wanted to migrate your home lab to Kubernetes. Can you walk us through what the setup was like before that transition and what it hosted?

Mircea: Prior to that, in 2023, my home lab was a lot more... Let's say simple. I had a TrueNAS server, which was my storage server. I had a Proxmox server that was hosting some VMs. What actually got me started into self-hosting services was to self-host a gaming virtual machine like Windows VM with a GPU passthrough so I can do cloud gaming. I am proud to say that I've been doing that before it was cool. So before GeForce Now and all of the other services were a thing, I had VMs going for myself and for my sister so we could game remotely. I also had a Docker VM running some services, like Plex, AdGuard Home, and all of that regular self-hosted home applications. And whenever I wanted to test something, I could create a VM, play with it, and then delete it. I had an OPNsense firewall, a DIY server that was running OPNsense, and I had a bunch of Raspberry Pis. I tried to make them into a Docker Swarm cluster at some point using GlusterFS for storage, but that was really a bad time. I never managed to get that to be stable enough. I wanted to do this migration to Kubernetes mainly because at that point, I gained enough experience to be comfortable running it at home. I've been working for one and a half years at that point. It's an experience to Kubernetes, and I wanted to get more hands-on with it because at work, I can play with it, I can deploy stuff, but you never have the same freedom you have at home. I can just destroy the cluster and bring it back up, and there's no SLA on it. So after I got my Kubernetes certifications, I wanted to gain a lot more hands-on knowledge, and that's what really prompted me to try to make this migration. And right now, I'm in the middle of getting this bare metal going. I recently got some hardware to build three servers to run Kubernetes bare metal, but I haven't gotten around to do that just yet.

Bart: Also, just a side topic, can you tell me about the Kubernetes certifications you did and what the process was like to prepare?

Mircea: I think it was in 2022, I believe, or 2021, I'm not entirely sure. I got a one-month holiday for December because I had a lot of holiday days left from my job. And I wanted to put a challenge on myself. I wanted to have three weeks to get all three Kubernetes certifications. So like one week for each of them. I used the courses from KodeKloud. I think that they are very good, at least for the certification itself. They cover the topics really well. So I went through the CKA and CKAD in one week each. And then I took the CKS as well at the end. The CKA and CKAD are relatively similar in curriculum. There's quite a bit of overlap. But for the CKS, that's definitely a different can of worms. So I also didn't have that much experience on the security aspect from work yet. So it was one of the more challenging ones. But overall, I would really recommend the courses from KodeKloud. Honestly, they have labs as well. They're just very good. Every time somebody asks me to recommend something, a learning resource on Kubernetes, I generally point them to those courses. Okay.

Bart: Back to the whole lab migration. So, what was your plan? You were thinking about doing this. How did you sit down and decide, "All right, this is what I'm going to do?"

Mircea: It was a lot of documenting what other people have done as well. I had this idea that I wanted to replace Proxmox with Harvester, as I said earlier. I played around with it, but it didn't quite work out as I expected. So that's still on hold for now. But other than that, I wanted to migrate all of the containers and the services that I was running in Docker to Kubernetes. I had a bunch of Raspberry Pis and other single board computers laying around that I was planning to use as my actual cluster, but I was a bit let down when I realized some of them were ARM 32-bit, not 64-bit, and there's not a lot of support for that in Kubernetes and in the other container images that you would want to deploy. So that really didn't work out as well. So I decided to use the Raspberry Pis only for the cluster initially, because there are a lot of people who are running Raspberry Pi clusters at home. But I relatively quickly found out that they are rather restricted when it comes to resources. I have the 4GB model and that wasn't really enough to get things going on properly. So I ultimately moved on to hosting VMs for my Kubernetes nodes under Proxmox because I couldn't get Harvester to run properly. And yeah, initially I was going to run Ubuntu with K3s on it, but during my tests, I always found that to be a little too clumsy for my taste, a little too laborious, too much work to get things going properly. And I don't know about you, but personally, when I have, even for my desktop, if I have Ubuntu or Windows or whatever installed for too long, after a while it starts feeling a bit cluttered and messy. I'm not sure anymore what exactly is there, what is configured, what is not configured. Sure, you can have automation or Ansible or whatever to set things up, but it's never going to be like a perfectly clean, what you have in your configuration is one-to-one to exactly what you have in the server, because you will at some point get some manual action done to fix a problem that you will not document or not implement in your configuration. Got it.

Bart: And with these different options in mind, what did you eventually settle on?

Mircea: I actually came across Talos Linux not that long ago, I think it was in the middle of last year, and I ended up going with Talos. It's an immutable operating system, so we don't have the problem of changing things manually in the OS and then not knowing what has been changed after a while. It's essentially just enough Linux to get Kubernetes going. It's a very minimal operating system. You don't have things like shell or SSH because you don't actually need them to run Kubernetes. It's just what you need to get Kubernetes going and not much more. One of my favorite features, which really pushed me over the edge to use Talos Linux, was the configuration. We have a single YAML file in which you can put all of the configuration for your OS and everything else. And then you apply that to the OS. When you boot Talos, you apply the configuration file, and then it automatically sorts itself out. It also comes with Kubernetes built in. So, bootstrapping the Kubernetes cluster after the OS is up and running is again very simple. It's a single command, and you're good to go. So, overall, it simplified the process a lot. And at least for the initial learning period, being able to just delete the cluster, recreate it, apply the config again, and get this going very quickly was helpful. I think I had days where I deleted and restored the cluster like 10 times or something like that.

Bart: All right. For the sake of playing devil's advocate, can you walk us through why or how this would be better than just installing Ubuntu and executing kubeadm? What's the advantage here?

Mircea: I would say that a good comparison is similar to what we're doing for containers. I think that for container images, we have reached a common consensus that using Ubuntu as the base image for your container is not necessarily the best idea. Maybe you should go for Alpine or even Scratch if possible. And I find it somehow interesting that we don't have the same mindset when we're talking about the OS itself, because at the end of the day, you don't want to deploy an Ubuntu server in your infrastructure. You want to deploy a Kubernetes cluster. There is no business value by it being Ubuntu instead of something else. So the quicker you can get from nothing to Kubernetes, I think, the better. Also, running Talos instead of Ubuntu just removes the need to manage and configure the OS that much because you have the configuration file. If something is wrong, you can just reset the node, bring it back, and it's all done. So I would say that it's much simpler, it is arguably more secure because it's a smaller image. Just like in Ubuntu, in the container image of Ubuntu, you have a lot of utilities you don't need compared to Alpine. Same thing here. You don't really need to worry about the OS. You don't need to SSH into it to edit things. You have the configuration, it's applied, it's there. That's it.

Bart: And as someone with a certification in security, would you say Ubuntu is not secure enough? Is there a problem there?

Mircea: The first thing here is to define what you mean by secure enough because, at the end of the day, given enough time and resources invested, you can make the OS as secure as you want it to. You can remove things until you get all that you need. But the idea is, again, that this is a pre-built solution, so you don't have to spend the time and the effort to do that. It's a much smaller image, I would say. So again, you don't have SSH at all. You interact with the OS via an API. So it's a reduced attack surface because if someone were to break into your server and get SSH access, then they could have access to all of the utilities that are installed on the system. Utilities that in production, as far as Kubernetes is concerned, you don't really need. But if somebody were to break, let's say the API server and get access to execute commands, then there's a smaller subset of actions that they can actually do. So assuming that both were to be compromised, there's actually a smaller set of actions that you can take on Talos compared to Ubuntu, for example. So that's one way to look at it.

Bart: Okay. You ended up finally settling on Talos, but did you consider other operating systems such as Bottlerocket or Flatcar?

Mircea: Yes, I've actually considered them a bit, but I ultimately ended up going with Talos for a few reasons. For Bottlerocket, it's actually that their documentation mainly focuses on deploying it on Amazon, on AWS, and that was making a bigger barrier to entry. So that was not ideal for just getting started, having no experience on this kind of immutable container optimized OS. And as far as Flatcar goes, in the documentation again, I noticed that the process to get Kubernetes up and running is a bit more cumbersome. You have to do a lot more configuration. Whereas with Talos, I think it's as easy as it gets. Mainly, you have the configuration file, you put mainly the default stuff, you don't have to customize anything too much to get up and running, and then you just run talosctl bootstrap because it comes with Kubernetes built in. For Flatcar, I think you have to do some configuration in order to download the binaries you need for Kubernetes, whereas Talos comes with them by default. I would say that the difference here is that Flatcar is a container optimized, purpose-built OS. So it's meant to run containers, not necessarily Kubernetes, but it can also do Kubernetes. Whereas Talos is really built for Kubernetes. It can run containers by itself, but it has to be inside the Kubernetes cluster.

Bart: And back in November, you published an article, The Best OS. Right around that time, Kubernetes 1.29 was released. And later on in February, Kubernetes 1.29 was released. Did you update the cluster? And if so, how difficult was it?

Mircea: No, actually. So I didn't go through the upgrade process, mainly because, as I mentioned, I got some hardware to build the server. So I knew I was going to go from virtual machines to bare metal, so I didn't bother to upgrade the virtual machine cluster. I did play around with upgrades, but it was in a learning environment. So we had a really small cluster deployed, no actual workloads or anything, just the Talos and then the upgrade. And the process itself is fairly straightforward. We have a talosctl command, you tell it what Kubernetes version you want to go to, and then it will just do it. And to compare it to kubeadm, the experience I have with upgrading kubeadm is still from the CKA certification I mentioned. So I would say it's still easier because for kubeadm, for example, if I remember correctly, you have to log in to each node to update the kubelet, you have to upgrade the kubeadm utility and then you have to do the upgrade plan and apply commands. Whereas for Talos, you just point it to a node, tell it to upgrade, it will automatically drain the node, update the OS, uncoordinate the node to bring the workloads back, and then you can go into the other node as well.

Bart: All right. Now, in terms of network plugins, did you have any particular choice that you'd like to share? We had a previous guest on the podcast, Mathias, who had a home lab like yours and settled on Cilium. Was your case similar?

Mircea: I also went with Cilium for my home cluster. I can't really say I have a strong reason for that. In my home environment, I'm not yet running any network policies, so it's all open. So I would honestly be fine with Flannel as well. But I chose Cilium mainly because it has the Hubble UI as well. So when I eventually get to implementing the network policies, I will be able to use it to visualize the traffic flow in the cluster. It's also what the Talos team recommends in their official documentation. They have a section for CNI and they recommend using Cilium. And a lot of people in the Kubernetes at home community are also running Cilium. So it's helpful to have example configurations and deployments. At work, I think we're using Calico, if I remember correctly, but I wasn't there when this decision was made, so I can't really go through the logic process behind it. Yeah, they're both great tools. I doubt you will have many problems with going with one or the other. At work, we don't have any complex network policies going on, so it's just the stuff that's by default in Kubernetes. So we would realistically be fine with any of the two. I would say that Cilium is, at least as far as I know, more feature-rich. You can also use it as an ingress controller, if I remember correctly. It can also function as a load balancer to replace Metal LB. And the Hubble UI as well is a big plus, in my opinion.

Bart: We often ask some of our guests this question: what's easier, learning how to manage network policies on Kubernetes or learning how to surf?

Mircea: As somebody who doesn't live by the seaside...

Bart: I was just going to say, there's a long line of Romanian surfers you have to live up to, so be careful.

Mircea: I think the bar is really low in my case, for surfing, but I would still say surfing. I think network policies are really the one thing you can make as complex as you want to. You can shoot yourself in the foot with complexity if you're not careful.

Bart: So what's the next step after installing Talos? Walk us through that.

Mircea: Well, it depends if you're talking about the OS level, I would say that the next step would be to get some tool to encrypt the sensitive data in your Talos configuration, something like sops and AGE, and then push it to Git to get your infrastructure repository going. There are also utility tools like TalHelper, which is built actually by a member of the Kubernetes at Home community. And it helps you manage this Talos configuration and get that into Git and get your infrastructure monorepo going. I am currently working on a video and a blog post as well on using these tools. So hopefully stay around for that. But if we're talking about Kubernetes. Then once you deploy Talos, there are a few steps. You need to get a networking solution going because otherwise your nodes won't be in a ready state. So you can't deploy pods on your cluster. You probably have to deploy some sort of ingress controller to be able to expose services, get a storage solution going for stateful applications, maybe Cert-Manager for TLS. But overall, I would say that the way I would recommend to do all that is to use some sort of GitOps tool. Personally, I'm a fan of FluxCD and that's what I would use to deploy all of the services. Thanks. Okay, and just once again to play devil's advocate, why Flux and not Argo CD? I can't really say I have a strong reason for that one. I mainly got started with Flux because the consensus I found online when researching between the two was that ArgoCD is more intended for developers, so deploying applications, and Flux is more intended for the platform side, for the infrastructure aspect. So I got started with Flux, learning GitOps, and it was enough for me, so I didn't look into Argo CD yet. I'm fairly new in the GitOps scene. I deployed my Flux on my cluster about eight months ago or something like that.

Bart: So. Which to a 24-year-old must feel like eight years. Don't worry, it's fine. Okay, but with that in mind, regardless of the GitOps tool of choice, whether it's Flux or Argo, can it be used to create more nodes in a Talos cluster?

Mircea: Well, directly, no. You still have to provision the hardware somehow. So you may use cluster API or crossplane to provision some VMs and then push your configuration to them. But essentially, the Talos team provides cloud-specific images, so you can use those and then push your config to them. And it's a matter of grabbing a cup of coffee and then coming back to the node joining the cluster. It should be that simple. They also have another product, I think it's called Omni, which is like a SaaS solution to manage your Talos clusters. You boot your Talos OS with the specific configuration to link back to Omni, and then you have a UI in which you can create and manage the nodes in your cluster.

Bart: This has been a fair amount of work that you've been putting into this process. Are you satisfied with your progress, or is there anything that you think you could have done differently knowing what you know now?

Mircea: I would say I'm pretty satisfied with the process, honestly. I think I've made a decent amount of progress, especially since I've got my cluster at home going. As for something I would change, I would say to deploy Kubernetes in my home much sooner. I think that sure, I made a lot of progress going from nothing to something in terms of Kubernetes experience and knowledge when I got my job and I started learning there. But I think that my progress really skyrocketed once I got Kubernetes going at home and playing around with random stuff. Again, you have a lot more freedom and a lot more flexibility when you have your own cluster in your home lab than you have at work. And also, one thing that I found very useful when going for the Kubernetes at home option is that I have to go from the minimal cluster to something working because at work, for example, at my first job, when I got in, it was an already established team with a lot of DevOps people in there. And the cluster was already up. We already had networking. We already had a Cert-Manager. We already had a lot of things deployed and automated. So I didn't get that much hands-on experience working with them as much as I would run pipelines or deploy Helm charts and stuff that were already made. So going with the at-home cluster option, you certainly get a lot more experience a lot quicker.

Bart: And now, given the experience that you have with Kubernetes optimized OS, how would you convince your earlier self to switch over sooner?

Mircea: I would say that it's a much cleaner and quicker option. I would redeploy the cluster a lot initially because I would break things or maybe I would reach a point where I finalized the lab or proof of concept that I was going for, and then I would have to restart and go for something else. And I think that for an immutable and container-optimized OS like we have with Talos, it's much easier to do that. You have the utility that interacts with their API, and you can just use the command to reset the operating system back to a blank state. So that would allow me to move much quicker in just deploying the cluster, doing what I have to do, ripping it out, and then doing it all over again. I think doing that with Ubuntu, for example, would be much more time-consuming.

Bart: You're doing all this in your free time. How does one manage? This is a significant amount of time. There's also some money in terms of acquiring the resources that you have, the physical hardware, things like that. This is tricky for a lot of people. How do you organize yourself in a way that you're able to dedicate the time that's necessary to make the progress that you make?

Mircea: With great difficulty. In terms of time, it's pretty tough. I have my full-time job. I'm also a student, working for my master's degree. I also have the drums, as you see. I practice with my band and have a social life as well. So, I find it hard to get the time I would really like to allocate to this. You can see that my last video and blog post was like three months ago because life got in the way, and I didn't manage to get things done as quickly as I wanted to. But I think time management is really something I'm currently working on improving. So, I'm struggling with that a bit. But it's a matter of prioritization, I guess.

Bart: Getting the time to focus on time management. It's not as easy to be looking at to an outsider. That's good, though. Beyond this as well, speaking of time that you dedicated, I know you said that you haven't written for a couple of months, but still been working on other things. You not only wrote multiple articles about your journey but also decided to record a video sharing your thoughts and demoed the entire process. What was the response from the community? What did people point out? What was the feedback that you got? What's it like being a creator in the cloud native space?

Mircea: So, the response and the feedback I got was really amazing. I didn't expect that. I started this blog post and YouTube channel with honestly little to no expectations. I expected that the first 50 videos or something wouldn't even get many views, but I was actually very pleasantly surprised to see that there were people actually finding it useful, commenting, saying that they found the video helpful and learned something new, which is just great. That's what I'm looking for. I'm trying to make the content that I myself would have liked to see from somebody else. So getting such a good response is honestly amazing. I didn't expect it. So, I don't know if I would consider myself a creator yet.

Bart: I've made only like three videos and wrote a bunch of blog posts, but I'm working towards it. I guess I would say the first video you make is probably the hardest one you'll ever do. Taking that step, you have to watch yourself many times when you're editing it, which was an absolutely awful experience for me. I don't know if it's for other people, but I find that to be very challenging. But it got to the point that it got you to, and also I think some people might start with the wrong mindset of thinking, "I'm gonna make three videos and get rich." Probably not. And also... You may get feedback sometimes from people that might give it in a way that they're not trying to hurt your feelings, but they might say something like, "Well, I spent a lot of time doing this." I didn't expect something to be so negative. There are a lot of different things that get involved there, but you have made it to this point, and we're interviewing you because of the content you created. So congratulations on all your hard work.

Mircea: Thank you.

Bart: I really mean it. It's no joke. Where do you want this experiment to take you next? What's on your roadmap? Can we expect more videos? Is this something you want to explore further?

Mircea: Absolutely, you can expect more videos and blog posts. I think the feedback I got, the good feedback I received, is really motivating me to do more of this, which I already wanted to do, and now I have the validation of the community, I guess. So, my roadmap is to find a way to make creating content fit more into the process and having it be as seamless and as friction-free as possible. Currently, it's been a while since my last video because I'm trying to see if batching them would be more efficient. So, creating maybe three videos and posts at a time instead of just one is something I'm experimenting with. So, definitely, you can expect more content. Hopefully not in another three months, hopefully sooner.

Bart: Well, looking forward to it whenever it comes out. It's not a question of if, but when. You mentioned the drums. Can you tell us more about when you started playing and what kind of music you play?

Mircea: I think I started playing in middle school. I was in sixth grade or something like that. We had a music school in Bucharest that I went to. It was mainly for rock music. I got to know some of the other kids there from the band, and I'm actually in the same band since I was in eighth grade, I think. We made some friends, formed a band, and we were playing together. As far as what we're playing, it's melodic metal, I guess. It's more aggressive music, but with clean vocals. We have a girl singing. And that's it. We're playing, mainly have played local shows, but since the pandemic, a little bit less. We took a break from performing because they are also in the same age as me. So they just finished their medical degree. I finished my engineering degree. I'm studying for my master's. So, we've been a bit busy.

Bart: It looks like it. And with a home lab at the same time. Other things about you that maybe we can speak about include your apparent liking for iced lattes. Tell me about that.

Mircea: In the summer, especially, I like to start my day with an iced coffee. I'm maybe drinking much more coffee than I should, but I really like coffee.

Bart: Enjoy it while you're young. Other things as well, too. You're also into fitness. Tell me more about that. What kind of exercise do you do?

Mircea: I'm going to the gym. I started going to the gym in high school, in 10th grade or so. I've been going ever since, made some friends, and we go to the gym together. It's just about staying active. I feel like if I sit on the chair too much, my back starts hurting, and it's not healthy, especially for us engineers, people who sit in a chair for way too long, more than we should. I think it's important to also stay active and have a hobby in the fitness area.

Bart: Completely agree. And I think there's something out there for everybody. You don't have to do rock climbing or martial arts or whatever. You just find something that works for you, make sure that it's scheduled in to get that break away from your chair, and to be active doing something. It can also be social, as you said as well.

Mircea: Good. Absolutely.

Bart: So, we've covered a lot. We've got your home lab. We've got content that we'll be seeing. Is there anything for people that want to get in touch with you? What's the best way to do so?

Mircea: The best way to get in touch with me would be through LinkedIn or via email. You can also find me in the Home Operations Discord community. It used to be called Kubernetes at home, now it's Home Operations. That's where you can find me. LinkedIn would be the quickest way to get a response. Perfect.

Bart: Well, Mircea, thank you very much for joining us today and looking forward to future conversations with you. Whether it's about your home lab, your band, or the kind of exercise you're doing, really enjoyed having you on with us. And best of luck to you with all of your different projects.

Mircea: Thank you so much for having me. And best of luck to you as well.

Bart: All right. Thank you very much. Cheers.