Yes, but now you have to pay for every requests made to your app instead of just paying $4 a month for a shared Apache server and I also have to architecture my PHP app in a rigid way to fit whatever "serverless" execution model the SAAS runs with.
A big IF. My $4/month stay $4/month without the added complexity of "serverless" deployment nor every stupid constraints this business model imposes. If serverless actually didn't make money, this business model wouldn't exist or wouldn't be pushed, mainly by Amazon employees here.
For most projects, that $4 server is great and what I would prefer. But where serverless can excel is an application that has very spikey usage.
If your $4 server gets hit with spikes of usage that would require a $500 server for an hour once or twice a month, you might be better off with serverless, rather than paying $500/month to have a server that big all the time.
You have your app, and database, and then your logging, tracing, and tracking stack and It all starts adding up pretty quickly.
Choosing serverless would be a bad game theory strategy choice.
This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.