Ep#116 Is Kubernetes, right for your company?

Host: Jon

Today we have Michael Levan, consultant trainer, and content creator joining us for our topic of Kubernetes. Yes, we're still talking about Kubernetes. Is it just another virtualization of my virtualized data center that might be virtualized in somebody else's computer? I'm not sure. But what's the value? What are the skills? What about the cost of implementing it? Is it the latest fad? Or is Kubernetes here to stay? Please join me in welcoming Michael Levant to the show. Michael, buddy, thanks for joining me.

Guest: Michael

Thanks, Jon for having me, and appreciate it.

Host: Jon

Okay, Michael, we're going to jump right into it. There is this hot topic of Kubernetes, and it's getting bigger and bigger due to the recent, obviously, cost efficiency optimization and cloud optimization that's happening in the world today. Let's talk Kubernetes.

Guest: Michael

Yeah, so to answer your question, is it virtualization on virtualization? I would say yes. You know, can have instances where you're running bare metal. You can have instances where you're running on VMs, you know, could have Kubernetes running you're on ESXi boxes. You could have Kubernetes running in the cloud. There are a bunch of different places to run it, but from a virtualization perspective, this is the key difference to think about. ESXi, hyper V, is it all these virtualization platforms? These are to virtualize your hardware. Containerization is to virtualize your operating system. So it's still virtualization happening. It's just happening at a different level or layer rather.

Host: Jon

Now, wait, because ESXi, so VMware, I'm virtualizing my hardware, ESXi is virtualizing the hardware, but I'm installing virtual operating systems, right?

Guest: Michael

Yep. Yeah, exactly. Yeah. So the whole idea about just overall virtualization, think, again, thinking about ES X I, thinking about Hyper-V, you take a server and this server maybe has, I don't know, 64 gigs, Oram, X amount of cores, storage, yadda, yadda. So what would happen back in the day was you would buy this server and you would run one application on it, one application stack on it, and you would use 20% of it. So it didn't make sense, because you were spending a ton of money. You know, we're running these things in the data center, you had your HVAC systems on to make sure everything was cool, a lot of electricity, just a lot of money going in and out in general, and a lot of boxes to manage for the kind of no reason. So that's where virtualization can come into play, where it was like, Hey, this box, we're only utilizing 20% of it.

Guest: Michael

Let's utilize all of it. Let's utilize a hundred percent of it, but at the same time, we need to segregate these resources. That's where virtualization kind of came into play. Then thinking about containerization, now, we don't care where it's running. We're just literally virtualizing the operating system, and I don't want to call it watering down the operating system, but essentially just installing the necessary things. When you're running an engine X container, when you're running, I think their node, yeah, they would be considered nodes like a bottle rocket, for example, in AWS, the or no bottle, I'm sorry, bottle Rocket is a Linux AMI, sorry, that AMI, that container that's running Engine Xs. It only has on it what it needs to run. So that's the virtualization piece of thinking about it from an operating system perspective and a smaller footprint. When you install any operating system, you're talking about gigs. When you install or run a container, you're talking about Megs or less,

Host: Jon

Why don't the operating systems run at MEGS and why do they run at gigs? Why can't I just have the necessary stuff? It's the dumbest question I have to ask because if you think about it, I would buy even a desktop or a server, and my root volume used to have to be, I don't know, a small Mountain, 10 gigs. Now my root volume for a Windows server has to be 60 gigs because of the growing expenditure. Why can't I just run what I need to get, what I need to get done?

Guest: Michael

So I mean, I think it just comes down to bloat. When you're thinking about desktops in general, when you're thinking about a Windows desktop, for example, if you look and see what's installed, there's Xbox stuff installed, there's photo stuff, install, yeah,

Host: Jon

Microsoft store,

Guest: Michael

There's this, there's that, and that's fine for the average consumer but not for the business. I would certainly hope, unless it's just a really slow week, you're not sitting and playing Xbox games on your work computer. They probably can't run anyways. Shh,

Host: Jon

You got me.

Guest: Michael

And then when you're thinking about window servers, same thing. There are so many, when you're thinking about active directory, when you're thinking about various roles and features, print servers, smb, et cetera, on a window server, there are so many different roles and features that you can install within the server manager that just causes it to grow and grow and grow. Then there is, from a Linux perspective, Linux, the distributions themselves are way smaller. You could run a bunch on a 10-gig hard drive, but that 10-gig comes from just years of kernel updates and modularization and everything. Everything's kind of there since the beginning, and that's where things like a bottle rocket and stuff come into play It. It's a Linux distro, but it's meant specifically to run containers. It's all it does, does not do anything else. Nothing else on it. So you do have these various levels of virtualization and operating systems where you can shorten the footprint a little bit and you can make it a little bit smaller. You can water it down, whatever you want to call it, but it all kind of depends on where and how you're running.

