I don’t think it’s that complicated: If you can’t see the servers in the service, then it’s serverless. Yeah, they’re still there, but the whole point is that you can mostly not worry about them.
[This is part of the Serverlessness series.]
That doesn’t work just for functions: Lots of services, for example RDS (in certain flavors), ElasticSearch, and Amazon MQ, require that you pick an instance that the service runs on before you start. Let’s extend the nomenclature a bit; if anything requires that you pre-provision IOPS (or other unit of capacity), then that’s not so serverless.
It’s a great service, but it’s not serverless.
Etymology · Several people, starting with Werner Vogels, have griped about the name “serverless”, finding it ill-conceived and pointed in the wrong direction, preferring positive rather than negative names. Fair enough, but too bad, English is not just a living language but a hasty, impulsive, pigheaded one, and it’s settled on “Serverless” now, so just deal.
By the way, any fool can plainly see that the opposite of Serverless is Serverful, with just one trailing “l”, just like faithful, sinful, and skillful.
It’s not binary · I heartily recommend Ben Kehoe’s The Serverless Spectrum in support of this point. Let me illustrate by example: Your basic enterprise Oracle deployment is the most serverful thing imaginable; with the primary, fallback, and standby instances, it’s triply serverful! RDS Aurora Serverless is more serverless, and while DynamoDB has always been even more serverless, with the advent of On-Demand mode, it’s really serverless.
Another example: An EC2 instance is hardly serverless, a Docker container launched in Fargate is really pretty serverless, while a Lambda function is the epitome of serverlessness.
I think we are past the time to argue about what “serverless” means.
