サーバレス開発における難しさ
ストレージ選択の難しさ
アプリケーション開発においては作り込まれたデータモデルを構築することこそがスケールするアプリケーションを作る方法とも言えるが、大抵DynamoDBのようなクラウドネイティブなDBをAWS公式ドキュメントですら勧めてくるが正直DynamoDBのような非RDBMSは勘所をつかまないとまともなデータモデルを作れずにその場しのぎのアドホックなデータモデルを作り、爆死する可能性が高い
クセの強い仕様(GSI、ベストエフォートでのTTL等)
ストレージまで手の回らないことの多いサーバレス開発においてはただでさえデータモデルを作り込めない中でデータモデルの作り込みまでやろうとすると難しい選択肢を迫られる
ストレージ特性から言ってRDBMSとは別物といっていいレベルなのでストレージ特性にあったデータモデルでないと保守出来ずに死ぬ
RDBMSに求められるようなタスクをDynamoDBで実現しようとすると、一見出来てるように見えるが誰もメンテ出来ないアプリが出来上がる可能性が高い
Backend, Frontendで必ずしも同じ言語でやる必用もないのでPolyglotな環境でそれぞれのタスクに最適な言語を選ぶのがやはりベストではある
人を増やせないような場合は1人でフロントとバックエンドもフルスタックに書くためサーバレスという選択肢はある
SSR/CSRでバックエンドにRDBMSを置いてAPIを作るのが安牌ではある
Lambda FunctionのCold Start等他にも考慮する点が多い
サーバサイドの制約や安定性と引き換えに委譲した責務をクラウドネイティブに解決しようとする際の問題ではあるのでクラウド特有のドメイン知識に精通していれば使うという選択肢は生きるが少なくともPoCなしにプロダクション運用出来るものは作れない
クラウドネイティブな機能に多くのことを委譲しているので昔動いたアプリケーションがクラウドの仕様変更に動かない、作り直しが必用になる可能性もある
性質上クラウト環境と密結合しやすいので移行等のBCPプランが作りづらい
マネージド系コンポーネント特有の制約への理解も求められるためトラップが多いと言える
特定の制約のため過度にコストがかかったりWorkAroundが求められケツが決まってるような開発の場合想定通りに行く保証をしづらい
十分なPoCが出来ず厳密なスケジュールを求められる場合には向かない
ピタゴラスイッチとなりクラウド上でしか動作を再現出来ないようなアプリケーションになりやすい
メンテが難しく長期的なスケールには向かない
詳細の隠蔽
ストレージとインフラが隠蔽されること
メリットでもあるが要はバックエンドが隠蔽されるためバックエンドの空気を読んでデプロイしないといけない
それがHTTPなどの後公開されたプロトコルの上に成り立っているならある程度原理原則は推測出来るがVercelなどプラットフォーム特有のビルド手順などが追加されるとそのプラットフォームと一連託生になる
サーバレスというのはサーバがないわけではなく隠蔽しているだけなのでそのブラックボックスになった部分が公開されたプロトコルでない限りなんらかのトラップにハマる可能性が高い
ピタゴラスイッチとなりやすい理由でもある
特にサーバレスSaaS提供側のセールストークをそのまま受け取ると問題になる可能性が高い
要はそううまい話は世の中にない