サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services

Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方

[syu-m-5151]

アーキテクチャの進化に伴い、Lambda関数の設計には単一責任からLambda-lithへの移行があり、各トレードオフが存在。このブログでは、読み書き操作を分離することで、これらの利点を組み合わせる方法を解説しています。

[JGEEM]

この比較表は良いな。が、Lambda-lithの利点にある「凝縮度の向上」「メンテナンスの簡素化」は違和感。目的の異なる似た処理を集めてるように見えて、不幸の始まりを予感させる

[lizy]

どちらかと言うとlambda-lithから始まってでかくなって分割→分割単位見直しという流れになりそう

[kzm1760]

なるほどこういう考えは足りてなかった"単一責任 と Lambda-lith (Monolith な Lambda という意味の造語) "

[emt0]

ラムダリスはあんま良いパターンに見えないけどメリットあるのか。CQRSはDBの考えが古い人居ると大体駄目になる。何で分けるんだとか整合性とか言って提案しても面倒じゃん言われる。

[masatotoro]

CQRSでAPI Gatewayの後ろがSQSになってる

[clubman023]

わかりやすい

[tmatsuu]

1つのLambdaにまとめることをLambda-lithということを知った。そしてオススメは読み込みと書き込みの分離と。なるほどですね。あなたのLambdaはどれかな？