Serverless computing has been getting a lot of attention lately. There are frameworks, a conference, some notable blog posts, and a few books (including mine). I'm really glad to see this happening. I think serverless web apps can be incredibly powerful. As an industry we have a lot of room to grow, especially when it comes to scalability and reliability.
One thing I'm concerned about, however, is that some people seem to be conflating serverless architectures with microservice architectures, often based on AWS Lambda. While there is some overlap, these are not at all the same thing. When it comes to serverless web apps, the true innovation of serverless computing isn't microservices, it's auth.
Both Auth0 and Amazon's Cognito service provide authentication and authorization as a service. They both allow you to create identity tokens that will let you access the full suite of AWS services and other 3rd party services directly from a browser. So when I see people getting all excited about moving their middle tier application server logic into dozens of microservices, I can't help but wonder if they know that they may not need that middle tier at all.
Authentication and authorization aren't exactly exciting topics. It's easy to see why these innovations have been overlooked, but they enable a different approach to building web and mobile applications than what most people are used to. Using the temporary credentials you can get from Cognito and Auth0, you can create both mobile and web applications that access databases, message queues, email gateways, microservice containers, or any of the dozens of other services that can be accessed directly and securely from a browser using a temporary token.
Not only can this greatly simplify your application (folding two tiers into one), but it also makes your app less distributed. I don't know if you've heard, but distributed computing is hard, and the less distributed your application can be, the easier it will be to deploy, test, maintain and reason about. Serverless applications have fewer points of interaction, as compared to apps with a middle-tier application server. This means troubleshooting your app means looking for problems in one place instead of hunting across tiers.
Microservices still have their place in this model, to be sure. Any operation which can't be safely or reliably performed in a client is a good candidate for a microservice. But unlike the old days of MVC application servers, this approach should be exception, not the rule. Especially with web applications, it's possible that the vast majority (90%?) of your application logic can live in the client.
The best part about this approach is that it's not some new untested form of building applications...the ideas behind client-server applications have been around for a long time. There are a lot of effective patterns to emulate. Much like REST triggered the rebirth of HTTP, I hope that serverless authentication will bring a renaissance of client-server applications, and the recognition that a middle-tier application layer is a strictly optional component of any web app.
By contrast, it still remains to be seen whether or not an architecture made of of dozens (or even hundreds) of middle-tier microservices is a good idea. While it might make sense for the huge development efforts that go on at companies like Netflix, there are inescapable trade-offs with this approach, and I certainly wouldn't recommend it to anyone as a general-purpose approach to building web apps.
Application servers were a solution to a problem. The nature of that problem has changed as technology has advanced, and our solutions should change with it. There's no reason to try to shoehorn the same old patterns into new architectures, especially when the risks of microservice architectures aren't fully understood.