4 ms·

On the subject of Perl: I've seen HN'ers vehemently beat down any comparison between "serverless" and the old world of /cgi-bin perl scripts. But I've yet to se

On the subject of Perl: I've seen HN'ers vehemently beat down any comparison between "serverless" and the old world of /cgi-bin perl scripts. But I've yet to see a reason why. Why, exactly, aren't people using simple and straight-forward run-once cgi-bin scripts? They seem super suitable to so many use cases, even in 2023.

jarym 3y ago
Because developers want to believe they're using something NEW and SHINY. Comparisons to decades old technology doesn't fit into that belief system so some will be hostile towards such suggestions.
TylerE 3y ago
Because they really aren't. Things like not being able to reuse DB connections really hurts. Building the world on every request, 99 times out of 100, is dumb.
- treis 3y ago
  This is my one big problem with Postgres. Their heavy client/thread model prevents these sort of architecture where you may have a large number of connections. PGBouncer helps a lot, but it's not quite the same.
sofixa 3y ago
You might have a different definition of "serverless", but for me and many others it's "you don't have to worry about the underlying infrastructure". You throw your script/container, it's easy to invoke, easy to scale up to millions rps, or down to zero. Nothing to maintain or update outside of your own code. Useful for unknown or highly variable loads. cgi-bin scripts have little in common with the above model.
- Sohcahtoa82 3y ago
  > You throw your script/container 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."
  - sofixa 3y ago
    That's where scratch containers come in.
    - Sohcahtoa82 3y ago
      Haven't heard of those. Can you tell me more?
      - sofixa 3y ago
        Basically instead of FROM python:3.9, you do FROM scratch. This represents an empty container with nothing. 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-golang-docker-image-based-on-scratch-4752223b7324 https://chemidy.medium.com/create-the-smallest-and-secured-g... https://medium.com/analytics-vidhya/dockerizing-a-rest-api-in-python-less-than-9-mb-and-based-on-scratch-image-ef0ee3ad3f0a https://medium.com/analytics-vidhya/dockerizing-a-rest-api-i...
themodelplumber 3y ago
There are so many different web developer audiences... 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... :-)
fullspectrumdev 3y ago
Most lambda functions and such that I see people write could just be a CGI script on an 5$/month box. And it would be way cheaper.
giantrobot 3y ago
To run a cgi-bin you need a host server that will execute the bin. That needs to run on a full fledged OS. When you've got an update to the script you've got to deploy it to that server. Every one of those things takes a little bit of time to manage. 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.

jarym 3y ago

Because developers want to believe they're using something NEW and SHINY. Comparisons to decades old technology doesn't fit into that belief system so some will be hostile towards such suggestions.

TylerE 3y ago

Because they really aren't. Things like not being able to reuse DB connections really hurts. Building the world on every request, 99 times out of 100, is dumb.

treis 3y ago
This is my one big problem with Postgres. Their heavy client/thread model prevents these sort of architecture where you may have a large number of connections. PGBouncer helps a lot, but it's not quite the same.

sofixa 3y ago

You might have a different definition of "serverless", but for me and many others it's "you don't have to worry about the underlying infrastructure". You throw your script/container, it's easy to invoke, easy to scale up to millions rps, or down to zero. Nothing to maintain or update outside of your own code. Useful for unknown or highly variable loads. cgi-bin scripts have little in common with the above model.

Sohcahtoa82 3y ago
> You throw your script/container 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."
- sofixa 3y ago
  That's where scratch containers come in.
  - Sohcahtoa82 3y ago
    Haven't heard of those. Can you tell me more?
    - sofixa 3y ago
      Basically instead of FROM python:3.9, you do FROM scratch. This represents an empty container with nothing. 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-golang-docker-image-based-on-scratch-4752223b7324 https://chemidy.medium.com/create-the-smallest-and-secured-g... https://medium.com/analytics-vidhya/dockerizing-a-rest-api-in-python-less-than-9-mb-and-based-on-scratch-image-ef0ee3ad3f0a https://medium.com/analytics-vidhya/dockerizing-a-rest-api-i...

themodelplumber 3y ago

There are so many different web developer audiences... 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... :-)

fullspectrumdev 3y ago

Most lambda functions and such that I see people write could just be a CGI script on an 5$/month box. And it would be way cheaper.

giantrobot 3y ago

To run a cgi-bin you need a host server that will execute the bin. That needs to run on a full fledged OS. When you've got an update to the script you've got to deploy it to that server. Every one of those things takes a little bit of time to manage. 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.