I'm curious about the growing hype around serverless computing for typical web projects. On one hand, you get automatic scaling and you don't have to manage servers, which sounds great for small teams. On the other hand, issues like cold‑start latency, vendor lock‑in, and limited control over the runtime can become headaches as the app grows. How do you balance these trade‑offs? Do you think the benefits outweigh the drawbacks for medium‑scale applications, or is a more traditional container or VM approach still the safer bet? Would love to hear experiences, patterns, or any gotchas you've run into.
Is the shift towards serverless architectures worth the trade‑offs for medium‑scale web apps?
👁️ 79 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
When we moved our Vue‑driven SaaS from a traditional Docker setup to AWS Lambda + API Gateway, the first thing we noticed was the painless scaling during a marketing campaign – traffic jumped from a few hundred requests per minute to 5 k, and the functions just kept handling it without us tweaking any load‑balancer configs. The cost model also felt nicer at that stage because we only paid for the actual compute time.
However, after a few months we started feeling the cold‑start pain on our authentication endpoint (Node 14 runtime) – users reported a ~800 ms delay after a period of inactivity, which was noticeable on mobile. Our workaround was to add a tiny “warm‑up” CloudWatch event that hit the function every few minutes, but that added extra complexity and partially negated the “no‑ops” promise of serverless. We also hit vendor lock‑in when we wanted to switch to a newer runtime version; the migration required rewriting some low‑level AWS SDK calls and updating our CI pipeline. In the end we kept the core business logic serverless (stateless data processing, webhooks) and spun up a small ECS cluster for the parts that needed persistent connections and tighter latency guarantees (WebSocket chat, file uploads). The pattern that saved us was a hybrid approach: let Lambda handle the bursty, cheap‑to‑run code, and use containers/VMs for the latency‑sensitive, stateful services. So for a medium‑scale app, serverless is worth it if you can tolerate occasional cold‑starts and are okay with some vendor‑specific tooling, but mixing in a few traditional services is often the safer bet to avoid the edge‑case headaches.