Host: Jon

Michael Kubernetes has been around for some time now, quite often. I don't even know how many years, what are we over five years now or somewhere close?

Guest: Michael

Yeah, since the end of 2015.

Host: Jon

Okay, so actually eight years. But I still feel that it's not widely adopted. It's only really kind of picked up in the last couple of years, but I'm not very familiar with many enterprises that have implemented it. They might have implemented it for their development, but are they using it for production? And why is it not picking up more at the enterprise or production level?

Guest: Michael

So I think it's very important to remember, and it's because we're all on social media, so we kind of see this every day. Sorry to everybody that's listening, but I have to say it, there's a big difference between what technical marketers are telling us and what is happening in production environments. So for me, as an independent consultant, I do things a little bit differently. Typically, you'll see independent folks either just doing a bunch of content or doing a bunch of consulting. I do both. So I have clients where I'm working in their production environments, I'm writing production level code, I'm spinning up production level Kubernetes environments, and I'm also working with the product companies, creating writing blogs for them, doing videos, white papers, et cetera, et cetera. So I see both very, very well in real-time. And what I can tell you is this, the products that are being created for Kubernetes right now, they're going to be more relevant in a couple of years.

Guest: Michael

Kubernetes itself, it's going to continue to expand. And the reason why is that what happens in real enterprise production-level environments is very different than what we're hearing on social media. This is a new thing. This is what's going to be working, et cetera, et cetera. The reality is that it takes enterprises a very long time to move off of what they're already running on. There are so many organizations that still have their own data centers, that still have fleets of ESX I boxes, and they're running perfectly fine, and they probably still have plenty of warranty left. They probably still have plenty of customer or engineering support from VMware left. Everything's running as is. So to get the enterprise to completely not only shift the way that they think, but have the engineering capacity, the people to migrate all of this stuff from VMware, put it on a container that's just step one, and then get it into your orchestration platform, whether that's Kubernetes, whether it's Nomad, whether it's, whatever it is, it, it's a very big lift, especially if you're an organization that's been around for 10, 15, 20 years, you got a lot of stuff.

Guest: Michael

Quite frankly, you also probably got a lot of tech debt, which is most likely going to stop you as well. There are a lot of manual processes that are occurring. You don't know what those are. One person in the whole organization knows what they are there. So it's not that Kubernetes isn't picking up steam. It's not that Kubernetes isn't being utilized. It's that moving from one architecture to another is not an easy thing. Now with that being said, I do work in a consulting capacity. I do work with a lot of small organizations and a lot of startups to get their environments up and running. And luckily with startups, they're starting fresh, so they get to start on all this stuff. But here's the thing, if those startups succeed and they exist in 10, or 15 years when the next new thing is out, they will have the same problem. Everybody's going to have the same problem over and over again. It's, excuses me, it's just where we are.

Host: Jon

Okay. There was a lot to unpack. The first thing is dimension is that it's taken enterprises five, or six years to maybe go to Kubernetes, and that's the same thing with the cloud, right? So the cloud's big. There's only, I think it was labeled as maybe three, we might be up to 5% of companies are moved or migrated to the cloud because it takes that amount of time. I think going to Kubernetes will, I don't want to say complicated, but will kind of revamp that decision-making process and how they plan to go to the cloud. Do we go to Kubernetes first and then in the cloud, or do we re-architect it? And those are some of the questions I want to dive into in a second. Let's talk about Kubernetes specifically and some of its components. And then my next question is, is it real? I mean, how do I repackage, and redo an application to make it to Kubernetes? I mean, it's great in theory to do, and any the skills. So what are the components of Kubernetes and what's sort of the process that I can get an application packaged into it?

Guest: Michael

So I always see stuff online that everybody kind of talks about and says, Kubernetes makes things easier and yada yada. And yes, that's true after you're in Kubernetes, but leading up to getting your workloads into Kubernetes is not a task for the fan of the heart. It's not something that you're just going to do. And cause again, going back to the technical marketing versus reality, and I hate to say it like that, but it's just kind of true. How can I put it? I'm trying to think of the best way, the tools and the process and the procedures to make it easier to get it going, to get it migrated, to move from binary Java binaries or whatever binaries running on a VM or a bunch of VMs to get them containerized, to put them into Kubernetes. There are tools and there are procedures, and there are best practices, a million of them out there.

Guest: Michael

