Function as a service

「砂の粒（Grain of Sand）アンチパターン」とは、システム内に小さなコンポーネント（関数など）を大量に作成することを指す。これは、多くの場合、複雑さの増大、運用上のオーバーヘッド、およびパフォーマンスの低下を招く原因になる^[3]。

これに関連するアンチパターンである「Lambdaピンボール」は、サーバレスアーキテクチャにおいて、関数（AWS LambdaやAzure Functionsなど）が断片化されたチェーンの中で互いを過剰に呼び出す場合に発生する現象である。これにより、レイテンシ、デバッグやテストの課題、そして可観測性の低下が引き起こされる^[4]。これらのアンチパターンは、分散モノリスを形成することにつながる。

これらのアンチパターンへの対策として有効なのが、「パブリック（Public）インターフェース」と「パブリッシュ（Published）インターフェース」を明確に区別し、適切なドメイン境界を設けることである^[4][5]。

パブリックインターフェースは、メソッド、クラス、APIエンドポイント、トリガーなど、技術的にアクセス可能なインターフェースであるが、正式な安定性を保証するものではない。一方、パブリッシュインターフェースは、正式なバージョニング、詳細なドキュメント、定義された非推奨ポリシー、および多くの場合は後方互換性のサポートが含まれます。また、複数バージョンを同時に維持することや、互換性を損なう変更（破壊的変更）を行う際に、正式な非推奨プロセスを踏むことが求められる^[5]。

関数呼び出しが細切れに連なるチェーンは、サーバーレス関数が複雑なパターンで他のリソースと相互作用するシステムでよく見られ、「スパゲッティアーキテクチャ」や「分散モノリス」と呼ばれる。 一方、境界が明確なシステムでは、サーバーレス関数を凝集度の高い（まとまりのある）グループとして組織化する。そして、グループ内の通信は内部のパブリックインターフェースで管理し、グループの境界を越える通信のみを公開インターフェースとして定義する。このように区別することで、安定性の保証やメンテナンスへのコミットメントが明確になり、依存関係の複雑さを軽減できる^[4][5]。

さらに、サーバーレス関数を過剰につなぐパターンへの対抗策として、個々の関数（コード）を書くのではなく、クラウドベンダーの「ネイティブ機能の統合」を重視するアーキテクチャ戦略（ファンクションレス・マインドセット）が採用されることもある。 ただし、このアプローチは学習コスト（学習曲線）が高くなる傾向があり、機能の制限や仕様が同じクラウドベンダーのエコシステム内であってもサービスごとに異なる点に注意が必要である^[2]。

Function as a serviceのワークロードは、ベンダーとの強固な統合によりサービスロックインになり、移行の障害に直面する可能性がある。ヘキサゴナルアーキテクチャは、ワークロードの移植性を促進することができる^[6]。

• As a Service
• Common Gateway Interface
• サーバレスコンピューティング
• Serverless Framework
• 個別のサービス
  • AWS Lambda
  • Google Cloud Functions