そもそもマイクロサービスは運用が複雑になるので、作らなくていいなら作らないほうが良いと考えているのですが、「モノリスアプリケーションと小さなマイクロサービスをいくつか組み合わせる」という考え方が今のところはしっくり来ています。

スケーラビリティが確保できるかコストが抑えれる場合に行う
ここで言うコストとは、運用にかかる時間と実費のコストどちらも指します。
デプロイ方法やログ管理であったりと、管理コストは増加してしまう部分はあるので、
何でもかんでもマイクロサービスにはしないですが、マイクロサービスにすることでスケーラビリティの確保やコストカットが大幅に望める場合に初めて検討しています。

これは前提条件として書いておくべきなのですが、昨今のWebアプリケーションは大抵クラウドサービスにホスティングされています。
確かにクラウドサービスはコンピューターリソースあたりのコストパフォーマンスが低いことがあります。
しかし独自にデータセンターを保有しているベンチャー企業は極めてまれなのと、
移行するにせよすぐにデータセンターを利用できるようにはならないもので、現状アプリケーションがクラウドサービスにおいてあることが前提にしてもよいと考えています。

サーバーレスであれば普段からサーバーを起動しておく必要がないので、処理の数に合わせてスケールアウト・スケールインしてくれるので、運用コストが下がると考えています。
例えば、サーバーレスではない、キューシステムのSidekiqなどを利用する場合は、マイクロサービス用にRedisを立てたり、ワーカープロセスを起動し続けておくVMやDockerコンテナを構築しなければなりません。
これにはこれらの監視コストや運用のコストがかかりますし、すぐに動けるSREが在籍していてシュッとインフラの構築を行ったり、Dockerコンテナの構築などが簡単にできる状況であれば良いのですが、そうでない場合もあり、難しいと感じることがあります。

ここからはAWSのサービスを例にとり、サーバーレスの技術を使ってマイクロサービスを構成するために利用するとよいサービスをモノリスのRuby on Railsで利用するキューシステムのSidekiqと比較しながらいくつか紹介します。

AWS SQS
AWSの最初期から存在しているサービスでかなり枯れています。
また、マネージドなのとAmazonの運用でもかなりの実績があり、スケーラブルについてもあまり気にしなくてもよいのが特徴です。
FIFOもサポートしているのと、Sidekiqがジョブキューのストレージで利用しているRedisのようにデータの消失リスクも重複実行のリスクも普通に使っていてもあまりないので、ミッションクリティカルな用途でも利用しやすいです。

AWS Lambda
SQSにキューイングしたJOBを実行するWorkerとして、スケールアウト・スケールインが可能なAWS Lambdaが適任であると考えています。
Sidekiqワーカープロセスの場合は、基本的にワーカープロセスを起動させ続けるので、稼働コストもかかりますし、その分運用コストもかかります。
もちろんSQSと組み合わせる際に特別に考慮するべき部分はあると思いますが、それでもスケールアウトするWorkerとして適任であることに変わりはありません。

以上のことから、クラウドサービスのサーバーレスを構成する技術を利用してマイクロサービスを実装することで、
一部スケーラビリティが必要なマイクロサービスについては既存のクラウドサービスのコンピューティングリソースをいい感じに利用することができます。