ベゾスの掟とAzureと疎結合

餅は餅屋でという親からの厳格な教育の元、本は本屋で買っていたのも、今や昔。Amazonで何でも買う子に育ってしまったし、エンジニアやっているとAWSという言葉を聞いたことがないなんて不届き者はきっといない。

そんな思いの元、どうしてオンライン本屋さんが、AWSなんてクラウドサービスを作れたのか、その元になったベゾスの掟と、その後のプロセスが面白かったという話¹。そしてやっぱり核の部分はAzureのサービスのコアに相似してくるのだなと思った。そんな話です²。

結論含め、だいぶ迷子感があるのですが、一旦あげます。（そうしないといつまでも手元に残りそうなので）なので、近日大幅修正発生するかもしれない、そんな記事だと思ってお楽しみください。

ベゾスの掟からAWSへ

2002年ごろにAmazonにいたSteve Yegge氏。彼は、2011年のある日、Amazon, というかそのCEOのジェフ・ベゾス氏のマイクロマネージメントぶりを嘆きつつ³、Googleとの違いを考えていた。どうしてGoogleはプラットフォームを握れなくて、AmazonはAWSなんて作れたのか。そのきっかけは、2002年前後に勅令されたベゾスの掟。そのインパクトは、とてつもなかったとそうな。

その掟とやらは以下。他のページでもよく紹介されてきて、紹介されつくした感はあるかもしれない。ちなみに訳はDeepLを使っている。

ざーっくり言えば、なんでもAPIを介してやるのを徹底する、ただし手段はいとわない、という方針。

1. All teams will henceforth expose their data and functionality through service interfaces. (すべてのチームは今後、サービスインターフェースを通じてデータや機能を公開する。)
2. Teams must communicate with each other through these interfaces. (チームはこれらのインターフェイスを通じて互いに通信しなければならない。)
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.　(他のプロセス間通信は一切認められません。直接リンク、他のチームのデータストアの直接読み込み、共有メモリモデル、バックドアも一切認められません。唯一許される通信は、ネットワークを介したサービスインターフェイスの呼び出しである。)
4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.(どんな技術を使っているかは問題ではありません。HTTP、Corba、Pubsub、カスタムプロトコル、などなど。Bezosは気にしない。
   )
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.（すべてのサービスインタフェースは、例外なく、外部化できるように一から設計しなければならない。つまり、外部の開発者にインターフェイスを公開できるように計画・設計しなければならない。例外はない。）
6. Anyone who doesn't do this will be fired.（これをしない者はクビになる）⁴
7. Thank you; have a nice day!（ありがとうございました、良い一日を！）⁵

この御触書がまわってからというものの、Amazon内部は急速に組織的な変化を強いられたとのこと。中の人は、とてもとても大変だったらしい（人事部でマーケティングの数字が欲しい！？そんな時にもメールで問い合わせじゃないのだ。API叩いてなんぼまんぼ！みたいな感じらしい）。

例えば、部署間のやり取りで使うAPIの整備に不備があったりすると、ちょっとした同僚からの問い合わせがDOS攻撃になったり、他人のコードのデバッグも大変になってしまったらしい（それ以外にもあるのだけれども、私の今の理解力で伝えられるのはこれくらいしかないので、もうちょっと知りたい方は、是非原文へ: Stevey's Google Platforms Rant）。

これを貫いた（というか、社員たちが貫かされた）結果が、Amazonは単なるオンライン本屋さんから、SOA(Service-Oriented Architecture)ベースの組織となり、結果AWSというプラットフォームにつながったという事実は変わらない。で、そのおおもとになったベゾスの掟が有名になったのでした。

実際APIを通じて操作をするというのは、当時の他のサービスと比べても画期的だったようだ。

そうだ、Azureの話で聞いた、疎結合だ

このAWSの話を聞いて思ったのが、疎結合という概念。
先日参加した弊社のイベントでも、Azure含めたクラウドサービスの核とは何かという話で、出てきた言葉だった。正直それまで知らなった概念だったけど、クラウドアーキテクチャを考えるうえで大事な概念らしい。

最新だと思って設計したものも、公開した時にはもう古くなってしまっている！みたいな悲劇も起こり得るくらい、技術の発展の流れは速い。だから、疎結合にして、どんどん新しい部品に替えていけるように、最初から作っていかなきゃいけないのだ。

私も、まだまだこの疎結合の威力を目の当たりにしたわけでないけれども、こうやってAWSの話とか、しばやんさんのお話とか聞いていると、こういう考え方で物事を進めていく癖がつけられるといいなと思った。

1. ざ・エンジニアちっくも書きたいのですが、元々組織開発とかに興味がある人間なので、たまにこういう感じの記事書きます。ご勘弁を。 ↩

2. 弊社は、絶賛Azure推しなうなので、AWSなんて目もくれない...なんてことはないわけで。個人的には、両方を知らないAzureのいいところなんて見えてこないなと思っています。 ↩

3. まるでベゾスはファッションとデザインセンスに欠けたSteve Jobsだみたいなことを言ったりしている。共通点は、そのマネジメントのアプローチと、頭の良さとのこと。(https://gist.github.com/chitchcock/1281611) ↩

4. Steve氏曰く、これは本当に徹底するための用心棒のような人が雇われていたらしい。元レンジャー部隊、かつ元ボクサー、かつ元ウォルマートのCIOのいかついRickさんが！(https://gist.github.com/chitchcock/1281611) ↩

5. Steve氏曰く、これはジョークなんだそうだよ！そんなこと、きっとベゾスは思っていなかったはずだ、と。京都流、イギリス流、そこら辺のユーモアの流れを、ベゾスさん引き継いでいるに違いない(https://gist.github.com/chitchcock/1281611) ↩