Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by redwall_hp | Hacker News Reader

Parent Full thread

redwall_hp·

My understanding of it has been "look, I reinvented cgi-bin."

View on HN

Is cgi-bin highly available and will someone else have to wake up at night if it crashes?

sure, cgi-bin with a big load balancer

It can be, and not necessarily. `cgi-bin` can be as stateless as you want it to be. Just as stateless as lambdas, or other forms of "serverless" functions.

And thus, it can be distributed as well as any other stateless function.

Yes and no, respectively.

A cgi-bin is as highly available as the web infrastructure hosting it, which as the cgi-bin author you don't need to know anything about.

A cgi-bin cannot "crash" because there is nothing long-running to crash. It is only run on demand.

I think it is easy to make the case that CGI was the proto-serverless api and that the serverless offerings we have today are an evolution of the CGI approach.

edit: typos

And cgi-bin was really just an evolution of inetd (or ucspi-tcp if you worshipped at the altar of djb). You didn't used to have to worry about binding to ports or long running processes. Something would just send you a message on stdin and you replied on stdout.

I ran an e-mail service with 2m users. The web frontend was written in C++ (no, I don't want to go back, but we had a pretty nice custom framework) all served up as a CGI, behind a load balancer.

If our code crashed, the next request would just get served as normal. If Apache crashed or a frontend crashed, another one would just take its place. High availability cgi-bin is trivial.

That depends on you and the SLAs you have in place with your cgi-bin provider.

I don't think there's anything wrong with reinventing something to be more accessible.

Reply on news.ycombinator.com