The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way.
With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to:
* Manage/deploy servers
* Monitor/maintain/upgrade servers
* Figuring out tools to deploy your app to your server
* Scaling an app globally.
* Coping with outages in a data-centre/availability
* Worry about load-balancing & scaling infrastructure
Heroku is a bit higher level. If you're using heroku, you're using their blocks and their methods of passing traffic, logging, etc. With lambda, it's just a function. You have to connect everything yourself, not you can do it exactly the way you want.
It's just code with basic function entry point. You may get your parameters and configuration in a different way, but not much else changes. There are only so many ways to call some code.
Which is probably when you need to re-architect, anyway. There are also several optimizations that can be made along the way to reduce costs. I think there are plenty of ways to think of problems from a serverless standpoint that really don't need to go the traditional server route. I also think there are plenty of use cases where serverless may very well be a problem, that's okay.
