As indicated by Amazon's promo materials for AWS Lambda, the service fails on the critical path. It works well as "glue" connecting disparate services. That's how Amazon uses Lambda internally and did so before commercializing it. It's a bad proposition as host for always-on services.
I have dabbled in serverless while working on hobby and commercial projects. Out of the few things I did, I used serverless to track visitors across websites by generating unique IDs for them and even ran a serverless webserver written in Express and Ember. After working with AWS Lambda for a while I can't recommend it for most cases. It sounds good as a concept but is difficult to use in practice in small to mid-size projects.
For example, it prevents storing runtime data for long periods of time. AWS Lambda can only run code for up to 15 minutes before terminating. One can communicate with a cache server and send data there before losing it and retrieve again when a new Lambda starts. But doing so is counterproductive. It unnecessarily complicates software architecture. And, while serverless can start and stop as needed, the caching server needs to run all the time.
Data cannot be persisted for longer either. There's Amazon Aurora, which is Amazon's serverless-like DB for those wanting a database with similar scaling strategy to serverless. But there aren't many similar offerings by companies other than Amazon and using a conventional database on a VPS is, again, an easier strategy. The traditional approach still allows scaling and oftentimes comes without any loss of data and minimal downtime.
There are many things to like about Lambdas. There are already a lot of services offered by AWS which can call Lambda natively. They're easy to setup as part of a large system and after a few years Amazon worked out many of their kinks. It's now possible to prevent the abuse of AWS functions by setting scaling limits. It now supports multiple programming languages out of the box and can run any arbitrary code if needed. Local testing is simple with the use of official Docker images and the AWS cli tool. And, of course, serverless has different running and maintenance strategies than regular VPSs. It boots up whenever needed and otherwise stays off taking no resources and money. That's great in certain situations. It also requires less upkeep if the service can work within its limitations. Using serverless encourages good practices. Long cold starts force optimizing services and reducing the number of packages pulled from the web to run them. It forces thinking about interfaces. If the codebase for each Lambda function is small there have to be many of them to cover a project's functionality. Each needs an interface to be accessible. This quickly develops eloquence producing sensible interfaces. Code becomes more functional and pluggable due to the inability to store data and being able to run just a single function for each Lambda instance. I like the idea of eventual consistency too. It requires careful planning and making few assumptions about the flow of data between services. But when done properly, it has the potential to produce a resilient system.
Taking all these benefits into account, though, I still think the best choice is to build up discipline and transfer the good parts of serverless programming to VPSs.