But again, it's a matter of hiring the people, getting the right expertise, and getting your current staff trained to understand that because you're turning an orange into an apple. This isn't something where it's like, Hey, let me just take my binary and throw into a container and throw it into Kubernetes, and poof, everything's done. It doesn't work that way. There are dependencies. There are several binaries there. Is your application a microservice stack or does it have dependencies? Okay, this part of the application needs to run but to do so, the middleware needs to be there, and that means the middleware piece needs to be containerized prior, but oh wait, there's also a database that it needs to talk to. And yet there are so many different things that you kind of need to think about. And not only that but there is the, I'll call it the day zero piece, which is planning what you're doing.

Guest: Michael

Where are you running Kubernetes? What security practices do you need for your organization, for your level of compliance? A startup creating a product is going to have way different compliance and security needs than a government-regulated environment. So there are all these different things, the different tools that you're going to use. There are over 1300 tools on the CNCF landscape. You're not using all of 'em. You're not going to know all of 'em. You're maybe going to be an expert in two of them if that's, so you got to kind of figure out this whole process, like the whole planning process, and then you can start thinking about like, oh, now I need to containerize this application. Well, now I know I'm going to use Docker cloud native build packs or scaffold or whatever I'm using to create container images. So it's like, and I know just, I'm just talking and talking and talking, right?

Guest: Michael

I'm kind of babbling. But the reason why I'm doing that is that I want to make it a hundred percent clear that there are a lot of steps that you need to take. And usually, organizations aren't going to have 30 free engineers to get all this stuff done. So you got to plan accordingly because if you don't plan properly in the beginning, you will end up with a massive amount of tech debt later on. And there's also the piece, and then I'll shut up, but there's also the piece of, I can take a nail and I can hammer it into the wood with the handle part, but even though I can do it, it's not efficient. So there are a lot of environments right now that are running Kubernetes that are not running them most efficiently. And when I say most efficient way, I mean the proper procedures and protocols and best practices, and hey, you can run it this way, but everybody's running it like this. So guess what? There's going to be far more documentation support community over here versus over here. Over here is homegrown, is the enterprise. So there are just so many different things to think about when you're even debating the idea of utilizing Kubernetes,

Host: Jon

Part of the components of Kubernetes. So Kubernetes is just an orchestrator for your containers, correct? Yep, yep. And everybody says Kubernetes, can I run? I can run a single container and run an environment, but it's not efficient for development. Okay, but for production, it doesn't do anything. If something breaks, something happens, it's done. My container and my node don't handle it. I mean, talk to me about the different components of containers and how Kubernetes is managing them, and why I would take this into a production environment.

Guest: Michael

So by default, containers are meant to be looked at as ephemeral. So you should not be thinking about containers as long-running containers inside of pods. Do pods run for a month, two months, or six months? They do. Should you architect your design decisions about or around the idea of this thing is going to always run? No, because pods, and containers, they're all meant to be ephemeral. So to your point, once a container goes down, let's say I'm just running a Docker container on a server, if that thing has any issues at all, if it goes down, that's it. I have to manually go back in and rerun this thing. And that's, that's time-consuming. That's cumbersome. Nobody wants to do that. That

Host: Jon

Sounds like the old-school VMware and virtualize environment where it didn't have an auto restart feature. I had to wake up my server admin at 2:00 AM to go power on the device.

Guest: Michael

Exactly. Yeah, no, it's the same thing, a hundred percent. And that's where orchestration platforms come into play. Whether you're using Docker Swarm, whether you're using Kubernetes, whether you're using Nomad, whether you're using ecs, whatever you're using Azure container apps, G K E, gaps, what is it? Cloud Run. I think that's what it is. Regardless of what you're using, regardless of what orchestrator you're using, it, does a lot of stuff, don't get me wrong, but it has one job. Schedule my containers, schedule my pods, and make sure these things are running as they are supposed to be. Make sure that the current state is the desired state, is the current state, not the desired state. Make it the desired state. That's the whole job of an orchestrator. An orchestrator at the end of the day, like just thinking about Kubernetes, has a scheduler piece and its control plane.

Guest: Michael

That's its whole job. Its whole job is really to take containers or pods in the Kubernetes sense and run them and make sure that they're running appropriately with what they need to be able to run and where they need to run and all that stuff. But then you have different pieces of it. So for example, on the control plane, again, you got the API server. Why do you have the API server? Well, because you need a way to interact with Kubernetes. Why do you have to, which is the data store, the database, because you need a place to store all the information? Kubernetes has stuff that needs to be saved, so you need to save it all there. So, and then, you know, go into this and you go into that, and before you know it, you got this whole environment and this whole, I'll call it infrastructure, but at the end of the day, when you peel back the onion, the whole idea of an orchestrator is scheduling pods and scheduling containers.

