> My understanding of serverless = easily scalable, managed service.

There is already a term for that concept: managed services. There is no such thing as a managed service that's designed not to be scalable. Some implementations may be better at scaling than others, but that's it.

The serverless buzzword is pure marketing.

For me, serverless is not just "easy" scaling or a managed service, but completely automatic and elastic scaling with metered billing. If you can go from 1 to millions of requests without touching your infrastructure or dropping requests, then that's serverless. If you have to provision larger instances or even wait 10 minutes for your autoscaling policy to spin up new VMs so you can serve those requests, then it's not.

Some services labelled serverless really do reach very close to this ideal (S3, for instance), while others fall short in various ways. "Serverless" Aurora, for example, can't scale writes beyond a single instance, so while it can take you quite far (a 96 core db instance can handle a lot of writes), past a certain point it's no longer really serverless anymore since you'll have to figure out some kind of sharding strategy to keep scaling writes. With S3 or DynamoDB, this doesn't happen. While even those services do have some sanity check limitations, they can scale seamlessly up to the point where you start to approach the scale of AWS itself.

I always explain serverless as "Instead of one server you have countless servers, but they are managed by someone else".

Yes, a better word would be great. I think that ship is sailed though...

'Instanceless'. Because the difference is that you outsource and forget any questions about the instance(s) of the service (and whatever supports it, like the os process, the kernel, the vm, the real machine, the datacenter).

My understanding was that cloud = easily scalable, managed service.

serverless it mean no server but everything use servers, yep we should find a better expression.

I never found things like DBaaS annoying at all.