cgi-bin scripts have little in common with the above model.
If you're using containers, then IMO, you're no longer serverless. The reason being...
> Nothing to maintain or update outside of your own code
Unless your Dockerfile uses something like "FROM python:latest", you'll find yourself having to update your Dockerfile to pull in new images on a regular basis in order to get the latest package updates.
People usually like to have reproducible builds though, so will instead use something like "FROM:python:3.7.16-alpine3.18". Except, sorry, that's out of date now. You need to update to "python:3.7.17-alpine3.18."
It's quite easy to use with statically compiled languages, and a bit less so with interpreted ones like Python, but you need to use a multi-step build with first an image containing your dependencies to compile, and then a stage from scratch copying just the resulting artifacts. That way your production image is extremely light and has no attack surface or stuff to update outside of your own code. The main downside is that debugging live is not easy (if you have some networking errors, you can't just exec inside and do some ping/curl/netstat/etc. to check stuff, because you can't even exec inside due to no shell being present), and requires extra tooling like cntr/cdebug or Kubernetes Ephemeral Containers which will attach a fuller container (e.g. busybox) to the running scratch one to be able to debug.
https://chemidy.medium.com/create-the-smallest-and-secured-g...
https://medium.com/analytics-vidhya/dockerizing-a-rest-api-i...
For example, developers who are really focused on up-to-date skills will likely recognize that cgi-bin has had a "scent" to it since the early 2000s.
Developers who are of a systems mindset will automatically think about contingencies. How will this scale as a system, what if I need to hire developers, what if cgi-bin goes away or gets expensive for various reasons, what about security, who is watching it, etc.
This sounds like enterprise level thinking but a lot of people think this way for a hobby, even.
Just like you said, it's really the strict-specification- and use-case-focused people who will still benefit from cgi-bin still being really cool in its own way.
I'd guess that it's a good idea to have at least some plan to move along, or keep one's finger to the cgi-bin wind, so to speak, if the project will be used by an audience that's taking it seriously. But this perspective can also suck a lot of fun out of things... :-)
The utility of "serverless" is it rolls up all the deployment and execution in automation. All of the infrastructure is managed externally and automatically for you. You also get auto scaling for free.
With a VPS you've got some minimal cost to leave it running. With "serverless" you're only paying for invocations. If you've got a handful of hits a day it costs so little you might not be charged for months. If you get a spike of traffic with thousands of hits you don't need to scramble to scale up your "simple" CGI server to handle the load.