InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

オープン・クラウド・マニフェスト

作者 Abel Avram , 翻訳者 渡嘉敷 満理子 投稿日 2009年4月17日

セクション
運用/インフラ,
デベロップメント,
設計/アーキテクチャ
トピック
クラウドコンピューティング ,
オープンソース ,
Architecture

原文(投稿日:2009/4/1)へのリンク

無名制作者のグループが、多数の企業が署名し、オープン・クラウド・コンピューティングを求めるためのオープン・クラウド・マニフェスト(リンク)を作成した。この 文書では、顧客が持つ4つのゴールの概要が述べられており6つの原則が提議されている。このマニフェストが秘密裏に作成されたことに対し、Webでは一部 好意的とは言えない反応も生じた。

マニフェストが、クラウドでの目標を以下のように説明している。

選択性 - 組織は、様々なベンダの中から自由に選択できることとする。

柔軟性 - 組織は、異なるクラウドを使用している場合でも協力が可能であることとする。

スピードとアジリティ - 組織は、官民のクラウドを統合するソリューションを容易に作成できることとする。

スキル - 組織は、その能力を特定のクラウドに依存しないユーザにアクセスできることとする。

同マニフェストでは、今後のオープン・クラウドに対する6つの基本原則が以下のとおり提議されている。

  1. クラウド・プロバイダは、クラウドの採用(セキュリティ、統合、ポータビリティ、相互運用性、ガバナンスとマネジメント、計測と監視)に対する課題が、オープンなコラボレーションや規格の適切な使用を通じて確実に対処されるよう協力し合わなければならない。
  2. クラウド・プロバイダは、市場での地位を利用して顧客を特定のプラットフォームに縛りつけたり、プロバイダの選択を制限したりしてはならない。
  3. クラウド・プロバイダは、既存の規格が適切である場合は、それを使用および導入しなくてはならない。IT産業は、これまで既存の規格や標準機構に重点を置いた投資をしてきた。したがって、それらの複製や改変は不要である。
  4. 新たな規格(または、既存規格の調整)が必要となった場合は、余分な規格を作らないよう適切な判断を下し現実的でなくてはならない。また、規格による改革の促進を確実にすべきであり、それを抑制してはならない。
  5. いかなるコミュニティの取り組みも、クラウド・プロバイダの単なる技術的なニーズではなく、顧客のニーズにより決定されるべきであり、実際の顧客の要件に対してテストや検証を行わなければならない。
  6. クラウド・コンピューティングの標準機構、支持グループ、およびコミュニティは、協力し合い、組織的な状態を維持し、各取り組みの対立や重複は必ず避けなくてはならない。

同マニフェストには、多数の企業(Akamai、AMD、AT&T、Cisco、Eclipse Foundation、EMC、IBM、Juniper Networks、Novell、Open Cloud Consortium、Red Hat、SAP、Software AG、Sun、VMwareなど)が参加している。

その一方で、ZDNetによると、Amazonは同マニフェストへ署名していないが、見逃しているわけではないようだ(リンク)。また、SalesForce.comは、まだ文書に署名はしていないものの、次のような前向きな姿勢を見せている(リンク)

われわれは、クラウドの相互運用性のゴールを支持し、Google、AmazonおよびFacebookといったパートナーとの継続的な協力とともに、署 名企業との連携にも期待しています。クラウド・プラットフォームはレガシーな前例であるクライアント/サーバ・システムに比べ、よりオープン性が高く、ま た、クラウド・プラットフォームとは、常にそうあるべきだと確信しています。なぜなら、それが顧客やクラウド・エコシステム全体にとって最適な状態だから です。

Microsoftは公式な対応はしていないが、同社グループ製品マネージャSteve Martin氏は、同マニフェストの策定方法に対する不服を次のように表明した(リンク)

1つあるいは少数の企業が、クラウド・ユーザを含む主要なステークホルダの同意を得ることに対して、「オープンな」プロセスを通じて、クラウド・コン ピューティングの発展をコントロールしようとしているように見えます。閉鎖的なプロセスから登場したオープン・マニフェストとなると、少なくともやや皮肉 な感があります。

そのようなプロジェクトへの取り組みの、オープン性、透過性および完全性を保証するには、いかなる「マニフェスト」も公の論議やコメントを求めて、開始当 初からWikiなどのオープンなメカニズムを通じて作成され、クリエイティブ・コモンズ・ライセンス(リンク)を介してすべて利用可能でなければならないと強く感じ ています。

われわれの見解では、マニフェストの草案の大部分は実用的であると見ていますが、おそらく、中には制作者の先入観が反映されている部分もあるでしょう。さらに、制作者が意図する内容があまりにも不明瞭で、正確に理解できない部分もあります。

クラウドの相互運用性や規格の原則に関して、オープンで、透過的、かつ包括的な対話がなされるなら、われわれは熱意をもって「参加」します。

同マニフェストに対するSteve Martin氏の批評に同調して、Australian Online Solutionsの創設者Sam Johnston氏は、Wiki(リンク)を設けて、今回は誰にでも解放的な新規マニフェストの作成プロセスを容易にした。当初から、一般に向けて利便性がよくな かった理由について、制作者は次のようにコメントしている。

この取り組みにかけた時間は、ほんの数週間であり、小規模なグループのアイデアとして開始されました。その後、広範囲なコミュニティにおいて、このアイデ アの共有化または形式化の必要性が明らかになったとき、他のメンバが加わり広がりをみせました。これは、その取り組みが、仕様書の作成なのか、あるいは オープン・ソース・コードの作成なのかに関わらず、いかなるクリエイティブなプロセスにもよくあることです。人は、何かに着手し、続いて、第三者の参加を 求めます。われわれは、ドキュメントに対して適切な開始をしたと思う何かを手にしたならば、より広範囲のコミュニティで、このドキュメントが理にかなって いると判断した場合に、ドキュメントを土台にできるよう、クリエイティブ・コモンズ・ライセンスのもとでリリースすることに決定しました。ところが、ド キュメントは、様々なメンバの間で反響を呼びました。このメンバとは、ドキュメントがコミュニティでリリースの準備段階に入っているにも関わらず、参加を 希望する企業や「サイン・オン」を希望する企業でした。このため、われわれは、彼らの依頼どおり、ドキュメントの公開をもう数日待ちました。こうして、こ れらの企業では、内部レビュー・プロセスの折り合いを付け、リリース前に署名することができたのです。

このマニフェストはCreative Commons Attribution-Share Alike 3.0 Unported License(リンク)にてリリースされた。陰の支持者に関する情報はごくわずかであるが、本人のブログ投稿や他の情報源によると、Enomalyの創設者 Reuven Cohen氏は、そのうちの一人(リンク)である。献身的なGoogle Group(リンク)がリストに挙げたのはたったの15名である。彼らの名前の公表が待たれる。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。