サーバーレスアーキテクチャを扱った最近の文献は、その多くがクラウドプロバイダによって書かれているため、メリットを強調し過ぎている — Wisen Tanasa氏は先日のブログ投稿で、このように書いた。新たなテクノロジが現れた時には、それを採用することの意味について理解することが重要である。Tanasa氏がサーバーレスアーキテクチャの特性について、より客観的な理解を提供しようとしているのは、そのような理由からだ。
Thoughtworksの主任開発者であるTanasa氏の講演は、特徴(characteristics)ではなく特性(traits)という言葉を使うべきだ、という話から始まった。変更の余地を残す"特徴"とは違い、サーバレスアーキテクチャには、変更できない要素がある、という考えからだ。特性は固有なものでもあるので、それに抗うのではなく、受け入れる必要がある。
サーバーレスアーキテクチャは参入障壁が低い。チュートリアルに従えば、簡単に始めることができる。しかしTanasa氏は、開発者にとって当初の学習曲線こそ低いものの、事情が複雑になるにつれてその勾配は急になる、と指摘する。インフラストラクチャ・アズ・コード、ロギング、モニタリングといったものは、サーバーレスの世界でも依然として不可欠だからだ。さらに氏が注目するのは、関数を開発するのみであるという論点から、コード設計を軽視する傾向のあることだ。重要なアーキテクチャの原則を無視すべきではない、と氏は強調する。SOLIDなどの設計コンセプトは、継続的デリバリの原則と同じく、依然として重要なのだ。
サーバーレスの世界はホストレスである。動作するサーバはない。これによって実現するメリットのひとつは、運用上のオーバヘッドの大幅な低減である。アップグレードすべきサーバや、適用すべきセキュリティパッチは存在しないのだ。その一方で、アプリケーションのさまざまな種類のメトリックを監視する必要があるため、アーキテクチャのチューニング方法を改めて学ぶ必要がある。セキュリティパッチは自動的に適用されるが、アプリケーションのセキュリティプラクティスの適用は変わらないという点を、Tanasa氏は強調している。一例は、シークレットをコードに記載することだ。依然としてこれは避けなくてはならない。
ファンクション・アズ・ア・サービス(FaaS)は短命である。すなわち、サーバーレスはステートレスでもある。状態がアプリケーションに保存されないので、水平方向のスケーリングは非常に簡単だ — 単にインスタンスを増やせばよいのだ。また、ステートレスであるということは、エラーの発生余地が大幅に減少するということでもある。それと同時に、ステートレスであるということは、状態を必要とする手法をアプリケーション開発で使用できないという意味でもある。例えば、HTTPセッションを使うことはできない。
ホストレスであるということは、アーキテクチャが弾力的(elastic)であるという意味も持つ。これはつまり、リソースを手動で管理する必要がなく、リソース割り当てに関する課題の多くが解決する、ということだ。一般的には、実際に使用されたリソースに対してのみ課金される、という点もある。レガシーシステムと統合する時には、しかしながら、この弾力性が問題になる場合もある。レガシーシステムがサーバーレスの部分と同じようにスケールアップできなければ、過負荷による障害を防ぐために、負荷を制限する必要があるかも知れない、とTanasa氏は指摘する。
多数のコンポーネントがネットワーク経由で統合されるサーバーレスアーキテクチャは、通常は分散システムである。永続性はバックエンド・アズ・ア・サービス(BaaS)で行われ、コードは複数の関数内で実行され、認証やキューなどには他のサービスが使用される。分散されることにより、アーキテクチャの可用性も向上する。現在の可用性ゾーンに問題が発生している場合に、利用可能な別のゾーンを使用できるからだ。分散アプリケーションにおけるトレードオフのひとつは一貫性(consistency)である。リードアフターライトと結果整合性のふたつは、データの更新と参照において考慮が必要なBaaSの動作の例である。
BaaSではイベントをサポートすることが多いため、BaaSを利用するサーバーレスアーキテクチャはイベント駆動型(event-driven)である。これは必ずしも、イベント駆動型アーキテクチャが完全に包含されているという意味ではないが、イベント駆動型であることには多くのメリットがある、とTanasa氏は考える。ひとつの例は、コンポーネント間の結合レベルが低いことだ。デメリットとしては、システムの全体像を失うリスクが挙げられる。これにより、トラブルシューティングが困難になる可能性がある。
サーバーレスアーキテクチャがもたらす興味深いパラダイムシフトへの注目を呼びかけて、Tanasa氏は自身の講演を締め括った。ソフトウェア開発の側面で多くの改善がある一方で、開発者や開発チームが受け入れなければならない、いくつかの新たな課題ももたらすことになる。
Symphoniaに所属するMike Roberts氏は、2つのブログ記事で、サーバーレスの定義について説明している。サーバーレスアプリケーションとは、サーバーレスサービスを使用して実装されたアプリケーションであり、そのようなサービスは共通的な5つの特性を持たなければならない、と氏は主張する。
- サーバーホストあるいはサーバープロセスの管理が不要であること
- 負荷に基づいた自動スケーリングと自動プロビジョニング
- コストが使用量に基づいていること
- パフォーマンス機能がホストサイズや数以外のさまざまな用語で定義されること
- 暗黙的な高可用性を持つこと
Roberts氏は、同じくSymphoniaのJohn Chapin氏とともに、"What is Serverless？"という本を執筆した。 その中で氏らは、サーバーレスをより詳細に定義するとともに、サーバーレスが他のクラウドネイティブのアプローチとどのように異なるかを説明している。
Jonas Bonr氏は今年初めのブログ記事に、サーバーレスのムーブメントは強く支持するが、サポートするユースケースを制限するという理由から、ステートレス関数のみに注目するべきではない、と書いている。
Martin Fowlerは2017年のブログ記事で、イベント通知のリスクを取り上げて、イベント通知パターンが有用である可能性を認めると同時に、全体的なフローの観点を失うリスクを付け加えている。