I appreciate the meme and get it as a response to everything being "serverless" recently. But I noticed some people started repeating it unironically, like cgi-bin was actually equivalent. I wish this project at least acknowledged it's a meme reaction. Maybe people these days don't remember anymore what cgi-bin really worked like? (or never worked with it?)
I think you're the one mistaken, here. The interface for cgi-bin was that you created a process per web request. The interface for Serverless is that you create a process per web request.
The tooling is a lot better for Serverless, but I'd hesitate to call it 20 years better - I'd hesitate to call it 10 years better.
> The interface for Serverless is that you create a process per web request.
That is not how it works in the most popular solutions. Both aws lambda and Google cloud functions will keep the server instance running after your first request and only dispatch function calls - you can cache data between requests in globals. That's also why the first cold request is so much slower (it actually loads the code for the first time).
Most serverless function environments are much closer to managed fastcgi, than old cgi-bin approach.
Managed FastCGI with guaranteed execution environment, integrated deployment process, aggressive autoscaling and billed for usage rather than provisioned resources.
No, you tell heroku how many dynos you're going to pay for, and you pay whether you fully utilised them or not. With lambda you don't declare that up front and get billed only for what was served.
I'd rather say it's worrying how millenials+ raised in post-standard cloud times are in denial of just how much they dropped the ball and are being brainwashed to believe the cloud progress narrative where there is only centralization and monopolization. Self-delusion to stay relevant in the job market.
I don't think you're fair here. There definitely are some that blindly believe the hype, but I met many who clearly see through the bullshit. Mostly, it boils down to the crucial distinction: are you building the project for someone else or for yourself? If for someone else, of course you want to maximize your revenue, and here the complexity of AWS &co. is an advantage. However, if you're building something for yourself, unless you're stupid you'll calculate well and choose the option that makes most business sense. In many case this means renting a server or a couple of servers for a flat rate.
The sad piece of truth in your comment is that there are actually people who seem to know only AWS (etc.) and use it for everything, whether it makes sense or not. Well, that's their choice.
That's a great point - that there are of course those who ride the cloud wave to milk their customers.
To get a sense of how much we're putting the cart before the horse, I recommend taking an occasional look at a subreddit frequented by webdev bootcampers (eg. [1] where they're hellbent to justify using React for static sites, because that's all they really know, and even accuse dissenters of being hiveminded).
I feel you're misrepresenting that discussion. Most people say they shouldn't use react, some propose react to generate static content before deployment, few raise good points for why you may want to use react even if the page is static right now. There's always going to be an extremist opinion somewhere, but it's really not common in the discussion you linked.
Maybe I'm biased because I've been downvoted. IMO /u/webdev has become a React echo chamber if there ever was one; it's actually encouraging to hear that you've got a different impression.
This is a great point. If we didn't host our own servers, we'd be on the line for thousands more than we currently pay.
It's only sheer force of keeping servers internal that we've had the expertise and knowhow to host our platform ourselves.
Now that we're the size that we are, the platform is crazily reliant on hosting it ourselves for administration and liability, so we'd need to have migrated anyway.
Funny, reminds me of the whole cloud-to-butt thing.
On a different note, the whole serverless thing seemed weird to me until I looked into it an realized that it kind of is cgi-bin all over again.
I love it, someone else can manage and patch the server and worry about scaling. I just deploy my workload as a self-contained app or set of apps. Scale is only limited by the bank account.
It’s a really apt comparison. Before PHP and embedded scripting with HTML, and entire contained applications with MVC frameworks, we had our static HTML and our CGI.
Now we have serverless and HTML that talks to our cgi-bin using JavaScript. Life is full circle. Client/server back to the cloud, which reminds me of the dumb-terminal/mainframe days.
But the key difference is in the "why". Serving that HTML from a nearby web server is a lot faster, and it's easier to distribute static content to a bunch of servers around the world that are near the people requesting them.
Fixing this for you -> "serving a multi-megabyte bundle of Javascript that renders the entire page through DOM manipulation" from a nearby web server is a lot faster, "in some cases almost being as fast as fetching a single HTML file from across the world."
Ok I’ll bite. The argument here is that serverless is similar to cgi (common gateway interface, the original way a web server handed requests to an executable) in that they both spawn a process for each ‘dynamic’ backend request (static files are served from a cdn in serverless model).
This is of course a false and misleading analogy - the reason spawning a new process for each request is bad is that it doesn’t scale on a single server, but in the serverless model the infrastructure serving this is scaled up exactly so you don’t have to worry about this aspect.
Response times are measurably very good for go python and js, in our experience, and aws serverless will try to reuse you running process for subsequent requests (warm start).
And most importantly — there are no servers to manage.
> Response times are measurably very good for go python and js, in our experience, and aws serverless will try to reuse you running process for subsequent requests (warm start).
This is because most modern serverless implementations are closer to FastCGI (which had similar benefits over classic CGI). But the concepts are the same.
Back in the day having fixed up front costs was considered a benefit and the "as a service" model was called rent seeking.
But even then you could buy shared hosting just as simply as you can sign up for "serverless" services. Some ISP's would even give you shared hosting as part of your internet connection. In many universities you could drop a script in your home directory and it was instantly available to the world.
Even further back owning and hosting your own server was a dream almost no one could afford. People had to upload their serverless code to time sharing systems.
No, you just rented an account on a shared host. My first job after uni in the 1990s was looking after Demon Internet’s web servers, which were all like 1000 accounts/sites per server.
32 comments
[ 1.8 ms ] story [ 78.5 ms ] threadThe tooling is a lot better for Serverless, but I'd hesitate to call it 20 years better - I'd hesitate to call it 10 years better.
That is not how it works in the most popular solutions. Both aws lambda and Google cloud functions will keep the server instance running after your first request and only dispatch function calls - you can cache data between requests in globals. That's also why the first cold request is so much slower (it actually loads the code for the first time).
Most serverless function environments are much closer to managed fastcgi, than old cgi-bin approach.
This is mentioned right in the service docs: https://cloud.google.com/functions/docs/concepts/exec#functi...
Also, thanks for proving my point - some people don't understand it's a meme, not real equivalence.
I get it, it's nice, but I agree with others it's mostly a nice extension and better api for CGIs. Oh, with better marketing of course.
The sad piece of truth in your comment is that there are actually people who seem to know only AWS (etc.) and use it for everything, whether it makes sense or not. Well, that's their choice.
To get a sense of how much we're putting the cart before the horse, I recommend taking an occasional look at a subreddit frequented by webdev bootcampers (eg. [1] where they're hellbent to justify using React for static sites, because that's all they really know, and even accuse dissenters of being hiveminded).
[1]: https://www.reddit.com/r/webdev/comments/cxfvcw/is_react_sti...
It's only sheer force of keeping servers internal that we've had the expertise and knowhow to host our platform ourselves. Now that we're the size that we are, the platform is crazily reliant on hosting it ourselves for administration and liability, so we'd need to have migrated anyway.
On a different note, the whole serverless thing seemed weird to me until I looked into it an realized that it kind of is cgi-bin all over again.
I love it, someone else can manage and patch the server and worry about scaling. I just deploy my workload as a self-contained app or set of apps. Scale is only limited by the bank account.
[1] https://chrome.google.com/webstore/detail/millennials-to-sna... [2]https://gizmodo.com/new-york-times-issues-correction-after-e...
Now we have serverless and HTML that talks to our cgi-bin using JavaScript. Life is full circle. Client/server back to the cloud, which reminds me of the dumb-terminal/mainframe days.
This is of course a false and misleading analogy - the reason spawning a new process for each request is bad is that it doesn’t scale on a single server, but in the serverless model the infrastructure serving this is scaled up exactly so you don’t have to worry about this aspect.
Response times are measurably very good for go python and js, in our experience, and aws serverless will try to reuse you running process for subsequent requests (warm start).
And most importantly — there are no servers to manage.
This is because most modern serverless implementations are closer to FastCGI (which had similar benefits over classic CGI). But the concepts are the same.
Back in the day, deploying code to cgi-bin first required buying and hosting your own server; which I have neither the time or patience to do today.
But even then you could buy shared hosting just as simply as you can sign up for "serverless" services. Some ISP's would even give you shared hosting as part of your internet connection. In many universities you could drop a script in your home directory and it was instantly available to the world.
Even further back owning and hosting your own server was a dream almost no one could afford. People had to upload their serverless code to time sharing systems.
Building and hosting your own server was prerequisite for having hacker cred in the 90s.
Maybe ‘Electron’ can be replaced by ‘JVM’?