Option A above requires standing up a new server. Option B involves just writing a short piece of code that handles a form POST and uploading it to a server (in that case, Amazon's). Option C, "If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost," has the following disadvantages, according to him: "Now you have to tweak the Nginx config to support the service that normally lives on that machine and the new system. And you still have to write and maintain the web service driving it (which may not be hard, like a Flask app with a single route, but still more than zero)."
But a CGI program, assuming you have cgi-bin already configured, gives you the benefits of option B without the drawbacks of option C: you don't need a Flask app or a route or a configuration tweak. You just write a short piece of code that handles a form POST and upload it to a server. The difference is that it's your server, not Amazon's, and you have to put this at the top of your code:
#!/usr/bin/python
import cgi
qs = cgi.parse()
Then you can version-control it in Git so that when you need to figure out what broke last week you don't depend on AWS deployment logs.
Like, literally, the drawbacks of "serverless" that are being cited in this discussion (startup time and performance cost) are the reasons we moved away from CGI in the late 1990s, and literally every single advantage being cited for "serverless" in this discussion is also an advantage of CGI. "Serverless" also has disadvantages of vendor lock-in, lack of programming-language choice, and difficulty of monitoring and debugging that don't exist with CGI, but those aren't coming up much in this discussion.
The only real advantage seems to be if you can get by with literally zero servers of your own, thus saving the US$5 a month you would spend on a low-end VPS to run your potentially dozens of CGI scripts under Nginx, maybe inside Docker. In that case maybe you should look into shared web hosting. Or possibly get a job, if that's a possibility.
I'm not saying "serverless" isn't a good idea or that it isn't an improvement on CGI. The CGI interface is kind of sketchy and it's produced a lot of bugs in the past. It would be easy to do better, especially with a native-language binding. But the reasons we abandoned CGI are also reasons to abandon "serverless", and the actual advantages of "serverless" (if they exist) are not coming up in this discussion.
But a CGI program, assuming you have cgi-bin already configured, gives you the benefits of option B without the drawbacks of option C: you don't need a Flask app or a route or a configuration tweak. You just write a short piece of code that handles a form POST and upload it to a server. The difference is that it's your server, not Amazon's, and you have to put this at the top of your code:
Then you can version-control it in Git so that when you need to figure out what broke last week you don't depend on AWS deployment logs.Like, literally, the drawbacks of "serverless" that are being cited in this discussion (startup time and performance cost) are the reasons we moved away from CGI in the late 1990s, and literally every single advantage being cited for "serverless" in this discussion is also an advantage of CGI. "Serverless" also has disadvantages of vendor lock-in, lack of programming-language choice, and difficulty of monitoring and debugging that don't exist with CGI, but those aren't coming up much in this discussion.
The only real advantage seems to be if you can get by with literally zero servers of your own, thus saving the US$5 a month you would spend on a low-end VPS to run your potentially dozens of CGI scripts under Nginx, maybe inside Docker. In that case maybe you should look into shared web hosting. Or possibly get a job, if that's a possibility.
I'm not saying "serverless" isn't a good idea or that it isn't an improvement on CGI. The CGI interface is kind of sketchy and it's produced a lot of bugs in the past. It would be easy to do better, especially with a native-language binding. But the reasons we abandoned CGI are also reasons to abandon "serverless", and the actual advantages of "serverless" (if they exist) are not coming up in this discussion.