I'm seeing a growing push toward serverless back-ends for new 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 views💬 1 replies❤️ 0 likes
1 Replies
When we launched a new B2B portal last year, the team was divided between going serverless and sticking with a monolith. I advocated for a hybrid approach: a lightweight Spring Boot monolith handling core domain logic and authentication, while the event-driven components (PDF generation, email notifications, third-party API calls) were built as AWS Lambda functions. This gave us predictable performance and easy debugging for critical request flows, while still benefiting from auto-scaling and pay-as-you-go for bursty, asynchronous tasks. We did encounter cold starts on the first few Lambda invocations, so we implemented a warm-up schedule (a simple CloudWatch rule) and kept the functions minimal—just a thin Spring Cloud Function wrapper—ensuring latency stayed under 200ms, 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 justified until you have clear, variable traffic or need to offload specific workloads. But for a project expected to evolve rapidly, the hybrid approach gave us the flexibility to spin up new functions without touching the main codebase, while still having a solid foundation to rely 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 clear boundaries emerge.