undefined | Better HN

0 pointsjchw8mo ago0 comments

OK good point. Let's see what Amazon describes the selling point of AWS Lambda is in the original press release from 2014; in fact, so early that it's actually not even the final draft[1]. Surely it will mention something about developers no longer having to write network server applications since (apparently) that is what the "server" in "serverless" is referring to (although this draft actually predates the term "serverless" entirely.)

> 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...

0 comments

kragen8mo ago

This is great, thanks for digging it up!

It does support the thesis that Amazon was attempting to prevent customers from realizing that what they were offering was basically CGI on a big load-balanced server farm, by claiming that it was something radically new that you couldn't get before, but their value proposition is still just the value proposition of shared CGI hosting. On a big load-balanced server farm. Which, to be perfectly fair, probably was bigger than anyone else's.

There is one major difference—the accounting, where you get charged by the megabyte-millisecond or whatever. Service bureaus ("cloud computing vendors") in the 01960s did do such billing, but Linux shared CGI hosts in the 01990s generally didn't; accton(8) doesn't record good enough information for such things. While in some sense that's really the value proposition for Amazon rather than the customer, it gives customers some confidence that their site isn't going to go down because a sysadmin decided they were being a CPU hog.

I agree that there's no evidence that they were talking about "servers" in the sense of processes that listen on a socket, rather than "servers" in the sense of computers that those processes run on.

Just to be clear, I know I'm not going to convince you of anything, but I'm really appreciating how much better informed I'm becoming because of this conversation!

jchwOP8mo ago

> It does support the thesis that Amazon was attempting to prevent customers from realizing that what they were offering was basically CGI on a big load-balanced server farm, by claiming that it was something radically new that you couldn't get before, but their value proposition is still just the value proposition of shared CGI hosting. On a big load-balanced server farm. Which, to be perfectly fair, probably was bigger than anyone else's.

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".

9rx8mo ago

> but the selling point of serverless functions isn't the "functions" part, it's the "serverless" part.

Yup. That's right. The removal of the server from your application is the selling point. As you subtly hint at, exposing the application as a "function" is a clever API design to facilitate that, but I'm sure you could imagine other ways to achieve the same. It is the "serverless" part that is significant.

HTTP servers, while simple to implement in terms of basic function, aren't easy to design well. There are a lot of more complex considerations, like around security and scaling, which are easy to screw up if you don't have a good handle on what you are doing. All alleviated by just letting someone else, who specializes in it, write the server code for you. If you take the server out of your application, making it "serverless", it becomes much more difficult (I really want to say impossible, but abstractions always leak eventually) to screw that end up.

Which is a very compelling business case, allowing businesses to hire people who aren't experts (read: cheaper) in the intricacies of low level technical details that are outside of their core business logic. That's the selling feature, just like you (and Amazon) say.

Glad we got away from that bizarre definition thinking that "serverless" somehow takes physical hardware out of the picture. Maybe it has also taken on that meaning (as nonsensical as that idea is) through the twisting in the popularity wind – definitions are most definitely influenced by time — but it certainly didn't originate in that vein.

9rx8mo ago

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?

j / k navigate · click thread line to collapse

0 pointsjchw8mo ago0 comments

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...

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

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...

0 comments

kragen8mo ago

This is great, thanks for digging it up!

I agree that there's no evidence that they were talking about "servers" in the sense of processes that listen on a socket, rather than "servers" in the sense of computers that those processes run on.

Just to be clear, I know I'm not going to convince you of anything, but I'm really appreciating how much better informed I'm becoming because of this conversation!

jchwOP8mo ago

9rx8mo ago

> but the selling point of serverless functions isn't the "functions" part, it's the "serverless" part.

9rx8mo ago

j / k navigate · click thread line to collapse