> I've seen this called Function as a Service and honestly I think using that term instead of Serverless would go a long way to fixing this issue
But "Functions as a Service" doesn't cover what it is, though.
The following AWS services are "serverless" but would not be "function as a service:"
* S3
* API Gateway
* SQS
* SNS
* Cognito
* DynamoDB
* CloudWatch (logs and metrics)
* Step Functions
In all cases, you are not provisioning or managing servers. Scaling is linear and costs are linear based on how much you use them, and typically based on what's actually being used (bytes stored, requests made, etc.) and not per-node. Because they're all hugely multi-tenant, they also cost almost nothing to use at low scale.
"Functions as a service" covers serverless compute, but it doesn't cover the huge architectural difference (from the developer's perspective) between the services above and rolling your own (for example) S3.
If we're qualifying anything on a server that developers don't have to manage themselves as serverless than anything with an API becomes serverless...despite all of them actually running on servers.
OK. I guess to me categorizing those things in the same bucket as EC2 or Salesforce is missing a pretty fundamental architectural difference and benefit. I'm not claiming "serverless" is an ideal term, but I haven't seen the case made for anything better.
The distinction I've heard and make (regardless of serverless being the right term) is that these infrastructure services expose their control plane and data plane without tying you to the concept of a particular machine. Compare this to all publicly available forms of RDS where I still have to think in terms of machines for scaling and management.
But "Functions as a Service" doesn't cover what it is, though.
The following AWS services are "serverless" but would not be "function as a service:"
* S3
* API Gateway
* SQS
* SNS
* Cognito
* DynamoDB
* CloudWatch (logs and metrics)
* Step Functions
In all cases, you are not provisioning or managing servers. Scaling is linear and costs are linear based on how much you use them, and typically based on what's actually being used (bytes stored, requests made, etc.) and not per-node. Because they're all hugely multi-tenant, they also cost almost nothing to use at low scale.
"Functions as a service" covers serverless compute, but it doesn't cover the huge architectural difference (from the developer's perspective) between the services above and rolling your own (for example) S3.