XML is the future

1. Having your APIs as lambdas now means you can't simply connect to a Postgres/MySQL without setting up a dedicated server that serve as a connection pool. So you're now "serverless" but you now have to add a server as a connection pool. /facepalm

2. Putting your APIs on the edge means absolutely nothing if your Postgres/MySQL/Redis/3rd party services is still in one location.

3. Serverless edge databases started popping up but they were significantly more expensive (because you have to replicate data everywhere) and more complicated with limited upside.

4. Cold starts on lambda APIs meant that your web app/web site often load slower than a centralized server.

5. You can't reliably share APIs between your web app and mobile app anymore. Previously, a single server could easily be made to serve both your web app and mobile app.

6. Serverless is often more expensive and unpredictable when it comes to billing. Previously, if you paid $15 for a server, you're going to be billed for $15.

7. Serverless is significantly more complicated when you're just trying to build an MVP. There's no need to try to scale like you're Google when you're just trying to create a proof of concept.

8. You're far more likely to be vendor-locked doing serverless.

Serverless should not have been the default option for webapps. Serverless should have been the exotic option for companies that had a special scaling/edge need. Instead, servers should still be the default. The problem is that Next.js is so popular and so intertwined with Vercel that serverless is the default now.

If Vercel/Next.js were honest, they would tell everyone to use serverless only if they're making a static website. Everything else should start out as a server.

- scale to zero, or scale to one (no cold starts) - not having to manage disk space - not having to manage quite a bit of security (ssh login, fail2ban, opened ports, unprivileged user) - in some cases, out of the box - or easier - deploy pipeline

Would you feel more or less confortable taking vacations while having a server or a server less platform?

Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform?

I quite agree with what you say but can't deny there are lots of non negligible advantages.

All of these things are extremely trivial to configure.

> Would you feel more or less confortable taking vacations while having a server or a server less platform?

Depends on the SLA of my provider. Most VPS providers have 3+9s these days, then the reliability concern becomes my code, same with serverless.

> Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform?

It is a common misconception that serverless platforms are inherently more secure. In reality, they just have different security concerns. In my eyes, it takes a practitioner of equivalent skill to properly harden a fleet of servers Vs correctly handle the eccentricities of IAM et al in a large cloud app.

1. You still have to do polling with servers 2. Not a serverless problem 3. Not a serverless problem 4. This is a tradeoff, not complexity 5. Why not? What does serverless have to do with this? 6. Appears you're confusing serverless and FaaS. Regarldess, FaaS has incredibly predictable pricing. Previously if you paid $15 for a server, you're going to be billed for however many servers you had running on average throughout the month. 7. It's not. Your points here are trying to back it up, but have so far not done so. 8. Why would that be? And how does that factor into complexity?

Your claim is flawed for two reasons: 1. Serverless != FaaS. FaaS is serverless, serverless is not FaaS. 2. You've not taken auto-scaling into consideration on the server side.