| it’s not about collaboration or finding the right tool for the job, but rather about “my tech is better than yours.” K8s and Lambda serve different scopes and use cases. You can adopt a Lambda-style architecture using tools like Fargate. But if a company has already committed to a k8s, and this direction has been approved by engineering leadership, then pushing a completely different serverless model without alignment is a recipe for friction. IHMO, the author seems to genuinely want to try something new and that’s great. But they may have overlooked how their company’s architecture and team dynamics were already structured. What comes across in the post isn’t just a technical argument — it reads like venting frustration after failing to get buy-in. I’ve worked with “Lambda-style” architectures myself. And yes, while there are limitations (layer size, deployment package limits, cold starts), the real charm of serverless is how close it feels to the old CGI-bin days: write your code, upload it, and let it run. But of course, that comes with new challenges: observability, startup latency, vendor lock-in, etc... On the other side, the engineer in this story could have been more constructive. There’s clearly a desire from the dev team to experiment with newer tools. Sometimes, the dev just wants to try out that “cool shiny thing” in a staging environment — and that should be welcomed, not immediately shut down. The biggest problem I see here is culture. The author wanted to innovate, but did it by diminishing the current status quo. The engineer felt attacked, and the conversation devolved into ego clashes. When DevOps loses the trust of developers, it creates long-term instability and resentment within teams. Interestingly, K8S itself was born from that very tension. If you read Beautiful Code or the original Borg paper (which inspired), you’ll see it was designed to abstract complexity away from developers — not dump it on their heads in YAML format. At the end of the day, this shouldn’t be a religious debate. Good architecture comes from understanding context, constraints, and cooperation, not just cool tech. |