Today I wanted to talk about Kubernetes. This is really a topic that is due for review. I think most people are overdoing what they’re thinking about interacting with Kubernetes as a platform. I believe Kubernetes is not the container manager you’re looking for. I know that’s not the thing that most people want to consider, but I really do think it’s worth reviewing Kubernetes relative to how you actually want to use it.
Kubernetes is a tool that was basically pushed into the market through Google and I think Google did an excellent job. Please don’t misunderstand. I do think Kubernetes is a fantastic tool, but it’s a tool that is often at the center of decision processes without really considering the overall goals of an application development environment.
I am 100% behind the idea of using containers. The first thing we need to consider is that, yes, containers and containerizing your application is, with very few exceptions, the way to go these days. But containers really are a change in how we think about operating our systems environment. So from that perspective, there is just no question you have to containerize your application environment.
Containerization as a toolset is a fantastic way of ensuring consistency and operations. There are some really great benefits to containerization in terms of trying out changes and actually being able to do changes in an atomic fashion. Each element of a change can be deployed. You can have a running system using that particular element, and if something breaks, if there was a disconnect between how the processing of data actually worked within that update, you can roll back to the previous version fairly easily.
There are still some interactions that you have to consider, especially when we talk about data and interacting at the database backend level, but even with that, there are excellent tools these days for managing that lifecycle. Containers are fantastic for that, and so often what happens is that somebody starts into this idea of containers and they think, “Oh well, the tool for containers is Kubernetes, so therefore we have to use Kubernetes.” I’ve gone through this a number of times with customers where you have to really look at how your application is being built, developed, managed, architected even, and once you’ve thought through those processes, now you get to a point where you can say, “Yes, I actually understand that I need a scale-out, potentially multi-site capable environment for running my containers. Hey, this is a useful toolset. This is a useful capability, something that you should consider integrating with and leveraging.”
But it really comes down to “What is my application development environment and what are the models that I’m trying to build?” Suppose I’m part of a 500 or 1000-person developer environment. In that case, I’m most likely going to want something like Kubernetes, but in most cases, if I’m a small company, 5, 10, 15 developers even, and I’m building an application or even a set of applications that are intended to work together, the overhead of Kubernetes may be more than the value you’re going to derive from it.
Firstly, we really have to look at: are you building a megalith classic, you know, one application to rule them all, and potentially a front end of modern applications? You have the MVC style and all the variants of the model-view-controller kind of application development model. That’s all fine. You can build that as one app. You can build that as a couple of separate components. It’s classically going back 20-plus years, we would talk about the web service. We would talk about the application data services, and we would talk about the database. We all have applications that use these components in various different ways.
Actually, often the web service side is now become distributed between the browser and what you do in the browser, JavaScript, and what you do with the application. Basically, a data manipulation engine, and data storage manipulation engine are probably more accurate within the server side of your system. However, even if you understand that level of breakdown, even there, you’re still most likely looking at one container for the core of your application, potentially even your JavaScript front end, all being managed as one container, and then the database is a separate entity unto itself.
This is really common and is the core of most application development delivery, whether you’re talking to back-end APIs, for example, for managing identity, who are you? Why are you there? What users are using your system, etc.? All of those components have really good value. They still tend to end up with one container of application, a set of data storage services, and then finally, potentially an external identity toolset.
If your application falls into that sort of category, then there are a number of delivery paradigms that you have to look at. Kubernetes might be the right answer, but you may actually be better suited to serverless-style infrastructure. And if you’ve been following my channel for any period of time, you know that I think serverless is a silly name for things, but it is not a bad architecture for applications, especially if again your application can be containerized. It is really the business logic and potentially the delivery of resources like the JavaScript front end or the React front end, which is also off of JavaScript.
Basically, everything ends up compiling down to JavaScript. Or maybe now you’re doing WebAssembly. Going with the latest and greatest trends, you still end up with one application. Yes, it may still be a microservices application because my identity is by an API, my back-end data is by an API, and my third-party data source is by an API, but you’re really only managing your one component. So do you need the overhead of Kubernetes? And this is really the point of what I wanted to talk about today.
Let’s think about where Kubernetes really comes into its own: if you have an entire set of application resources you want to pull together and build against and actually deploy out to a production environment. Potentially you have lots of developers working on these different components. Those components are all separate containers that have their own lifecycle and their own scale-out deployment processes. What is your model and architecture for dealing with that?
So when you actually start getting into really complex operational questions around the containerized applications that you’ve been building, this is where Kubernetes really comes to the forefront because now you have a set of tools that are state-based, driven by an API-enabled infrastructure. You can automate the upgrade and downgrade lifecycle of those resources. You can tie into networking services components that actually support all kinds of additional scalability capabilities. It really is an amazingly powerful toolset.
But if your team of developers is really working on one or two components, and maybe the architecture and orchestrating the lifecycle of how do you deploy that component and how do you pull it back, yes, Kubernetes can absolutely do that for you, but there’s a lot of extra overhead, security policy, etc. that you have to still think about even if you use a managed Kubernetes service.
So Kubernetes is great for scale-out systems, but if you’re just deploying a basic service, even if you’re deploying three or four containers as your application, I think it’s actually worth it to go look at Google, Amazon, and Azure. Oracle now has growth in the cloud market that I think is probably worth looking at as well. If you’re overseas, there are other providers. I’m not as versed in those, but there are other cloud providers that provide either container-as-a-service, I’m going to manage the lifecycle of a container, or function-as-a-service, I’m going to manage the activity of that function. I’m going to manage the operations of your back-end processing infrastructure in a dynamic fashion, which is really the function-as-a-service world. I’ve written a function. It takes data from a web API, maybe from some back-end API services, bunches them together, and re-displays them for my customer. I manage the lifecycle of leasing messages into message service. I guess we can still call it Twitter, but maybe it’s a different one. Maybe you’re talking to Mastodon and you want to get your things scheduled. There’s a scheduling component.
We can build all these architectures. We can build all these applications. But when you think about the operations of them, you really have to think through the process of saying, “What does this really look like? How am I actually building out the application components within my system? And what am I operating this against?” So again, Kubernetes is probably not the container manager you’re looking for, and I know this is a strange thing to say here in what is it now, March of 2023 that I’m writing this, but it is something that you really have to consider.
Why are you trying to do Kubernetes? Is it because it’s the buzz and that’s what we’re all trying to learn? We think it’s going to give us great jobs in the future. That may be if you want to go work at a thousand-person company. If you are building a thousand-person company, it may make sense to do Kubernetes. Now if you’re building a company that is probably going to be acquired by somebody else, focus on your application and your application operations. You don’t always have to be thinking about how do I scale my application beyond the 500 users I have today? If you’ve containerized things, it’s the operations that will change. It’s not the application that you’ve built. And that I think is really the key.
If your application is containerized, you can run it in a number of different fashions, and the actual operational runtime can really be tuned to how your application behaves best. If you need to be online 24/7 and always able to receive a message into your application engine, then Kubernetes might be a great management platform for you because it has some very nice features for supporting that kind of functionality. If your use case is bursty, somebody shows up, they do some processing, they get a result, and maybe they walk away and get a coffee. There’s no reason to have to run that container 24/7. It just needs to be able to spin up when a resource is required. This is the container-as-process worldview, and that is why the function-as-a-service or Amazon’s Lambda is a classic example of that these days. Why that is such a powerful operational engine for you?
So look at the actual use case of your application, look at the scale of your application, look at the complexity of running your application, and with those pieces of information, you can then decide: Is Kubernetes the right container manager for you, or should you be looking at a function-as-a-service or container-as-a-service style environment?
Again, Kubernetes is not the container manager you’re looking for. I am convinced that 99% of you do not need Kubernetes, and for those of you that do, and even if you don’t need it, Kumulus is here to help you find the right solution, build out the right solution, and build the right infrastructure to support the platform solution that will provide you with the greatest value.
Want some more thought-provoking Kubernetes content? Check out my 5 Minutes of Cloud episode on why developers should stop using kubectl here: https://www.youtube.com/watch?v=hlfdlG04z8w&t=4s
Robert Starmer, Founder & CTO
Kumulus Technologies