N層サービスとシステム複雑性
Steve Yeggeが2004年にAmazon内部で書いたエッセイ。内部データサービスがシステム全体の複雑性を減らしたのか、単に移したのかを問う。サービスAPIの2つの失敗パターンを指摘し、新しいクエリ言語の必要性を予言。2012年にFacebookがGraphQLとして実現した。
2004年11月、Steve YeggeはAmazon内部で「N層サービスとシステム複雑性」というエッセイを執筆しました。このエッセイは2006年3月に「Drunken Blog Rants」で一時公開されましたが、CTOのWerner Vogelsの要請でわずか5日で削除されました。理由は内部サービスアーキテクチャを赤裸々に語りすぎたためです。幸い、Yeggeの旧サーバーcabochon.comのバージョン管理履歴に残っており、20年後に復元されました。
エッセイの核心は単純な問いかけです：Amazonの内部データサービス（Customer Master、Order Master、Item Masterなど）は全体のシステム複雑性を減らしたのか、それとも単に移動させたのか？アプリケーションチームの立場から、Yeggeはデータベースの分割が「2層問題」（SQLをクライアントコードに直接埋め込むことによる密結合）を解決した一方で、アプリ開発者はSQLの表現力を失い、手作りのオブジェクト指向サービス呼び出しのパッチワークを強いられたと述べています。
Yeggeは2つの比喩と9つの脚注を用いて、サービスAPIの2つの失敗パターンを指摘します：過剰取得（オーバーフェッチ）と細粒度の頻繁な呼び出し（チャティな呼び出し）です。そして解決策として、「次の論理的ステップは、クライアントのためにAPIを抽象化する新しいクエリ言語を構築することである」と予言します。この言語は後にGraphQLとして2012年にFacebookによって実現され、Yeggeが2004年に指摘したまさにその2つの問題を解決しました。
このエッセイは変換の物語ではありません。Yeggeは90年代初頭のMUD時代からプラットフォームの構築と思考に取り組んでおり、サービス指向アーキテクチャをしっかりと支持していました。彼は当時のアーキテクチャに欠けていたピースを正確に特定したのです。このエッセイは今でも面白く、Amazonが「プラットフォーム問題」に取り組んでいた時代の貴重なタイムカプセルとなっています。