I convinced my K8s team to go AWS serverless. Spoiler, they didn't

Clickbait alert! I could not.

But since you’re here and in the same proverbial boat as me, maybe my lessons learned and battle scars can help you frame your own arguments better.

Generally, the discussion starts with you pitching serverless to your team, praising the benefits of

1. running lambdas on demand
2. using cognito for user-authentication
3. using API Gateway for exposing endpoints
4. Using Dynamodb you dont have to pre-provision or manage
5. Using Managed SQL databases for relational queries
6. Using Kinesis/Kafka for capturing logs
7. Event-driven invocation using EventBridge

Eventually, your discussion gets louder, you get excited and a k8s engineer looks up from his yaml editor of choice and shuts you down loudly and rudely.

“Do you know how much it costs when Lambdas go out of control with high concurrency and cold starts?”

There it is, you have already lost the argument, Why?
Because you didnt mention ECS for long-running/continuous tasks.

I will give you points for mentioning “on demand” with lambda, but hey its not your fault, blame AWS for promoting the word “serverless”

To a k8s engineer, serverless means “no servers”! Yes I know to an engineer it means “no servers to manage”. But that nuance is lost in the trenches of DevOps debates.

You see, I have trawled through tons of reditt discussions, stackoverflow debates, and never found the one k8s engineer who was convinced to give serverless a chance.
I even went to chatgpt to try to reason it out and it conked-out on me. Remember the OpenAI outage 3 weeks back? That was me, trying to work it out with chatgpt. It was easier to convince it that in 2025 Trump is indeed the president of USA.

So, I have made my peace with 2 things:

1. My Wife is always right
2. k8s engineer would never understand YBIYRI (You-Build-It-You-Run-It)

I know the arguments they will have, since I spent the last year of my short life arguing and arguing again, against the same points

1. Lambda

• k8s Engineer: If use lambda, it will cost a bomb
• Serverless Advocate: You definitely should not use lambda for long running tasks, use ECS instead.
  Afterall, with k8s you are also spawning EC2 instances, same way ECS does.
  And you need to pay for EKS cost + Master Servers, plus the compute performance is eaten by kubelet and what not.
  Plus you cant run stateful applications like kafka on k8s ( well not without pain and suffering)

2. Cost

• k8s Engineer: you will pay more for serverless services
• Serverless Advocate: Yes, but instead of paying for infrastructure overhead and hiring 5–10 highly specialized k8s engineers, you pay AWS to manage it for you. Thousands of AWS engineers do a better job than any in-house team ever could.

3. Escalating Cost

• k8s Engineer: A lot of companies, like Basecamp/Hey, are moving away from cloud because of escalating costs
• Serverless Advocate: Yes, cloud can be costly, if improperly implemented. eg. running a lambda continously, leaving provisioned instances idle, even unnecessary public IPs will burn your wallet, and they should. Stupidity should be pricey

4. Vendor lock-in

• k8s Engineer: Serverless ties you to your cloud provider
• Serverless Advocate: Nice, now we are getting somewhere. Even with say python for code and terrform for deployment, you will end up using some or other managed service like DynamoDB, and migration to another cloud provider will need re-engineering.
  But the real question is, why will you migrate? It is not like AWS is like Orkut, which can be shutdown overnight. As long as you keep the cost down, you will never need to move away.

5. AWS vs opensource

• k8s Engineer: AWS is evil, its repacking opensource technologies and making money out of them
• Serverless Advocate: That went downhill quickly. So what? It’s a free economy. Isn’t that what you are also doing? Eg. Redis, the darling of open-source wold, has top contributors from AWS. You have to respect AWS for the sheer engineering involved in technologies like DynamoDb, S3, EventBridge, Lambda

6. I will take responsibility

• k8s Engineer: Hey man, just give me your code, I will run it, you dont have to worry
• Serverless Advocate: Yes you will, but what happens when something breaks, and eventually it definitely will. You will wake me up at 4AM and blame me for “bad code”, I will say “It works on my machine” and we will be back to pre-cloud days.

7. We will Share Responsibility

• k8s Engineer: We will work together to deploy it and it’s all yaml, you can also learn it
• Serverless Advocate: DO.NOT.FALL.FOR.THIS. Developer hate k8s yaml config files, they dont make sense to real-developers, until we can parse it, load it into a variable and inspect it in debug window.

Now you go on the offensive.

1. Single Point-Of-Failure: the Platform/DevOps/Infrastructure Team

• Serverless Advocate: We are adopting microservice, but with a central deployment team, we are causing a single point of failure
• k8s Engineer: We can scale up our team, best case scenario one k8s engineer in each dev team who will report to a central k8s boss
• Serverless Advocate: like mafia?
• k8s Engineer: Call me Don Kuberleone…

2. Serverless offerings + k8s ?

• Serverless Advocate: What if i want to use serverless offerings like DynamoDB which I can self-provision using infrastructure-as-code
• k8s Engineer: Postgres is the king of databases, change ur design to use sql instead?

3. Stateful Apps on K8s

• Serverless Advocate: Teams have failed to run stateful applications like kafka at scale on k8s
• k8s Engineer: We will do it better!

4. Killing Developer Velocity

• Serverless Advocate: If I develop a new feature, I will build it, debug it, then come to you. Then you will do the same, have endless meetings and finally my user will see the product 3 months after asking for it.
• k8s Engineer: No no, you first discuss the feature with us, we will provision resources for you to develop it.
• Serverless Advocate: Cloud will be your personal fiefdom?

5. Less infra management = More focus on higher-value tasks

• Serverless Advocate: you loose control, say something naive like instead of maintaining YAML, they can work on observability, security, and automation.
• k8s Engineer: How dare you? can you write custom Istio routing policies for control traffic at a granular level, ensuring safe rollouts and performance tuning. Serverless doesn’t provide that level of customization.
• Serverless Advocate: Exactly! I dont need that, no body needs that!

At this point, you are already tired of this meeting, and even this article, and just want to go back to coding, so I will wrap up quickly.
You too should pretend to take an urgent call and get out of this meeting.

This debate never ends. You just can’t win it.

In reality, k8s and serverless can coexist. They both have their strengths and weaknesses. k8s is great for container orchestration and complex workloads, while serverless shines for event-driven, auto-scaling applications.

But will a k8s engineer ever admit that?

A Kubernetes engineer is never going to openly admit that serverless reduces their control (and potentially their role).
It’s like asking a taxi driver what they think about self-driving cars — there’s an existential threat involved. They’ve spent years mastering Kubernetes (basically copy/pasting yamls) — it’s hard to just walk away.

If you’re arguing with a k8s purist, you’ll never convince them.

Do real work, stop staring at charts.

Good luck :) No need to let me know how it goes in comments, as I already know the result. 😆