Guest: Michael

And that's why, for example, I'll still never, well, I mean do understand it, it's just because this is just the way that the market went. But I'll never fully understand from a technical perspective why Docker Swarm didn't kick off way more than Kubernetes did. Docker Swarm is immensely easier to use than Kubernetes. I mean it, it's a night and day difference. It's so much easier to use Swarm. But here's the problem. There's no GI Ops, no, this tool, there's no that tool. People aren't building for Swarm. People aren't building right now for Nomad. So when we think about why we're using Kubernetes, really the reason why we're using Kubernetes is that that's what everybody's building for. And that's been the way that tech has been since the beginning of time. You look at ES X I versus Hyper V, they're the same thing. On Peel Back The Onion, it's the same thing. But everybody was building for VMware and because of that, I think it was VMware

Host: Jon

Won the war, the marketing value that you had, VMware versus Hyper V, right? Or Kubernetes versus Docker. Swarm Kubernetes sounds cooler. I want to build for that. In all honesty, it was the visibility of the marketing and the capability out there that probably kind of pushed some of that. Michael, let's talk a little bit about not only one of the things that the adoption and production, but here's my personal opinion. In my humble opinion, I'm a state is my disclaimer that things that engineers are now doing, they play around with Kubernetes. This is cool. I like this. Great. We're going to use it in production as the typical dev moves to a production-type model, which you really shouldn't do. But one of the things that you talked about before was that they're not building to best practices. So I played around with this in Debit works at Great has Run, and now I push it to production and not end it to best practices. Does that go with the skill sets and some of the things that you're working with and doing as a consultant?

Guest: Michael

Yeah, so here's the thing. You know mentioned earlier, Kubernetes is about eight years old to give or take. Now, if we think about the old psychology thought process of it takes 10,000 hours or 10 years to master something, nobody is a master. Nobody's an expert in the Kubernetes realm right now. Not to mention Kubernetes is constantly changing, not the core of Kubernetes, but how you're utilizing Kubernetes, the tools and the platforms and the add-ons that are being used for Kubernetes, and the different practices. So at the end of the day, I think it's going to be incredibly hard to become an expert in Kubernetes. With that being said, the reason why Kubernetes is being implemented into these environments without best practices is that here's the thing, you take a platform engineer, you take a DevOps engineer, sure, whatever you want to call it, yeah, they got to worry about Kubernetes and containerization.

Guest: Michael

They also got to worry about the 50 other things that they're working on. They got to worry about the network. They have to worry about C I C D. They have to worry about infrastructure as code. They have to worry about their automation and their scripts. They don't have the time to sit there and just be an expert or be looked at as the expert in-house in Kubernetes because of that. That's where, as you said, I kind of come in from a consulting perspective because this is what I do. I just focus on Kubernetes and containerization. It's what I do day in and day out. So it's very difficult to be an expert in something that's constantly changing. Now, with that being said, like, as I said, I focus on this a hundred percent. I focus on Kubernetes and containerization a hundred percent. I'm not an expert.

Guest: Michael

I'm always, I'm just about to add, so Mike, are you an expert in this field? I mean, because I don't think anybody can be. I am constantly always learning. I am constantly always testing and playing with new tools. I'm constantly always doing implementations. Just the other day, for example, I was working with one of my clients and I could not, for the life of me, get e k s registered and Datadog. I've done it a ton of times with a K s. I've done it a ton of times with on-prem environments. I could not get e K s working now for whatever reason with the helm chart, when you're deploying the Datadog cluster agent and node agents to your E K S environment, you have to specify in the helm chart the cluster name for whatever reason. You don't have to do that anywhere else, but you got to specify it.

Guest: Michael

And the Datadog documentation, nowhere in the documentation with the errors that I was getting states, Hey, this is what you need to do. So this was just me. I had the helm chart, the values dot YAML is like 300 lines I think, or more. And I'm just sitting there, reading through it, reading through it, reading through it, and I'm like, what could the problem be? Because everything is, it's supposedly everything is good. And I just started throwing random values in and I was like, oh, this is the one. Awesome. So point is, I do this, I do the Kubernetes in the containerization every day and things are still tripping me up. So I don't think that there's a way to be an expert in a hundred percent. What I do believe is that if you can focus on it, a hundred percent, go for it. That's what I'm doing. I enjoy it. I learn a lot. I play around with really cool technology. So that's my take on it.

Host: Jon

