Edit: "managed cgi-bin" is perhaps more apt.
* As a synonym for dedicated hosting. E.g. you rent a machine, and run what you want on it. And have to patch stuff etc.
* As a separate tier of service above dedicated hosting where the hosting provider is responsible for running the services on the machine. Some managed hosting providers will take responsibility for scaling too, though often it will be a semi-manual process.
Managed hosting in this second sense is to serverless what dedicated hosting is to "regular" cloud instances.
Your comment did nothing to address the point, which is that your definiiton of "serverless" is actually just a buzzword used to refer to the old as the web commercial practice of managed hosting.
Serverless is not just “managed hosting” in the cgi-bin since - serverless implies there is no server to manage and it’s for all intents and purposes “infinitely scalable”.
For instance, Amazon’s hosted versions of Mysql, Postgres, Sql Server, etc are not what they consider “Serverless” you still have to size it appropriately and if your needs increase, have to move to a larger server. You have to worry about CPU utilization, memory utilization etc.
DynamoDB is considered “serverless” because you don’t have to manage any of that.
The same is the difference between S3 and provisioning storage that you attach to your VM.
Please don't digress. The questions regarding you assertions on "serverless" don't change or are addressed with your attempt to divert attentions to other buzzwords.
> Serverless is not just “managed hosting” in the cgi-bin since - serverless implies there is no server to manage and it’s for all intents and purposes “infinitely scalable”.
You're running in circles by trying to pin a buzzword on managed hosting.
> For instance, Amazon’s hosted versions of Mysql, Postgres, Sql Server, etc are not what they consider “Serverless”
I wouldn't use AWS as an example of coherent classification, as AWS's database offerings have multiple ovelapping concerns, including an overreaching gray area of "serverless-ness". See for example Amazon RDS and Amazon Aurora.
No one on HN would accept an argument that technology is “confusing” that the poster didn’t take time to learn unless it involves AWS.
You mean AWS Aurora serverless?
https://aws.amazon.com/rds/aurora/serverless/
You're underlining the failing of buzzword-driven development.
> No one on HN would accept an argument that technology is “confusing”
Good. No one other than yourself ever made the mistake of doing so. If you have a hard time arguing the facts then refrain from making up fiction.
Again, you're quite (and patently) wrong. Aurora Serverless is quite bluntly a configuration of AWS Aurora to add autoscaling to AWS Aurora instances.
https://aws.amazon.com/rds/aurora/serverless/
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
> Aurora Serverless autoscales - just like lambda.
If you're confused to the point of confounding autoscaling with serverless then I'm afraid there is no point to continue this discussion. You're just underlining the fact that "serverless" is a fad being mindlessly disseminated by clueless proponents.
We specifically could not use Aurora Serverless for our ETL jobs because of the lack of integration with S3
Again there is a difference between reading documentation and actually using it.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
I’m also not confounding “Autoscaling” and services. Being able to scale on demand and “scale down to zero” is one of the parts of how Serverless is defined.
Also, it didn’t tie in to other none web based events.
"Lambdas" don't by nature either. I can run cgi-bin in a FirecrackerVM-like ecosystem with one script per VM.
>Also, it didn’t tie in to other none web based events.
Webhooks aren't new.
I'm not disputing the popularity and convenience of serverless. I'm just noting it's somewhat like Docker. Packaging existing tech in an easier-to-use bundle.
And with webhooks I’m required to keep enough server capacity running all of the time to handle the events. Can a web hook automatically instantiate enough VMs on demand without reducing throughput?
Yes, there are various cgi-bin implementations with horizontal auto-scaling.
And you still have to provision and pay for the VM for peak load.
Lambdas do have process isolation.
See because only science has a concrete fixed point for measuring which is the speed of light.
Human culture is subjective buzzwords where the only relative fixed point is when they learned a term.
Serverless is “managed hosting 3.0”.
First there was bare metal, run your cage. Then ec2/traditional VMs. Now just an ephemeral thread.
Computer people need to stop thinking in terms used by product & marketing people. Reasoning around it from the perspective of how it’s implemented specifically helps with the understanding.
It’s a Linux OS wrapped in layers of UX to facilitate composition of services. Unix command line tools at scale.
Cloud provider is just an OS at scale. They handle CPU, memory, scheduling, etc., all the same things a desktop OS does from the end user perspective, using a different process model we don’t generally care about as end users
Hopefully OpenAPI will help normalize this interface. Who knows though. Rich people like to drag their feet when they think sticking with the status quo gives them an advantage. Bezos may feel like making it easy to copy paste away from his cloud is a shitty idea
But Lambda is more than just for APIs. But if you’re worried about the “lock in” boogeyman for APIs, there are small packages for every language that lambda supports that allows you to run your standard Node/Express, C#/WebAPI, Python/Django/Flask API, etc on lambda just by changing the entry point.
Right now I’m deploying a Node/Express app to both lambda and Fargate (Serverless Docker) withoit any code changes.