Recently, Jeff (that’s Jeff Meyerson, not Jeff-as-a-serverless-replacement) hosted a show with me on his podcast, Software Engineering Daily. Towards the end of the show, there was a question about comparing Kubernetes and “serverless” that caught me a bit off guard. I think the answer could have been a lot clearer, so here’s a text version that’s had a bit more thought put into it.
First, let’s cover the definition of “serverless” I’m using here. It comes down to the use of SaaS (like Algolia, Auth0, etc) in combination with cloud functions (Functions-as-a-Service like Lambda) to build applications that don’t require that you run your own infrastructure, and can outsource all hardware/environment management to service providers.
Kubernetes is an open source project from Google to handle infrastructure-layer concerns of scheduling containers or groups of containers (pods) for many different applications/workloads. Fundamentally, both of these are designed to ease the gap between writing an application and scaling it to meet production-level traffic and reliability demands. They aren’t really competitors in a direct sense, since the model of Kubernetes is to manage long-running containers, and serverless is all about short, on-demand tasks.
Special thanks to ServerlessCode sponsor Trek10, experts in supporting high-scale serverless and event-driven applications.
Of course, you could host a “serverless” application on Kubernetes by running something like OpenWhisk on it that would provide the event triggers and scheduling for your functions. As a normal user this may not make sense, since you take on more management work, and lose the cost savings you can get from cloud functions by not paying for idle time. Because you’re not outsourcing the hardware and environment, I wouldn’t consider it Serverless - just on-premesis Function-as-a-Service.
Could it make sense in some cases, sure. But I wouldn’t categorize them as competitors.