So everybody, real quick, I just want to give you a recap on what we're talking about and whom we're talking with. We're talking with Michael Levan, who's a consultant, trainer, and content creator. And our today's topic is Kubernetes. What is it? Another virtualization of my data center that's virtualized in somebody else's data center. The skillset sets, the cost of implementation plus is Kubernetes here to stay. Michael, you were talking about the helm chart. What is the helm chart? What is it used for?

Guest: Michael

Yeah, good question. So helm chart is, well, you can look at it in two ways. It's used to make your life easier or you, you're going to hate your life after you use them. One or two. It's one, it's

Host: Jon

One of flip a coin,

Guest: Michael

It's one or two. So the idea of a home chart is this. When let's say you're deploying an application stack, you're going to have a ton of Kubernetes manifests for your front end, for your middleware, for your backend, for just all these pieces, for your secrets, for your config maps, just for your back, just all these different various levels. So let's say by the time you're done, you got 15 Kubernetes manifests. Now you could run cube ctl, apply minus F, and all of them. Or you could use something like a helm chart. So what a chart does is essentially at a high level, it just takes all of your Kubernetes manifests and it just puts them into a package so you can deploy them all at the same time.

Host: Jon

Is that zipping 'em all up? Is that just like a zip-out, I'm going to compress this and here you go.

Guest: Michael

No, not necessarily compressed, but it can be looked at the same way. So for example, you and usually people have used helm charts in one way or another. So I use them a lot, for example, to install various tools like Datadog or Prometheus or Grafana or HashiCorp Vault or whatever. And I just have to run one command, helm install, point to the repo where the helm chart is and poof, I'm off to the races. But if you go into GitHub and if you look at the repo that helm chart is pointing to, or the helm stall rather is what chart it's pointing to, you're going to see a whole bunch of files and there you're going to see a whole bunch of templates, deployment templates, service templates are back templates, CRDs, yadda, yadda. So it kind of just takes everything that's in one place and deploys it all at the same time, versus you having to manually run, excuse me, sorry, cube CTL apply, minus F cube, ctl, create minus F, et cetera.

Host: Jon

Okay, wasn't Kubernetes once thought of, oh, this is going to be awesome. It's going to make me cloud agnostic, hardware agnostic, the portability, I'm going to be able to take it from Azure to AWS to G C P and it's not even going to matter. Is it still thought that way? And is it possible?

Guest: Michael

Yeah, so the whole idea of Kubernetes, in the beginning, was just to schedule your containers. That was it. That was the whole purpose. It wasn't meant to be what it is today with all of these different third-party tools, with all these different services, with all these GID ops and this service mesh and this yada yada. It makes things easier in a certain capacity, but at the end of the day, this was not what it was meant to do. I started using Kubernetes in 2016, and 2017, and this was not what it was meant to do. It was just meant to take my containers and manage them. That was it. But now, it's all of this stuff and because of all of this stuff doesn't make certain things easier. Sure. Does it make everything harder? Absolutely. For example, thinking, just thinking about service mesh, the whole idea of service mesh just at a high level, you know, can encrypt your traffic from a networking perspective, because networks are usually very flat.

Guest: Michael

So you're doing a lot of security for inbound and outbound, right? Egress, ingress, a lot of firewall rules, a lot of this thing can talk to that thing, et cetera. But once it's in the network, it's very flat. There's not a whole lot going on. Service mesh pretty much allows you to manage that internal flat network, make sure that everything is encrypted, and make sure EastWest traffic is happening as expected latency, making sure that you can troubleshoot all that, et cetera. That's just a high level of service mesh. Can I do all of that without a service mesh? Absolutely. Like it. Service mesh isn't, isn't inventing anything here. It's just taking a whole bunch of stuff and packaging it up into one thing. So utilizing a service mesh makes all of that stuff way easier. But guess what? Now you got to goldarn service mesh and you got to dive into linker D and IST and console connect and yadda. So it does make things easier, but at the same time, it makes things harder.

Host: Jon

You ever, there's this old movie, and I'm going to it, I don't know if I can date myself back to, I'm just probably like 20 years old by now. It was a, I want to say military comedy movie. And when it's about creating a Bradbury tank and this Bradbury tank was to go in and take forces either to the front or pull forces back, simple design. That's all it was meant to do. Then they had the bright idea, oh, wouldn't it be nice to protect our troops? So they started putting on extra weapons and everything on it to, oh, wouldn't it be nice to, if it could flow, it could drive across water. Yes. So they started doing this. Now all of a sudden they added all these components from what it originally stated, and it was bloated. Does it feel like Kubernetes is, it was just a scheduler? Now it's throwing all these extra things just like an operating system. I could have the minimal, but now I have all these extra things. Is it getting too many add-ons to it, and can I just simplify it to do what it was meant to be?

