2008年10月30日
マイクロソフトもサービスを開始して、
にわかに盛り上がり始めたクラウドコンピューティングですが、
Azure Service Platform
http://www.microsoft.com/azure/default.mspx
マシンリソースがあれば、オープンソースでシステムを構築することもできそうです。
ただ、本格的にクラウドコンピューティングとして始めると、
圧倒的多数のサーバリソースが必要になりますが…。
（電力の問題以外に、日本ですと収納スペースの問題もあります…。）
分散ストレージなどでは以下が使われているようです。
Hadoop http://hadoop.apache.org/core/
hBase http://hadoop.apache.org/hbase/
以下のリストを見る限りでは、現時点でもかなりの実績があるようですね。
大きいところでは、Yahoo, IBM, Amazon, Facebookなどでしょうか。
http://wiki.apache.org/hadoop/PoweredBy
クラウド的に使用する以外に、ある程度のデータサイズをもつサービスであれば
分散ストレージとして採用するのもありかもしれませんね。
若干変わったアプローチですが、今ある「技術」「インフラ」から新しいビジネスを生み出す。
こういう視点も必要でしょう。
"オープンソースでクラウド的コンピューティング"の詳細へ»
2008年10月27日
昨今のバズワードの一つ、「クラウドコンピューティング」ですが、
それに代表されるサービスのAmazon EC2が、ついに正式版になりました。
クラウドコンピューティングの解説はWikipediaに任せますが、
その概念の背景は、私はグリッドコンピューティングにあると思っています。
グリッドは複数台のマシン、クラウドは極論一台もありえるため別物という論調がありますが、
実際問題として、スーパーコンピュータの世界でも複数台のクラスタが当り前の世の中です。
論点として若干ズレている気がします。
グリッドとクラウドの決定的な違いは、処理する場所にあります。
グリッドはローカルマシンを含む世の中のすべての計算機が分散、協調して処理をするのが理想ですが、
実際には他組織のコンピュータリソースを利用することは、セキュリティ上の問題がありました。
その点クラウドは同一組織のデータセンターなどに集約している点が現実的で、
ローカルマシンを含まない、ネットワーククラウド内で処理されます。
まさに「クラウド」ですね。（グリッドはクラウドを内包する概念かもしれません。）
さて、EC2ですが、スケーラビリティやリライアビリティに気をとられて、
これをただのレンタルサーバとしてとらえるのは考え物です。
ローカルサーバでは処理しきれないような重たい処理、膨大な処理を
代行させることが真髄のように思えます。いわばグリッドのように。
EC2では仮想化技術でXenが使用されています。
いうまでもなく仮想化はここ数年で急速に実用化されるようになりました。
この、熟れてきた技術に概念がマッチして生まれたのがクラウドコンピューティングであり、
グリッド（分散）コンピューティング＋仮想化→クラウドコンピューティング
といえるのかもしれません。（矢印の逆は真ではなさそうですが…）
EC2ではインスタンス（実体、サーバイメージ）とストレージを分けているところも
仮想化技術をつかったレンタルサーバ（いわゆるVPS）とは違っているところです。
クラウドコンピューティングは、技術の現実と、概念の理想の折衷点に思えます。
ITシステムのパラダイムシフトがまた始まる予感がします。
"グリッド＋仮想化→クラウド？"の詳細へ»
2008年10月13日
次回に続くと言いながら、続いてなかったエントリの続き。
オープンソースの恩恵はずっと続くのでしょうか。考えてみます。
一般に、オープンソースに限らず、ソフトウェアには3種類あるといいます。
第一のソフトウェア。
このソフトウェアは、今までに無い非常に画期的な技術で、パラダイムシフトとも言える代物です。
ただし代償として、まともに動作しない部分やバグも多かったりします。
第二のソフトウェア。
このソフトウェアは、第一のものが非常に安定して動作するようになったものです。
インターフェイスなども使い易く改善されて、万人が良いソフトだと言うようになります。
第三のソフトウェア。
このソフトウェアは、第二のものから進化して、もっと使い易くなったものです。
しかし、この頃になると旧式の技術となって古くさいソフトウェアとなってしまい、
そのうち多くの人に見向きもされなくなってしまいます。
これに当てはめて考えると、
今のメジャーなオープンソースプロダクトは第二になったと言えます。
# 余談ですが、今やオープンソースメジャーアプリの一つFirefox(Mozilla)や、OpenOffice.orgも、
# 始めのころは酷かったですね。今は非常に安定して動作してくれて助かっています。
どんなソフトウェアも、そのうち第三になります。
そして、そんな時、ヒットするのは第一のソフトウェア。
その第一から第三のサイクルがソフトウェアの生存サイクルと言えるでしょう。
今オープンソースソフトウェアには、色々な種類のものが出てきました。
サーバ、ワークステーション用ソフトウェア主体だったものが、
コンシューマー向けにも、エンタープライズ向けにもソフトウェアが揃っています。
今までなかったパイが埋まって、やっとオープンソースの「生態系」といえる中に
第一から第三を包括するソフトウェアが生まれるようになったと感じています。
オープンソースという仕組み（世界）の中で、
日々様々な種類の第一のソフトウェアが生まれ、第三となって死んでいく。
技術者や研究者に第一のソフトウェアをオープンソースとしてリリースする動機がある限り、
このサイクルは続くと私は考えます。そして、その動機は十分にあるようです。
前置きが長くなりましたが、オープンソースの恩恵は今と変わらず続くようです。
ただしこれはシステムを作る側の話。
作る事も重要ですが、システムは使うことも重要です。
技術のコモディティ化によって、作る側の障壁は下がりましたが、
これらの技術をうまく生かせるエンジニアは一握りで、
今も昔も、これからも、それは変わらないかもしれません。
"技術のコモディティ化と将来(2)"の詳細へ»
2008年10月07日
前々回、.Netの話をしましたが、今回はその「フレームワーク」について。
フレームワークとは、言わずもがな「枠組み」のことで、色々な場面で使われる言葉ですが、
ことエンジニアにとっては、開発フレームワークが最も馴染みのあるフレームワークでしょう。
フレームワークを使うメリットは、
開発効率の向上が見込める点、
複数人での開発において統一的なルールとして成り立つ点、
各個人間のスキルの上下を吸収して概ね均一化できる点、
汎用的なフレームワークであれば、それを使える人材を確保しやすい点、
などが挙げられます。
つまり端的に言えば、フレームワークの使い方を知っていれば、
すぐにでもチームに根ざした開発がしやすい（程度こそありますが…）という事です。
ただ、この点「フレームワーク」はただの道具です。
IT以外にも言えることですが、フレームワークに当てはめれば
比較的容易に「何かが出来上がる」だけのこと。
真のエンジニアになるには、
そのフレームワークにある「どうしてそういう仕組みなのか」という点を理解しなければなりません。
そして、そういった考え方は「設計」というフェーズにおいて、非常に重要なファクターになり得ます。
日々、ただAPIをたたいているだけで満足していませんか？
フレームワークにある思想を理解することで、一歩先に踏み出せるかもしれません。
そのためには色々なフレームワークを試してみると良いでしょう。
今回はちょっと抽象的な話でしたが、いかがでしょうか。
一部の用語を置き換えることで、アプリ開発に限らず、色々な分野に適用できる話です。
"フレームワークはエンジニア殺し？"の詳細へ»
