At Arist (YC S20) we've found that we can have our cake and eat it too by using Ruby on Jets, which is a nearly 100% drop-in replacement for Rails that runs on AWS Lambda. Our service sends messages to hundreds of thousands of people at scheduled moments in the day, and traffic is incredibly spikey, so combining the productivity of Rails and the Ruby ecosystem with the cost effectiveness and scalability of Lambda was a no-brainer. It also passed muster recently when we subjected our platform to a comprehensive penetration test.
We also get the benefits of a mono-repo and the benefits of microservices in the same application footprint, because every controller method is automatically deployed as its own independent lambda (this is core to how Jets works), but we're still in the usual Rails mono-repo format we all know and love. Also very strong integration between ApplicationJob and background lambdas has been killer for us.
One thing I've always said is the real difficulties in software development happen at the seams where services connect with other services. This sort of strategy (and particularly, the mono-repo format) minimizes the number of seams within your application, while still giving you the scalability and other benefits of microservices and serverless.
We also get the benefits of a mono-repo and the benefits of microservices in the same application footprint, because every controller method is automatically deployed as its own independent lambda (this is core to how Jets works), but we're still in the usual Rails mono-repo format we all know and love. Also very strong integration between ApplicationJob and background lambdas has been killer for us.
One thing I've always said is the real difficulties in software development happen at the seams where services connect with other services. This sort of strategy (and particularly, the mono-repo format) minimizes the number of seams within your application, while still giving you the scalability and other benefits of microservices and serverless.