Guest: Michael

Yeah. So I believe that everything is done with good intentions. For example, let's look at WordPress. What was WordPress supposed to be in the beginning? Blogging. Now it's a content manager and these ads and this and yada yada. So WordPress is very bloated right now. WordPress is not.

Host: Jon

Oh, the plugins for that. Everything. Slow down my website. Crazy.

Guest: Michael

Exactly. So WordPress is not used today. What it was intended for however many years ago. Was it done on purpose? Was somebody sitting there and they were like, we're going to make this thing suck? No, no. Nobody was like, nobody thought that in their head they were like, we want to add this thing. A customer is asking for this feature. Oh, this would be awesome. This would make things so much easier. And before you know it, you kind of just keep stacking until you're like, what is this behemoth that we just built? And I think Kubernetes is the same thing. Nobody's building these tools and platforms and stuff to be like, let's slow this thing down and make everybody's lives more difficult. People are building it. Cause it's like, let's make things easier. And these things do make things easier. But then you take a step back and you're like, whoa, there's a lot of stuff here.

Guest: Michael

There's a lot of stuff that you got to learn. There's a lot of stuff that we got to figure out. So it's, can you use Kubernetes for what it was just intended to do? Yes. Would you benefit from it? Not as much. Let's take a very strong yet, simple example. Kubernetes Secrets. You can use Kubernetes Secrets, but here's the problem. They are stored in plain text base 64 within ETS e d. So they're not secrets. They're not fully encrypted end to end. Because of that, you typically want to use a third-party secrets manager, like Hash Corp. Vault is a very good implementation in Kubernetes. So you're utilizing this thing outside of Kubernetes, but at the same time, it's making your life better. It's making you more secure, but at the same time, it's making it harder. Because now you have something else you have to manage. And so it's he here, here's my take on it. Use what you need. Don't just go into the CNCF landscape and be like, all these 1300 tools look great. Let's just deploy 'em all. Do that. Just use what you need and walk away from everything else. And I think that that's very difficult for a lot of engineers. Because we kind of just look at stuff and we're like, Ooh, shiny, this looks great. I do it all the time. Literally every single day. I do it every day.

Host: Jon

That's what I do. Exactly,

Guest: Michael

Exactly. But then I got to take a step back and I got to be like, is this necessary? No. All right, let's walk away from it. Only use what's necessary. Exactly. And that's going back to what I was saying before. That's the day zero piece. That's the planning piece. What does this thing need? And that's it. Don't implement anything else that this thing doesn't need. So it is possible to make it as simple as it is possible, to make it as simple as possible. I don't know if that's a correct sentence, but you know, got to be smart and strategic about it. And you got to plan because before you know it, if you don't plan properly, you are going to have a ton of tech debt in six months and you're going to be like, I now got to rearchitect this entire thing. And that's never pretty either.

Host: Jon

Let's talk about tech debt. Is Kubernetes, and will it ultimately be cost-effective for me? And what are some of those cost-efficiency things that I should look out for to implement this correctly?

Guest: Michael

I don't know. I mean,

Host: Jon

I love that, man. I don't know, but it's pretty cool. Install. So

Guest: Michael

Here, here's the thing. Let's say you got 10 VMs and you're running a bunch of binaries and this and that, and then you convert them all to the container, not convert, it's not the right word, but you know, start to utilize containerization, but now you're running this managed Kubernetes service in the cloud and you got 3, 4, 5 worker nodes and these things are scaling out and this and that. So are you saving money by just moving to Kubernetes and being like, yep, we're done? I think it's less. Well, yeah, it's a good question. Never really compared the two. I think from a financial perspective, you're going to save money because of certain things. Well, just moving into the cloud in general, you don't have a data center. You don't have 20 people that you've hired to manage this data center, et cetera, and now you're kind of offloading this thing to the cloud.

Guest: Michael

But I think that's as far as it goes from a cost perspective where you're saving money in Kubernetes is understanding the fact that, for example, you don't have to have somebody set up, you don't have to have somebody on call, oh, this application went down at 2:00 AM I have to go fix it like Kubernetes is, and then the scheduler and all that. That support and self-healing are supposed to take care of all of that for you. The whole idea is to confirm that your current state is your desired state. If it's not, please do something about it. If something needs to scale at 2:00 AM Kubernetes should be able to handle that for you. If there are four pods and there are supposed to be five pods, Kubernetes should automatically be going and doing that for you. You shouldn't have to wake up at 2:00 AM to kick up the pod replicas so it doesn't save you money, but it really should be saving you time. Now does it always do that?

