アマゾンでデータベースのパフォーマンスが問題になったとき、口のうまいセールスマンに勧められるまま、メインフレームを購入した。しかしビッグアイアン（メインフレーム）では問題は解決しなかった。これは技術的判断の誤りであり、ボーゲルス氏は今でもそれを後悔しているという。

　「1999年当時のインターネット企業の例に漏れず、われわれもメインフレームを買った」と同氏は話す。しかし、拡張性、信頼性、パフォーマンスのすべてにわたってニーズを満たすことができなかったため、アマゾンはこのハードウェアの電源プラグを引き抜いた。

　ボーゲルス氏によると、アマゾンをこれほどまでに有名な企業にした“秘密のソース”については、さまざまな意見があるという。同氏の意見は、「秘密のソースとは、規模拡大時における運用の信頼性である」というものだ。

　6000万人の顧客にサービスを提供し、彼らをすべて満足させるためには、スケーラビリティと信頼性が求められ、それは、大抵のSOA開発者／アーキテクトがプラットフォームに織り込む必要があるとしているレベルを上回るだろう、とボーゲルス氏は話す。例えば、大多数の顧客はオンラインショッピングカートに20冊の本あるいは20個の品物を入れたら、たくさんの買い物をしたと思うかもしれないが、アマゾンは6000万人の顧客の中の1人がショッピングカートに2万個の品物を入れた場合にも対応できるようにしておく必要があるという。

　1999年のメインフレーム導入で失敗した後、アマゾンは2001年ごろ、同社が必要とする信頼性と拡張性を実現するためには、Webサービスの手法を採用することにより、オンラインアプリケーションとの直接的なやりとりでデータベースの処理能力がパンクするのを防ぐしかないという状況に到達した。

　「SOAが流行語になる前から、われわれはそれを実践していた」とボーゲルス氏は話す。

　アナリストカンファレンスなどでの講演者の多くとは違い、ボーゲルス氏は、SOAが優れた戦略なのか、あるいは実現可能な理論なのかについて、回りくどい言い方をしない。同氏はプレゼンテーションの冒頭、「サービス指向は有効だ」と言い切った。

　アマゾンはLinuxで動作するブレードサーバで成功したといわれているが、「サービス指向なしでは、決してこのプラットフォームを構築することができなかっただろう」とボーゲルス氏は話す。

　ボーゲルス氏は、アマゾン社内の開発者の組織についても言及し、チーム方式を採用していることを明らかにした。各Webサービスは、1組の開発者チームが責任を持って担当するという。各チームはサービスを開発するだけでなく、それをテストし、最終的に本稼働させるまで責任を持ち、その後はチームのメンテナンス担当者が管理する仕組みになっている。

　ボーゲルス氏はWebサービスチームのメンバーに、「君たちが作り、君たちが所有するのだ」と話している。

　これは、各チームがWebサービスの運用にも責任を持つことを意味する。Webサービスが真夜中に停止すると、チームのメンバーが修理のために呼び出されるのだ。

　「開発には終着点がない」というアマゾンのポリシーは、開発者にWebサービスをできる限り堅牢なものにしようという気にさせるのだ。

　システムの複雑さは信頼性の敵であるため、ボーゲルス氏は開発者に対し、Webサービスをできるだけシンプルなものにするよう促しているという。

　「シンプルさは最も厳しい設計基準だ。サービスをデザインするに当たり、われわれは『もっとシンプルなサービスを作ることはできないだろうか』と常に自問している」（ボーゲルス氏）

　ボーゲルス氏が強調するもう1つの設計基準は、特定の技術や標準に固執しないということだ。アマゾンの開発者は顧客のニーズからスタートし、それから、彼らの役に立つ技術はどれかという検討に入るのだ、と同氏は話す。

　この方針は、Webサービス標準の実装に対しても適用される。ある小売りパートナーがSOAPを利用したがっており、別のパートナーがREST（Representational State Transfer）を利用したがっていれば、それぞれが求める標準に対応するようにしているという。

　「当社の開発者は、SOAPにもRESTにもこだわっていない。すべては顧客次第なのだ」（ボーゲルス氏）