Serverless vs. Kubernetes: The People’s Vote
Which architecture is better in terms of scaling, cost, and security — Kubernetes or serverless?
A breakout session at Amazon Web Services‘ recent Re:Invent conference, “Competition of the modern workloads: Serverless vs. Kubernetes on AWS” was a six-point comparison of serverless vs. Kubernetes to finally determine which architecture was better, presented by Niv Yungelson, DevOps leader at payment provider Melio and Shimon Tolts, co-founder and CEO of Datree, which provides configuration software for Kubernetes.
The categories covered everything from maintainability to logging and everything in between. Each attendee had the chance to cast their vote at the end of each round via a hand raise, a live action pros and cons if you will.
Tolts, on the Kubernetes side, credentialed himself as a committer and maintainer for numerous large-scale applications that use Kubernetes has seen the good, bad, and once in a lifetime. In terms of relatability, he knows the tradeoffs and how to work within the gray area.
Yungelson was the first DevOps engineer at Melio and now leads the serverless team for the company. She believes serverless is farther down the innovation scale. First, there was on-premises then everyone moved to the cloud but with the same mindset as on-prem: infrastructure first then build out based on needs. Then serverless came along and flipped everything on its head by first starting with the need-then-build-out.
Category 0 – Maintainability
To kick things off, Yungelson quoted Werner Vogels (AWS chief technology officer): “No server is easier to manage than no server.” Kubernetes on the other hand requires a lot of maintenance — regular updates and the occasional random production-level code depreciation.
AWS does help with Kubernetes maintainability with Amazon’s Elastic Kubernetes Service (EKS), which offer conveniences such as auto version upgrades.
It’s no surprise that the audience favored serverless by a landslide.
Category 1 – Cost
How do we buy this? How do we pay for this?
The Kubernetes tradeoff came down to cluster optimization. Build optimized clusters with the correct ratios of I/O, compute, and memory-intensive workloads. That comes at a high development cost. Are the savings with the potential development cost? Only the specific organization can make that determination.
“Who has a DevOps position they can’t fill?” was Yungelson’s response. A lot of attendees raised their hands. That’s not to say that a serverless architecture isn’t a challenge but the engineering specialty is elsewhere.
There are two more things to consider. Reliability. Kubernetes is reliable. Large traffic spikes don’t affect the cost and the workload doesn’t have to be estimated or forecasted as precisely as it does with serverless as serverless costs can grow quickly.
A major pro for serverless is that the only services paid for are services used which is not the case for Kubernetes.
The raised hands were evenly split in numbers.
Category 2 – Scalability
Kubernetes and serverless were designed with scaling in mind but function differently. It really came down to serverless’ quotas vs the high amount of babysitting needed for Kubernetes. To the cons, Tolts admitted that scaling Kubernetes was more complicated than scaling serverless but not without also adding that AWS does offer autoscaling. It does exist.
In order to work comfortably within the quota system, Melio created multiple accounts (ie staging, production, etc) because AWS doesn’t allow scaling over hard limits but they do have friendly options.
The audience was still didn’t completely buy into serverless. Tie.
Category 3 – Developer Friendly
Neither are easy but with Kubernetes, once someone understands the technology, they understand how to work with it. High bar to enter but only have to enter once since Kubernetes as a single API across runtimes. The challenge lies in orchestrating a large environment.
Serverless had a longer list of cons but they can be categorized as being vendor specific. Each vendor has their own tech, their own rules, and everything that goes along with that. In Melio’s case specifically, developers need to understand the limitations of AWS Lambda, and it’s harder to work on the same resources (emulators aren’t exactly the same).
Melio’s solution is private accounts. Rather than have each developer work off a main account and troubleshoot different environments, everyone has their own AWS account and connects to the main account with a script and short feedback loop. Rather than deploying an entire code file update, only their specific changes are deployed.
One point for Kubernetes.
Category 4 – Ecosystem
The developer world at large or the world created by a cloud provider. Severless is vendor-locked (at least in the case of AWS Lambda) and Kubernetes is open source software managed by the vendor-neutral Cloud Native Computing Foundation (CNCF), and user community Kubernetes has a rich ecosystem around it and can use any service by any provider but serverless is locked to one provider — but its the provider of choice. It’s not like there’s only one serverless option around.
Yungelson is happy with AWS, its vast amount of innovative services, and said she, “doesn’t feel like she’s missing out. It was our choice to vendor lock.”
The attendees were not quite ready to make that commitment though. Another point for Kubernetes.
Category 5 – Monitoring and Logging
This one takes it back to the earlier idea of serverless being a new way of thinking. With Kubernetes, developers can monitor and log with the same tools they know and love from everything else (ie “it’s how we monitor Linux”) but with serverless there is no server infrastructure to monitor and log. There’s no hardware or hardware limitation to manage though all standard monitoring software supports serverless though the use may be different.
The main con with Kubernetes are the multiple layers and objects to monitor.
It wasn’t enough to push serverless for a win. It was a tie.
Category 6 – Security
They both have help with security. Kubernetes from regular updates and serverless from the cloud provider, but there is still development work. For example with Kubernetes, if they’re running on EC2 instances the devs need to secure the EC2 instances. With serverless the elopement work comes from the making sure the code meets the security requirements, lambdas are built inside the virtual private cloud (VPC), and there aren’t any virtual public clouds.
And in the end it was a tie!
Both applications discussed in the talk are running on Amazon Firecracker.
This was an incredibly engaging way to talk about tech tradeoffs. It was engaging and informative. The space was packed as was the overflow space and the presenters were very knowledgeable. Five stars. Do recommend.