Host: Jon

Does cloud already do that?

Guest: Michael

Yeah, well, I mean theoretically.

Host: Jon

Yeah. Well, it's supposed to,

Guest: Michael

Yeah. Yeah. And I think that's the thing about when you think about the cloud, let's say you're just running workloads and VMs and then you're running workloads and Kubernetes. At the end of the day, from a technical perspective, it's all doing the same thing. It's just the understanding of what the next thing is. Running containers because of the small form factor versus running an entire virtual machine. That's a big difference from a size perspective, from that type of cost perspective, running a container versus having an entire VM running for an application, that's a significant cost difference. Just like buying 10 servers when realistically you only need to buy three because you can just pop s x on them, that's a significant cost benefit. But from a technical perspective, it's all doing the same thing. It's just doing it at a different layer. That's all.

Host: Jon

Okay, so besides cost, let's take cost out of it. What's my compelling reason as an enterprise to choose Kubernetes or the cloud?

Guest: Michael

Yeah, so I think it's just the smaller form factor piece. So when you're thinking about how everything kind of goes, we started at mainframes, these things were refrigerator size or bigger. We needed a smaller form factor, but the same power. So then we went to servers much smaller, same power, more power. Then we said, okay, this is pretty big. We need another smaller form factor. So then we went to virtual machines, same power applications run the same. We utilize servers very differently now, but they're more powerful or at the same power level. Then we went to containers and it was like, okay, way smaller than a VM, smaller footprint, way less to manage smaller form factor applications. Still, the same way where Kubernetes comes into play is, okay, great, this container is a smaller form factor. It costs us way less, is way easier to manage, et cetera, but we need a way to run it at scale. That's where an orchestration platform comes into play. Like Kubernetes, nomad, like a swarm. So it's not really what the debate should more be, not what Kubernetes does versus the cloud. It should be what VMs do in the cloud versus what containers do. That's the real debate. Kubernetes is just the thing that manages your containers, but the meat of it all is what's running inside of your pod, which is your application containers.

Host: Jon

The thing that manages your containers. AWS is the thing that manages your virtual servers.

Guest: Michael

Exactly. And guess what? There's all, I had a client last year that Kubernetes was a huge thing for them in a huge lift, and they decided to go with AWS CSE is doing the same thing. It's just managing your containers. Same thing as Kubernetes, managing your containers. But going back to our conversation before, not that Kubernetes is doing something drastically different than all these other orchestrators. It's that this is the thing that Kubernetes is the thing that everybody chose to be the thing to use right now. Just like

Host: Jon

Until the next thing comes along.

Guest: Michael

Exactly. Yeah. And I always think about it like that, not that Kubernetes is doing something for us way different from a technical perspective than what the ECS S does, then what Nomad does, then what cross plane does, then what Swarm did. Mesos, all of these things are doing the same thing. Kubernetes is just what was chosen. And if you look back over the years, the same thing again. Like we were talking about with virtualization, you had es xi, you had Hyper V, you, I always forget Lennox's version virtualization, it's still used and stuff, but oh man, I forget what it was called.

Host: Jon

I don't even recall it. I know, I mean, hyper V, I played around with it, but never thought it was a production-type ready thing. Always had issues going on. But

Guest: Michael

They have has their own, and you can use, I, I'm forgetting this off the top of my head anyways,

Host: Jon

Keep going. I'm going to Google it.

Guest: Michael

Yeah. Anyways, it's not that any of these platforms did anything different. They all did the same stuff. They all did the virtualization, but VMware was chosen. It was the thing that was chosen so well,

Host: Jon

It's not a distro or virtual box, is it?

Guest: Michael

No, not a virtual box. I forget. Yeah, but the

Guest: Michael

Know. Yeah, I forget.

Host: Jon

Well, there's the KVM

Guest: Michael

KVM. Thank you. That's what it is.

Host: Jon

Thank Google,

Guest: Michael

Thank Google. Wow. Yes, KVM. So there are all of these, the different platforms and they're all, they're not doing anything different. The only thing is VM VMware was chosen. That's it. That's the only difference. So underneath the hood, it's all the same thing. And the same thing with Kubernetes. Kubernetes is doing the same thing that all these other orchestrators are doing at the technical level of scheduling workloads. It is just what was chosen. And that's where I kind of come in from a training and a consulting perspective. My thing as an independent consultant and as a trainer and as a content creator, I'm not creating stuff that's the latest and greatest. I'm not pushing products on you. I'm teaching you what's being used in production right now, and from a production perspective of what's continuously growing. Kubernetes is being utilized. That's why when you look at my content and when you look at my consulting and my training and stuff, I'm not just pushing stuff out that I think is cool.

