The Pros and Cons of Kubernetes

Myles Brown: ExitCertified is a training company that provides technical training from a lot of different vendors, cloud vendors like AWS and Microsoft Azure, Google Cloud, and Oracle Cloud. And we offer cloud-related training for different kinds of workloads that people run in the cloud like containers and Kubernetes. I have with me, Mike Stapleton, and maybe Mike you could talk a little bit about what you do.

Mike Stapleton: I've been teaching since 1999 and working in the IT industry since before then. I have taught system administration development throughout the years. Currently, I'm focusing on Kubernetes, cloud services, and Identity & Access Management. I have my fingers in a little bit of everything.

Myles Brown: Excellent, well, Kubernetes is what I want to talk about a little bit today. I'll ask you a few questions. Maybe you could tell me some things. I know a little bit about containers and Kubernetes. But I think people would want to know, you know, some of the things that we see because we teach courses for a lot of different vendors, which provides the ability for us to give a vendor-agnostic view of things. Because we are partnered with all the main vendors, we teach their authorized training. But we also can see through the cracks among the vendors. So, I want to talk about containers and (the pros and cons of) Kubernetes. These days there's such a push that you see IT departments in enterprises saying, “Hey, this is the way to go; everything's going to be Kubernetes down the road.” And I get the sense that that's not always the case. I've talked to some customers who started down this road and then came back and said, “We don't need that complexity. We have simple web apps that don't scale like crazy and aren't very complex.” So maybe you could talk about where Kubernetes and containers in general are appropriate and when they aren’t.

Mike Stapleton: Yeah, Kubernetes is kind of like the conversation around a monolithic application, right? We start off with the monolith, and some people say it’s this awful thing that you should never use. No, a monolith is not this horrible application. This is technology, and what you use depends on your requirements. Right? So, the thing about Kubernetes is it helps solve problems with networking, storage, service discovery, and scheduling for complex applications. Companies using Kubernetes usually use distributed applications across many, many servers. If that's not what you're doing (using distributed apps across many servers), Kubernetes, which is extremely complex, might not be right for you. On the other hand, if you have this whole complex application (composed of many distributed applications), and you want it to be web-scale, you're going to have all kinds of networking problems you need to solve. You're going to have to solve them one way or another—with or without Kubernetes—and it's a lot easier with Kubernetes. (Web-scale is the way data centers and software architectures are designed to incorporate multi-dimensional concepts such as scalability, consistency, tolerance, and versioning.) But Kubernetes isn’t easy. It's a complex thing. I just want to add one more thing here. When I used to teach Enterprise Java, you remember that for Sun Microsystems, they said Enterprise Java doesn't make enterprise development easy—it just makes it tractable, or manageable. But without Java Enterprise Edition, building some of those apps would have been near impossible. So that's kind of the same thing with Kubernetes. It's an awesome tool, but only if you need it.

Myles Brown: So that complexity that Kubernetes does bring, you know, I'm familiar with the cloud vendors, and each of them seems to have a service to help with the complexity of Kubernetes. For example, Amazon Elastic Kubernetes Service (EKS) in AWS. Maybe you can tell us a little bit about some of the things cloud vendors can do for you with Kubernetes. And tell us why we would love that or maybe why would we avoid it.

Mike Stapleton: Well, there are two parts when you're dealing with Kubernetes. There's the Kubernetes cluster and the Kubernetes software. It is a thing itself that you have to build and maintain. And then once you have Kubernetes, you have to deploy your application and services and everything in it. Both can be fairly complex, probably deploying your app is the most complex part, but at least with a cloud vendor, you outsource the system administration of the cluster itself. You're not responsible for doing the backups of all of the Kubernetes data. You're still responsible for your data (your applications), but at least the configuration and everything in the cluster are taken care of by the vendor. They (cloud service providers) can also make it easy to scale. And they'll also integrate it with their own services for logging purposes and things like that. Whereas if you were to install Kubernetes raw yourself, you’d have to figure out your own logging and your integration with Identity and Access Management solutions. Kubernetes doesn't have a whole lot of opinions about anything. You got to figure all that out. When you go to a cloud vendor to handle the system administration, with just a couple of clicks, you get a cluster. Then you just deploy your application on it. That's a big deal (that you can do that so simply). You want to do that (use a cloud service provider to administer Kubernetes) if you can.

Myles Brown: That sounds like a bit of a double-edged sword. The cloud vendor will make your life easier, but that will also very much tie you to that cloud vendor.

