Serverless Drupal in a microservices environment
Regardless of what happens to the hype, it's a good time to consider how an old monolithic application like Drupal can survive in the future. Drupal is known for being very extensible through the module system, this leads to it being easily used for quite a few things at once. Everything from user management to email list management to content production can be done with Drupal.
This massive accumulation of features is the antithesis of the serverless movement. In these cases you simply build microservices that do a very specific thing and then send it to the cloud and forget about it. The provider will do all the software updates and handle the infrastructure and this is reliable as the functionality is very simple.
With Drupal you'll have more complexity and upgrades are manual and can be somewhat of a risky business when done fully automated. Even though Drupal 8 adopts semantic versioning, the scheme does not guarantee that all the modules actually adhere to the rules of it. This is inherently shown in the example where it took a PaaS provider 540 days to create a Drupal 8 install guide because of random issues.
A lot of the architectural changes made in Drupal 8 enable the adoption of a microservice based deployment strategy using Docker and other methods, but this does not change the fact that Drupal is used for too many things at once to be carelessly deployed and maintained by a 3rd party. In addition the added overhead in Drupal 8 results in worse performance, which is not good if you're doing a single thing and doing it very well.
All in all it seems like nothing is one size fits all and expanding Drupal to microservices is likely not the ideal solution. It can function as one piece of the puzzle, providing a content field. But for a complete solution, using Drupal is no longer as attractive as it was in the age of the monolith.