To be fair, serverless platforms doesn't always provide queue or database. Usually they come alone with some sqlite or KV store for the convenience.
SSL was provided by the php-fpm part, with either Apache or nginx, like most "platforms" do. Modern platforms may choose less-popular fronts like Caddy, and Caddy does support php_fastcgi.
The purpose of serverless is easily deploy applications without worrying about / managing infra at all. The only reason you don't need to run your own infra with PHP is because it doesn't do anything except the web application. As you noted, it doesn't even do the web-serving. Most serverless application platforms are then paired with hosted databases, hosted queues, etc, so that you don't need to manage those either. But yes, only some of those additional pieces can be described as "serverless", e.g. AWS Aurora is an actual serverless database, vs DigitalOcean's hosted Postgres, which does not scale in a "serverless" way. Regardless, minimal management of the database is required on these platforms.
Dokku in turn is a replacement for those platforms and makes it easy to host your own [insert some part of your platform stack here]. That is the purpose of a PaaS, which is what Dokku is and what PHP certainly is not. Yes, the OP maybe should've said "My favorite personal PaaS", but that is less catchy, and I think calling it a "serverless platform" is close enough to the truth and gets the point across.
Dont get me wrong, Dokku is a fine project of its own, but it doesn't seem to tackle the problems you mentioned either. On the other hand, if php is not enough, the LAMP can do everything.
I'd recommend reading more thoroughly about Dokku (or PaaS in general) since it is somewhat clear you don't understand the value prop. Just grepping for certain terms isn't gonna get you very far.
Dokku is Docker + Buildpacks + Orchestration. You give it a buildpack (developed/popularized by Heroku) to specify your application, which is the main "serverless" part. Then you tell Dokku that you want datastores or queues or whatever, via plugins[1]. Dokku handles pulling the relevant docker images, running them, and linking it all together. In other words, Dokku is open-source Heroku, where you can add databases and such with a single command, specify your app with a buildpack, and you're off to the races.
If Dokku only did the application via buildpack part, people would not find it nearly as useful and PHP on a webhost somewhere would indeed be a good alternative.
But Dokku is not that, it is a PaaS, so it can also run your PHP application just as easily. And if you're self-hosting Postgres and RabbitMQ via Dokku, why would you run your PHP on Dreamhost? You probably wouldn't, you'd throw a PHP buildpack up there and call it a day.
ok, but "pulling the relevant docker images" does not scale, bro. There's a gazillion of parameters to fine tune a Postgres alone, and trust me, running db inside a container is bad, as stateful containers are terrible in general.
And I really do hope scaling should be as easy as "pulling docker images"
So, how is PHP + queue library different than Dokku(or PAAS as you call it) + queue plugin? Other than the fact that you write it all in yaml/json/gui instead of code?
> "I'd recommend reading more thoroughly about Dokku (or PaaS in general) since it is somewhat clear you don't understand the value prop."
My cynical and uncharitable translation of this and the rest of your post for the GP: We've invented platform or PAAS or devops so that we can carve-away work from devs that used to traditionally do this kind of stuff in partnership with infrastructure, and you're just not understanding it because you're coming from a dev perspective.
It's all just evangelism/marketing-push to gather the online webosphere mindshare and capture the development process so that all that's left for the downstream individuals (developers) is nothing but config/yaml/plugin-ecosystem and even that stuff only the ordained priests of DevOps understand (or are allowed to touch), again leaving developers with even less, making them glorified code-monkeys that need to spit out CRUD screens. It's either that, or put "DevOps" on your resume or title, almost like a mafia-style shake-down.
It works, sure, provides immense value sometimes and gets you to market quickly sometimes, sure, etc. But damn is it toxic and detrimental for our community in the long run. In an alternate universe or timeline we could have gone some other direction, but this is what we have for now, so we have to live with it. DevOps and UX will many years from now be known as two very bad paths that we allowed our industry to be dragged down into.
To answer your question with another question: what exactly is the PHP queue library interacting with? Where is the queue being persisted? How is that persistence layer being deployed/run?
I am a dev, so your translation is indeed cynical and uncharitable (and inaccurate).
I also don't understand what you have against DevOps or UX. DevOps is just how you actually run the applications/services/etc (that you've written with code) in production. DevOps can be done by a developer or by people dedicated solely to that task. UX is just caring about how end users actually interact with the application/services/platform. This can also be done by developers, or by designers, or by UX specialists, or whomever.
These concepts exist regardless. Sure, you can choose not to care about how your application and its required dependencies are run. Sure, you can choose not to care about how your users interact with the things you are building. But not caring about those things doesn't mean they go away.
But that's the reason why serverless has mostly failed so far -- because it is not stateful. And that is only because most existing offering don't have the correct primitives.
By that I mean that if the programming model has a way to automatically capture state, an implementation framework can manage it automatically on behalf of the application, while the user (person writing the app logic) doesn't have to care about the state.
SSL was provided by the php-fpm part, with either Apache or nginx, like most "platforms" do. Modern platforms may choose less-popular fronts like Caddy, and Caddy does support php_fastcgi.