Mike Stapleton: That is exactly it, right? With everything, there's a cost-benefit analysis kind of thing you have to do. With the cloud vendor, it's plug-and-play, but then you're also handcuffed. I don't know about you, but sometimes I just want to go to the raw logs. I was working recently on a cluster on Google, and I wanted to look at some of the Kubernetes logs. And I was just fighting with Google's logging system trying to get basic logs I would have found in two minutes had Kubernetes not been integrated with Google’s logging. Yeah, it's nice that it's (the Kubernetes logs) are integrated with their (the cloud vendor’s) logging. But it's bad it's integrated with their logging; you lose some control.

Myles Brown: And I imagine if you are in a multicloud situation or a hybrid cloud where you have some Kubernetes workloads running on-premises in your own clusters and some running in the cloud, having to manage the two different types of clusters, different ways, probably just gets in the way at some point.

Mike Stapleton: You are always trying to find the simplest solution for sure: consistency. That was the whole point of containers. I always find it interesting when people talk about containers and say, “I can pack more stuff into a server.” No (you can’t pack more stuff into a server). Containerization decouples your development environment from your runtime environment in Prod. Containers provide a consistent environment for your app, no matter where they run. In the past, some developers would use Ubuntu Desktop for development, test, and production environments. So, in Ops, you'd have different operating systems. Containerization allows you to standardize, so now you just have a whole bunch of servers, and it's so much easier to automate and manage when there’s consistency in your cluster technology.

Myles Brown: Some of our clients want to work in either hybrid or multicloud environments with their container applications and want help with that. So, they turn to a product like OpenShift. You know, we are partnered with Red Hat. We do training on Red Hat OpenShift. I know that it is built around Kubernetes. So what does that bring to the table?

Mike Stapleton: Well, it's built on top of Kubernetes and there are a number of platforms built on top of Kubernetes. The thing about Kubernetes is that people often say, “It's a platform.” But I don’t think that’s entirely accurate. I really find it to be more of a framework because you start off with a Kubernetes cluster and if you're doing it raw, like from the base, then it doesn't need to have a default logging system. It doesn't have a default way of networking. It doesn't have any integration with identity access management. It doesn't have any CI/CD pipelines. It has no default way of doing anything. So, you have to do it yourself, which is good and bad. If you know exactly what you want, you've got the expertise, you can turn Kubernetes into exactly what you need. On the other hand, if you don't have the expertise, you may not have that much expertise or you just want something like logging and integration with Identity & Access Management, that's where these other things give you a layer on top of Kubernetes. You get some opinions added to it. When you use something like OpenShift, it has opinions about how you should do things, how your development team should work, how you do the CI/CD pipeline, and how security works—Kubernetes out of the box is not secure. You’ve got to do work to make sure it’s secure. So, if you just run Kubernetes, you're responsible for that security. When you use OpenShift, they have opinions on security, which are good opinions, and you don't have to worry about security as long as you agree with their opinions. 

Myles Brown: Again, there's a bunch of tradeoffs because there's going to be some extra cost. Also, if you're not happy with those opinions (you’ll have to do even more work to override their choices).

Mike Stapleton: Well, we've all worked with people who we get along well with. You agree with their opinions so much that you barely have to talk to each other. Similarly, if OpenShift works the way you think it should, working with the platform is easy. But on the other hand, we've all worked with those co-workers where you don't quite share the same opinions. That causes conflict because you want to do it differently. They want to do it a different way than you do. And yeah, the more you need to do something a little different to differentiate yourself, the harder it is. It becomes an obstacle. So, it's give and take. 

Myles Brown: You mentioned that OpenShift is just one of these sorts of platforms on top of Kubernetes. Do you have any other examples? Like, is Rancher one of those? I've heard a little bit about that. Rancher is a complete software stack for teams adopting containers. 

Mike Stapleton: Yeah, it's a good example. 

Myles Brown: Yeah. Because I think we've had some customers doing some work for the Department of Defense, or something like that. And our customers’ clients had very specific security requirements and were able to meet those requirements by using Rancher, whereas maybe they couldn't meet those requirements with EKS in their AWS environment. 

Mike Stapleton: Well, that's actually a good point security-wise, right? You have to have something that's certified as secure. And if you just do your own thing to lock it down, that won’t work because it hasn't been certified. So having a layer on top of Kubernetes like OpenShift or Rancher that's been pre-approved is important. 

Myles Brown: Well, then, I think that's probably all the questions for you today. I just wanted to get a better feel for when you might use Kubernetes and what things you need to consider when you use it.

Mike Stapleton: Use Kubernetes for complex, distributed applications to help you with your storage, networking, and integration with DevOps. Kubernetes acts like a platform in that if you develop your software to work in Kubernetes, anywhere you have a Kubernetes cluster, you can run your apps, so you're not tied to a vendor.