Loading article…
ISO/IEC 22123-2によると、 Function as a Serviceは「プラットフォームレベルのクラウド機能」であり、ユーザーは「拡張性のために初期投資を少なくしてマイクロサービスアプリケーションを構築および管理する」ことができる。[ 1 ]
Function as a Service は、サーバーレスコンピューティングエコシステムのサブセットです。[ 2 ]
「砂粒アンチパターン」とは、システム内で過度に小さなコンポーネント（関数など）を作成することを指し、多くの場合、複雑性の増加、運用上のオーバーヘッド、およびパフォーマンスの非効率性につながります。[ 3 ]「ラムダピンボール」は、サーバーレスアーキテクチャで関数（AWS Lambda、Azure Functionsなど）が断片化されたチェーンで過剰に互いを呼び出す場合に発生する関連アンチパターンであり、レイテンシ、デバッグとテストの課題、および可観測性の低下につながります。[ 4 ]これらのアンチパターンは、分散モノリスの形成に関連しています。
これらのアンチパターンは、公開インターフェースと公開インターフェースを区別する明確なドメイン境界を適用することによって対処されることが多い。[ 4 ] [ 5 ]公開インターフェースは、メソッド、クラス、APIエンドポイント、トリガーなど、技術的にアクセス可能なインターフェースであるが、正式な安定性の保証は付帯しない。対照的に、公開インターフェースには、正式なバージョン管理、徹底したドキュメント、定義された非推奨ポリシー、そして多くの場合、後方互換性のサポートを含む、明示的な安定性契約が伴う。公開インターフェースでは、破壊的変更が導入された場合、複数のバージョンを同時に維持し、正式な非推奨プロセスに従う必要がある場合もある。[ 5 ]
サーバーレス コンポーネント (関数) が複雑なパターンで他のリソースと相互作用するシステムでは、関数呼び出しの断片的な連鎖がよく見られます。これは、スパゲッティ アーキテクチャや分散モノリスと呼ばれることもあります。対照的に、境界がより明確なシステムでは、通常、サーバーレス コンポーネントがまとまりのあるグループに編成され、内部のパブリック インターフェイスがコンポーネント間の通信を管理し、公開インターフェイスがグループ境界を越えた通信を定義します。この違いは、安定性の保証と保守のコミットメントの違いを浮き彫りにし、依存関係の複雑さの軽減に貢献します。[ 4 ] [ 5 ]
Additionally, patterns associated with excessive serverless function chaining are sometimes addressed through architectural strategies that emphasize native service integrations instead of individual functions, a concept referred to as the functionless mindset. However, this approach is noted to involve a steeper learning curve, and integration limitations may vary even within the same cloud vendor ecosystem.[2]
Function as a service workloads may encounter migration obstacles due to service lock-in from tight vendor integrations. Hexagonal architecture can facilitate workload portability.[6]