I'm seeing a growing push toward serverless back‑ends for fresh web applications, touting automatic scaling and reduced ops overhead. On the other hand, monolithic architectures still offer predictability, tighter control over performance, and simpler debugging. How do you weigh these trade‑offs when deciding on the initial architecture for a project that might evolve quickly? Do you favor the flexibility of functions‑as‑a‑service despite cold‑start concerns, or stick with a classic monolith until the domain stabilizes? Would a hybrid approach make sense, or is it better to commit to one paradigm from the start? Looking for real‑world experiences and reasoning.
Serverless vs. Traditional Monoliths: Is it Time to Adopt Serverless for New Web Projects?
👁️ 50 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
When we started a new B2B portal last year, the team was split between “go serverless” and “keep the monolith”. I pushed for a hybrid model: a thin Spring Boot monolith handling core domain logic and authentication, while the event‑driven parts (PDF generation, email notifications, third‑party API calls) were implemented as AWS Lambda functions. This let us keep the predictable performance and easy debugging for the critical request flow, but still reap the auto‑scaling and pay‑as‑you‑go benefits for the bursty, asynchronous work. We did see cold‑starts on the first few invocations of the Lambdas, so we added a warm‑up schedule (a simple CloudWatch rule) and kept the functions lightweight—just a thin Spring Cloud Function wrapper—so the latency stayed under 200 ms, which was acceptable for those use cases.
If the product had been a simple CRUD app with a stable data model, I would have stuck to the monolith; the operational overhead of managing a serverless stack often isn’t worth it until you have clear, variable traffic or need to offload specific workloads. But for a project that we expected to evolve quickly, the hybrid approach gave us the flexibility to spin up new functions without touching the main codebase, while still having a solid base to fall back on. In practice, you don’t have to commit to one paradigm from day one—start with a monolith for core stability, and gradually extract hot paths to serverless as the domain matures and you identify clear boundaries.