Serverless usually means that the servers are 'hidden' from the user. You only get one shell, one desktop environment, but on the backend, your session might be split between multiple servers. Or it might not be. You, as the user, won't know. It is basically an abstraction layer between you and the servers themselves.
To add, it is typically manifested as generic 'compute' or in the case of azure 'functions' where you environment the code is running on is abstracted away, instead you are just paying for compute, e.g. this function takes x time/cycles to run and so it costs y to run it each time.
In theory you don't need to worry about scale or anything, just deploy your function, and pay for what it uses.
Yeah better get really good at paying unexpectedly high invoices. Or if you want to know ahead of time what your costs will be, hire three specialists who will monitor your not servers as their full time job and make sure your „functions“ are not bankrupting you in a month.
If you think you sleep too well, go serverless you’ll never sleep well again.
Serverless means you don't have a server running 24/7 that's sitting idle waiting for requests. When a user makes a request on a webpage/app it'll run a short lived piece of code for a few dozen milliseconds then shuts off. No permanent "server" running. Of course there's servers running the code to start that function and usually a permanent database server but the main app/website code is running on demand only.
There's a few advantages. No server maintenance is one, but the main benefits are scalability and cost. Renting a server is expensive and is billed regardless of usage per month. Serverless is billed in 10 millisecond blocks so you only pay for each request essentially. Since it creates one compute function per request, it will more easily scale up to meet a surge of users. Of course with any trendy technology it can be misused to situations where it's not a good fit and lose the cost and scalability benefits.