Serving a half billion requests per day with Rust and CGI

> SEATTLE – (Nov XX, 2014) – Amazon Web Services LLC (AWS), an Amazon.com company (NASDAQ:AMZN), today announced the introduction of AWS Lambda, the simplest way to run code in the cloud. Previously, running code in the cloud meant creating a cloud service to host the application logic, and then operating the service, requiring developers to be experts in everything from automating failover to security to service reliability. Lambda eliminates the operational costs and learning curve for developers by turning any code into a secure, reliable and highly available cloud service with a web accessible end point within seconds. Lambda uses trusted AWS infrastructure to automatically match resources to incoming requests, ensuring the resulting service can instantaneously scale with no change in performance or behavior. This frees developers to focus on their application logic – there is no capacity planning or up-front resource type selection required to handle additional traffic. There is no learning curve to get started with Lambda – it supports familiar platforms like Java, Node.js, Python and Ruby, with rich support for each language’s standard and third-party libraries. Lambda is priced at $XXX for each request handled by the developer’s service and $YYY for each 250ms of execution time, making it cost effective at any amount of usage. To get started, visit aws.amazon.com/lambda.

Let me emphasize some points here:

> Previously, running code in the cloud meant creating a cloud service to host the application logic...

> then operating the service, requiring developers to be experts in everything from automating failover to security to service reliability...

> Lambda eliminates the operational costs and learning curve for developers by turning any code into a secure, reliable and highly available cloud service with a web accessible end point within seconds.

> there is no capacity planning or up-front resource type selection required to handle additional traffic

It is genuinely impressive how devastatingly, horrifically incorrect the idea is that "serverless" ever had anything to do with whether your application binary has a network request server in it. It's just not a thing.

We can talk about the parallels between CGI servers and Lambda all day and all night, but I am not letting this non-sense go. Serverless is not a marketing term for CGI.

[1]: https://www.allthingsdistributed.com/2024/11/aws-lambda-turn...

But it remains that deployment is normally considered to be independent of development. If you put your binaries on a CD instead of sending it to AWS, the application will still be considered developed by most people. Deployment is a post-development activity.

> I guess the next argument is that Amazon is just diluting the term

Could be. Would it matter? The specific definition you offer didn't even emerge until ~2023, nearly a decade after Lamba was introduced, so clearly they're not hung up on some kind of definitional purity. Services like Cloud Run figured out that you could keep the server in the application, while still exhibiting the spirit of CGI, so it is not like it is hard technical requirement, but it is the technical solution that originally emerged and was named as such.

If what you are trying to say, and not conveying it well, is that it has become a marketing term for all kinds of different things, you're not wrong. Like I suggested in another comment, there is probably a "Serverless" toaster for sale out there somewhere these days.

Yup. "turning any code into a cloud service". In other words: No need to write complicated server-bits that can be easy to screw up. Just write a "function" that accepts inputs and returns outputs and let something else will worry about the rest. Just like CGI (in sprit).

It is great that you were willing to share this as it proves without a doubt that Amazon were thinking about (the concept of) CGI during this time. But perhaps all you've been trying to say, poorly, is that "serverless" is no longer limited to marketing just one thing these days?

I loathe to be of service defending Amazon's marketing BS, but I think you're saying the selling point of AWS Lambda is that it's "like CGI", and that serverless functions are substantially equivalent to CGI. I disagree. The programming model of serverless functions is definitely substantially equivalent to CGI, but the selling point of serverless functions isn't the "functions" part, it's the "serverless" part. It would've had the exact same draw and could've even had a very similar programming model (The Lambda SDK makes your applications look like a typical request handling server, probably for development purposes) and ran multi-request servers under the hood and as long as it had the same billing and management most people would've been happy with it. The thing that unites Fargate and Lambda in being "serverless" is the specific way they're abstracting infrastructure.

Amazon could've and could still launch something like CloudCGI if they wanted to, and if it used the same model as Lambda I'm sure it'd be successful. If I had to guess why they didn't, the less cynical answer is that they just felt it was outdated and wanted to make something new and shiny with a nice developer experience. The more cynical answer is probably truer, because vendor lock-in. Even if they did launch something like "CloudCGI" though, it would still be a very big departure from anything people called "CGI hosting".

FastCGI is binary based, which has benefits, but hopefully a reverse proxy sends well-formed HTTP requests ... but maybe having the application runtime provide an http frontend encourages running the application software directly accessible, which isn't always wise... some of them are really bad at HTTP.