XML is the future

In fact, it's trivial to setup many things on a server that you simply can't on a serverless function. For example, a simple cron job or a simple persistent queue or websockets. You have to use 3rd party services for these simple tasks that you could have done on your server.

2. That has nothing to do with serverless or servers.

It's been this way forever. For every level of the stack. When I started the physical hardware hadn't been settled (coax, ethernet, token ring etc.)

Fortunately when I started we only got paid when we shipped. So we were motivated to ship, not be distracted by rewrites. We were also lucky that as a boot-strapped company we had no managers calling the shots. We made decisions and stuck to them, and it's paid off over the long run.

Of course the product has changed immensely over 25 years - but the core code laid down in 1996 is still integral. We've spent the time on the product, not worrying about the sexiness of the tech stack.

Which is not to say we've ignored the tech stack, it's evolved a lot, but the stack serves the product, not the other way around.

On the other hand we don't have to raise investments, we don't have to attract endless streams of new programmers, we don't have to juice a stock price, so we don't have to appear modern or hip. We can just keep doing what we do, making money, focusing on the value to customers, not being (easily) distracted by the next shiny toy.

And yeah, after a couple decades you learn to see through the hype a bit and distinguish things that are good for you, not just the flavor of the week.

2, 3. The promise is that serverless APIs can be deployed on the edge for improved latency. The edge does not matter if your data is centralized. So you're adding complexity without the benefit of speed.

4. One of the most important aspects of any web app is load speed. Sure, you can say that serverless is better for scaling but who cares if your web pages are randomly adding 3-5 seconds to the loading time.

5. Try pointing your mobile app to Vercel's serverless APIs that are built inside Next.js. Makes no sense.

6. The most common way people use serverless for webapps is through Vercel's FaaS or some other similar FaaS. That's what I'm focusing on. Not confused. No, FaaS does not have more predictable pricing than servers.

7. It is. I just outlined why it is. Even if you want a simple cron job or a simple persistent queue, you can't do it with serverless functions.

8. You're building your entire stack on a FaaS like Vercel with Next.js. It's not as easy to switch hosts like using Docker. I don't know if you were doing development during the Zeit V1 days but one of the main criticisms of Vercel and newer versions of Next.js is now it makes it hard to switch hosts. Whereas, being able to switch hosts easily is default in a docker setup.

AKA Yak shaving[0], which I am... unashamedly fond of doing

>> There are yaks to shave all over the stack, and I go where the yaks are. (quote is from my github readme)

> When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.

I definitely agree that selling this to a client when you've told them you'll do the minimum to update the codebase is immoral, but if there is value in updating, then you should expose them that value.

For example -- moving a client to AWS might not make sense, but if they're maintaining on-prem infra and paying tons of money for an application that would actually cost less as a single ECS service (or App Runner, these days)... Then maybe you should upgrade their stack a little bit.

In the end it's your job as a consultant or an employee (if you're high level enough) to introduce change that will make the company better, if you see an opportunity.

Tech stacks crumble underneath their own weight, and if they're bad enough, become business risks. If it's humming along, easy to maintain, and isn't riddled with security holes, then great!

[0]: https://en.wikipedia.org/wiki/Yak_shaving

1. Amazon provides things like RDS Proxy, which is essentially a hosted version of pgbouncer, and Aurora, essentially a "serverless postgres" - no need to manage your own server for connection pooling.

2. Cloud vendors have largely fixed the cold start times through a variety of means like min scaling of 1, warming requests, and functions that can process many requests simultaneously.

3. I don't get your point about not being able to share an API between web and mobile. I do this all the time.

4. When it comes to vendor lock-in, GCP for example offers Cloud Run, which will essentially just spin up any Docker container you give to it.

Managing your own servers can have a huge cost, and this can be an especially large cost for a small team. For example, does your business have any SOC 2 or other compliance requirements? Being on serverless as opposed to being on, say, your own EC2 instances, means a huge amount of work (e.g. ensuring servers are always patched, ensuring they are configured securely, ensuring you have permissions configured correctly, etc.) can be offloaded to the cloud provider, who is frankly much more likely to do it correctly than a small startup team.

If anything, I think GCP's CloudRun is awesome and the real future of serverless. In my mind it has most of the benefits of something like kubernetes with about 1/50th of the complexity.