FaaS platform concurrency and operational challenges
Problem
Commenters' experiences with AWS Lambda Web Functions and similar serverless models are divided: some appreciate the zero-cost, no-server-management aspect (e.g., comment 3), while others explicitly highlight concurrency limits (e.g., 128 requests per environment) and code fragmentation causing operational friction, preferring traditional cloud instances (e.g., comment 5). Additionally, cold starts can be mitigated via Rust runtimes (comment 4), exposing an overall trade-off between serverless simplicity and operational flexibility.
Pain points
- Do not want to manage servers or Docker images
- Concurrency limit of 128 restricts application scaling, requiring traditional cloud instances
- Serverless mode scatters code, increases operational difficulty, forming 'piles' that are harder to maintain
Questions to verify
- Would you be willing to pay extra for higher concurrency limits or equivalent control over traditional cloud services?
- How do you currently handle code organization and operations on serverless platforms? Do you experience 'fragmentation' challenges?
- Do you consider the current FaaS concurrency limits (e.g., 128 concurrent requests per environment) a major bottleneck for your business?
Evidence
I don't want to manage a server or even a docker image.
up to 128 concurrent requests per environment
it's in these really weird piles that are often much harder to access.
Disclaimer: this card is distilled by AI from community discussions as “pain point evidence”. It is a starting point for need analysis and validation, not a “validated market need”. AI has analytical limits; please open the original discussion above to manually verify before key decisions.