分散システムの私的歴史観

温古知新という言葉がある。未来を予測するために歴史を学ぶのも１つの方法だ。ここでは自分の解釈を踏まえた歴史を述べる。
ネットワークが考案され、コンピュータを接続したとき、分散システムが誕生した。
分散システムの意義は情報の共有にある。そこで、FTPや電子メールが誕生した。
ネットワークが登場した時代、PCの性能は極めて低かった。そこで、すべての作業をサーバ上で行うために遠隔操作のプロトコルTELNETが考えられた。（この解釈は少し強引だ。必要最小限の機能として実現されたと解釈してもよい。）
やがて、PCの性能が向上するとPCでもある程度の仕事をこなせるようになってきた。しかし、PC用OS(DOS)は機能が貧弱だったので、UNIXが移植された。また、DOSはWindowsへ進化した。このころサーバとクライアントで仕事を分担するクライアント・サーバ型アプリケーション(C/S)が登場した。この時代のC/Sでは、アプリケーションのロジックはクライアント側にあり、サーバはデータベースであった。この方式はクライアント側にある程度の性能がないと成立しない。しかし、複数のクライアントを処理するサーバはもっと性能がよくなくてはならない。
やがて、ネットワークは徐々に速くなってきた。また、クライアントとサーバの性能差は厳然と存在していた。さらに、WWWが普及した。すると、多少通信が増えても、サーバ側で仕事のほとんどを処理した方が便利になった。そこで、ブラウザ、アプリケーションサーバ、データベースからなる３階層モデルが登場した。このモデルではアプリケーションのロジックはアプリケーションサーバにある。クライアントにインストールする必要がない。
いま、ネットワークの性能は飽和し、クライアントとサーバの性能差も小さくなった。そのため、リッチクライアントが必要とされている。リッチクライアントは通信量を減らし、サーバの仕事量を減らす。これはC/Sに極めて似ている。歴史は繰り返された。しかし、同じものではない。クライアントにインストールは不要だ。データベースもサービスに一般化されている。
今後、ネットワークの性能向上は容易ではない。ADSLからFTTHへの完全移行が必要になるからだ。一方、サーバ用CPUはマルチコアでどんどん速くなる。周波数競争がマルチコア競争になる。この結果、クライアントとサーバの性能差が顕著になる。すると、クライアントの消費電力を抑える方が重要になる。この結果、通信量は増やさずクライアントの負荷を減らしたくなる。
一度確立した技術はなくならない。つまり、リッチクライアントもなくならない。ただし、より複雑なロジックが主にサーバ側の負担で実行される。つまり、高機能サービスのマッシュアップが主流になる。