[dbrueck]

I can see both sides, and have used both sides (at my last company we used 1500-2000 EC2 instances at any given time and at my current company we have one non-critical EC2 instance and then a bunch of cloud functions on Firebase/GoogleCloud, though the current company is much earlier in its life than the former one).

For a new project, serverless seems to involve a ton of momentum-stealing upfront work before you can really get going, and thereafter you do always feel one step further removed from your code, so it can be a pain to debug and troubleshoot.

OTOH, for any real production application, a single VM instance is rarely sufficient if it's critical to the business, and even within a single machine there always seem to be a lot of ops tasks like setting up process keep-alive stuff, rotating and deleting logs, making backups, etc.

For now, either approach can work great. Long term I think serverless is the way to go, but it still has a lot of maturing to do (the good news is that pretty much all of the annoyances of serverless seem like very solvable problems).

[djhaskin987]

> you do always feel one step further removed from your code, so it can be a pain to debug and troubleshoot.

This reminded me of a story I heard about RMS's kernel, GNU Hurd. Linux being built as a monolith in the 90's, Hurd was being built as a microkernel (microservices) architecture. Guess which one was easier to debug[1]?

1: https://biblioweb.sindominio.net/telematica/open-sources-htm...

[p_l]

Considering some other stories regarding how Hurd project was managed early on, the lack of appropriately capable debugger might be due to non-technical issues...