Guest: Michael

Very rarely am I creating a piece of content that's like, oh, this thing is cool and this is super popular and I'm going to get a lot of views in the yada, yada? I don't care. What I care about is creating the stuff that's going to help people use it in production. What's being used in production right now, realistically, okay, let me create content on that. Let me create training on that because that's going to help engineers with their job, all of this other flashy stuff. This isn't like what's helping them with their job right now. So that's why I focus very much on answering the questions in the way that I answer them not that the difference between Kubernetes and cloud Kubernetes is doing the same thing as everything else. It's just what's the new thing or what's the thing right now? And that thing is Kubernetes.

Host: Jon

That leads me to my next question, and I have one more after that, is some of the training and technical content that you create, what are some of the skills that are needed? Because going into the cloud, you need cloud skills. So that's another one I got to invest in. And now we want to go to Kubernetes, and now I have to invest in Kubernetes and Kubernetes on the cloud. And it's a lot to understand for one person to take this on in a short amount of time, what are the skills that are needed to run in an efficient Kubernetes environment?

Guest: Michael

So I would say you should have a solid understanding of infrastructure and systems administration, and you should also have a decent enough understanding of programming and development because you're going to see it from both angles. So for example, you can't run a production-level Kubernetes environment unless you understand networking. I don't care what anybody says, you can't do it. Because even though, let's say even you're running in a managed Kubernetes service, a K S E K S G key, whatever, you're still managing everything at the network level, not only at the host network level but at the pod network level. You're still managing firewall rules, you're still managing these network policies. You're still managing ingress and egress, you're still managing what pod can talk to, what service can talk to what you're still managing. All of this stuff ports everything. If your application code inside of your application is saying, I need to listen on 80, 80, port 80 needs to be open.

Guest: Michael

And then the question is, where does that need to be open? Who else needs to talk to port 80 80? What ingress points need to talk to 80? 80? So it's like there are all these things from a networking perspective. So networking, you need to know. You need to understand the general systems administration of operating systems. You need to understand scalability, how it all works, et cetera. And then from a development perspective, you are running applications, you're running application stacks. You need to understand how to troubleshoot applications. You need to understand how applications scale. You don't need to know how to build the next Twitter or Instagram, but you do need to understand general programming.

Host: Jon

I think everybody, I'm going to leave everybody with this, is that if you're going to work with Cloud or Kubernetes, I think the basic understanding is some of my core training came from building an actual server. I worked for an internet hosting company. We built servers, we racked and stacked on my installed os, troubleshoot connectivity, and put in some routes. And yes, I was at the dolls prompt, putting in route tables and adding all the, and I think understanding that and firewall rules are key to anything you do within a cloud environment. Yes, you're not touching it physically, but you get to understand and troubleshoot how things work and connect. And I think that's key for understanding it and just coming up with a business idea. I'm not going to drop it here because nobody's taking it. This is what happens when like mines go together. Michael, I'm going to leave everybody with this. How can people get ahold of you? Where can they connect with you and look for more of your content?

Guest: Michael

Yeah, so the best place right now is LinkedIn. So feel free to follow me over there, Michael Levan. I also have Twitter, but I'm, I'm a little bit less active on Twitter than I am on LinkedIn. And I also have a link tree that I'll send you, Jon, that you can put in the show notes that way that that's like because I just do so much stuff and I'm so all over the place that the link tree just kind of points you to wherever you need to go. But yeah, LinkedIn and Link Tree, and Michael Levan.net. Those are the three best places.

Host: Jon

Michael, I heard you got a cool website.

Guest: Michael

Yeah, exactly. Yeah. Thanks to Myer Media for a lot of really cool landing pages.

Host: Jon

Ah, Michael, you're awesome. Michael, thank you so much for joining me. I appreciate it helping us understand Kubernetes.

Guest: Michael

Sure. Thank you so much, Jon. Appreciate you having me on.

Host: Jon

All right, everybody. Michael Levan, consultant, trainer, and content creator. Our topic today was Kubernetes virtualization of the virtualization and data center layer, the cost, the efficiency, the skills, and everything that it takes to move from development to production. And now we didn't break it down step by step, but Michael can help you with that because he has in-depth knowledge and he's not a self-proclaimed expert, but in my opinion, he's close enough for it. Everybody. This has been a Jon Myer podcast. Don't forget to hit that like subscribe, end, notify, because guess what, we're out of here.