Serverless implies a very high level of abstraction when interacting with cloud infrastructure. Traditionally app developers have consumed cloud infrastructure on the level of individual boxes running operating systems. Obviously these don't usually correspond to actual physical machines, but the OS box is the unit of abstraction presented to people running building and deploying cloud apps. Serverless apps are typically based on the "function" (one invocation of some small bit of logic) as the unit of consumption for cloud infrastructure - e.g AWS Lambda. They also typically embrace high-level abstractions for managing data - e.g. building against DynamoDB as opposed to your own Cassandra cluster running on EC2.
The term "serverless" is annoying as heck. I mean, sure, you're not fiddling with nginx configs, but you're even more tightly dependent on running in a cloud environment. It really should be "servermore".
At some point, the new hotness will be the old tiredness, and the cycle will repeat.
Its kinda equivalent to a timeshare condo vs renting a condo. Your functions only run when they are called.
>When I say serverless, I’m referring to the function-as-a-service pattern. A serverless system must scale dynamically per request, and not require any capacity planning or provisioning. For instance, you can connect to FaunaDB serverless cloud in moments, and scale seamlessly from idea to runaway hit.
So, not AWS lambda then. With their concurrency limits, one-lambda-function-per-kinesis shard architecture, gateway request per second limitations, API count limitations, payload limits...