Is serverless worth the complexity?

The context is too vague. A web application doesn't mean anything. It's like saying 'I need to buy a car, what is the price?'. A web application can be anything between a one page small site to an e-commerce platform or a twitter-like application. So it is very difficult to give guidance based on such a broad use case.

In any case, here are some general ideas: Costs

TLDR : Spiky usage = Serverless is less expensive in general.

• Serverless architectures can offer lower costs compared to traditional server-based options, especially for applications with inconsistent usage patterns. This is because serverless architectures follow a pay-as-you-go model, meaning you only pay for the resources you use. This can be more cost-effective than maintaining servers that may be underutilized during off-peak periods
• The cost advantage of serverless can diminish or even reverse for certain workloads, particularly those with consistent, high-volume traffic. In such cases, the costs for serverless can become higher than a plain server. This apply as well for on-prem vs cloud based server (on-prem is cheaper than cloud based if you use the server 100% of the time), if you do not factor the global TCO (human labor, maintenance, etc).

Latency

*TLDR : Not a real issue if you know how to architect your application

• The latency question is complex to answer. First it depends on the language you use: Node.js applications are way less prone to cold start than Java application. Then there is multiple way to reduce the cold start that could in addition be an improvement to the overhal application.
• As an example, by splitting the code base into smaller function, you reduce the cold start, reduce the import dependencies, thus you reduce the memory footprint, package size and increase code flexibility.
• As a bonus, you could even use different language per serverless function (if you go the lambda way) : python for ML function and Node.js for standard web queries for instance.

Complexity

*TLDR : Managing EKS can be more complex than just an Apigateway+lambda. The complexity depends on the skillset of the team.

• If the team is made of seasoned dev ops, with server management+kubernetes proficiencies, then yes they should use that advantage.
• If it's a rookie team or small team, then the serverless is nearly always a better choice: you develop, you deploy, repeat. It's that simple. No specific config to scale, no patching, no monitoring, etc.
• The complexity question can be seen as a strength as well => More complex mean more finetunable which is key for some workload. If you have a twitter-like application with millions concurrents users, i'm pretty sure you're gonna need something more specific than Lambdas...

As a final note, 3rd party vendors of PaaS are mainly using serverless technologies. Ask yourself why...

First when we talk about serverless, it means that we have different services such as databases (Aurora serverless), computing for containers (AWS Fargate), etc.

1 Depending on the type of service, serverless may be a little more expensive. But avoiding managing servers will definitely reduce your workload in server administration. (In another area, working with EMR in instances vs AWS Glue for ETLs, glue is serverless and makes everything much simpler). This first point is a little difficult to define unless you are talking about a specific service to be able to give you better answers.

2 For the second point, when you work serverless, latency is not a problem and the complexity is always much lower. The important point here is the price, which could be high depending on the use case.

Only you can determine whether moving to a serverless architecture is worth the benefit to you. To me, the benefits are:

• Only paying for what is being used.
• Not having to install, patch or otherwise maintain operating systems.
• Not having to worry about scaling.
• Not having to make choices about what compute and storage to use. There are still choices but they are simpler.

On the latency question: It's not necessarily true that serverless is higher latency than server-based computing. Nor is it necessarily true that serverless is lower latency. It's absolutely possible to build solutions using either technologies that can display higher or lower latency than the other depending on the architecture.

A common question here is about Lambda cold start times - even the runtimes that exhibit very low cold start times can still be higher latency than a (say) Fargate container which is always on and waiting for a network connection. But because of that (always waiting and always on) there is a higher cost. So there are tradeoffs to be made.

On complexity: Again this could be argued either way as it depends on which parts of your system you want to invest time and effort in maintaining.

I come at this from an overall view of why use the cloud in the first place? My belief is improved business agility.

As a developer, I find serverless helps you focus on patterns and development. Then you have to ask what happens to the infrastructure and "ops" functions? They become repurposed to focus on enabling product development, which is very much required in the cloud.

The assertion that serverless is higher latency is a very odd one.