新しい JClouds 1.0 リリースの目標は、多くのベンダー、プロバイダー、IaaS から PaaSまでのフレームワークとAPIを跨いだ、計算ノードとストレージノードを管理する共通のインターフェースを提供することだ、と JCloudsの設立者である Adrian Cole氏が言っている。
JCloudsは世界中の30の色々なプロバイダーをサポートしている。開発者と DevOps は、 Apache Whirr （Hadoop, HBase, elasticsearch, Voldemort などようなクラウドサービスを走らせる）あるいは、Pallet（クラウドコンピューティングリソースのプロビジョニング、設定、管理用のライブラリ）のような下流のツールから JCloudsを使ったり、APIやantタスクを介して直接JCloudsを使う。
InfoQは Adrian Cole 氏と情報交換する機会があった。氏は JCloudsの設立者で、クラウド相互運用性と devops 世界における、積極的なコミュニティリーダーである。
InfoQ: JClouds 1.0リリースに追加された主要なものは何ですか？
JClouds 1.0.0には、かなり多くの新しいことがあり、全部言うのは無理ですが、重要なものには次のものがあります。
ユーザビリティに関しては、 David Santiago とMattias Holmqvistの両氏がblobstore と 計算クロージャのAPIを完全に改造して、言語にもっと合った感じにしてくれました。 Tim Peierls氏は BlobStoreのJava APIを修正して、もっと直感的に書けるようにしてくれました。
JCloudsが管理やアプリケーションプラットフォームに組込まれてきたので、モジュール化が重要になって来ました。ありがたい事に、Gustavo Morozowski と Ioannis Canellosの両氏が最大限の貢献をしてくれて、OSGiのバンドル化と Karaf との統合をまとめてくれました。 OSGiのサポートは最も以前からある課題の1つでした。
またパワーユーザーからの要求によるフィーチャも幾つもあります。例えば、Tibor Kiss氏は我々の BlobStore をペタバイト規模に押し上げました。そしてNGSプラットフォーム内のモジュールに磨きをかけ、テストしました。
Jeremy Whitlock氏は ProviderMetadataの最初のバージョンを率いてくれました。これは、使えるクラウドや詳細、例えばクラウドのコンソールURLやフレンドリー名などをクエリするのに使うことができるものです。 Cloudsoftはこのような詳細を使って、管轄境界の配置ルールを持っています。US外の人達がこの件に、非常に熱心ですね。
セキュリティ意識の高い人たちには、AdminAccessという本当に良いツールがあります。これを使うと1ステップで、ノードをロックダウンし、個別のユーザーを作成できます。
多くのことをやるのに重要なのは、我々への幅広いサポートです。 Grid Dynamics と GigaSpaces は人気のある OpenStack Nova プラットフォームへの支援を提供してくれました。我々はたくさんの新しいサービスを加えてきましたが、これらはプロバイダーからのもので、一番遠いプロバイダーには、 オーストラリアの Ninefold(XEN と VMWare でホスティング) と 英国の Stratogen（VMWare でホスティング) があります。
InfoQ:2010年12月23日のInfoQとのインタビューで、あなたは まもなくJCloudsはlibvirt と一緒に開発を行ない、JCloudsを仮想化制御に使えるようになるかもしれない、と言いました。この件で何か進展がありますか？
余りありませんね。多少、我々は OpenStack Nova や vCloudのようなクラウドコントローラに興味を持ってます。両者が一緒になるまでね。別のオプションは我々のbyon (Bring your own node)プロバイダーで、最近Twitter と協働で開発しました。 BYON を使うと、 Jcloudsにyamlシンタックスでマシンの詳細と一緒にファイルやweb URLを与えることができます。これは我々がまだサポートしていないプラットフォームへの素晴らしい回避策になります。
InfoQ: どのCloud APIをJClouds はサポートしているのですか（vCloud, Amazon EC2など）？
JCloudsがサポートしているストレージインストールには、EMC Atmos, OpenStack Swift, Eucalyptus Walrus (S3 クローン), 他のAmazon S3クローンがあり、ディスクへのたくさんのファイルさえサポートしています。計算側で、我々がサポートしているインストールには、 vCloud（WMWareからのイニシアティブ）, ElasticStack, Eucalyptus (Open Source Amazon EC2クローン), Deltacloud （JCloudsとある程度オーバーラップしている）, Amazon EC2の多くの派生、そしてbyonフォーマットです。
Cole氏は JCloudsのフィーチャロードマップについて説明してくれた。PaaS抽象化への支援を要求する、最近の大きな圧力があったので、サポートが彼らのロードマップに載った。PaaSへの焦点は、これまでIaaS抽象化に主に焦点を当ててきたJCloudsにとっては新しいことである。このPaaS開発には Google App Engine や CloudBees Run@Cloudと一緒に開発することを含んでいる。
焦点を当てている他の領域には、スロットリングとスケーリングである。プロバイダーによっては、100余りのノードをプロビジョニングしようとすると、問題があった。JCloudsは追加された組込み戦略に取り組んでいるので、もうすぐリソースの大きなプールを要求できるようになり、そしてそれはかなりの確率で成功する。
Cole氏が更に説明してくれたのは、ロードバランシングと仮想化のサポートについても開発中で、まもなく終了する、ということだ。仮想化サポートには、代替のブートソース、ISOマウント、 PXE、自分のイメージの作成、他のマシンのイメージのクローニング。仮想化のサポートにはプライベートクラウドもちゃんとサポートするようだった。
InfoQ: JCloudsを Jets3t , typica, Deltacloud、Daseinと較べると、どうですか？品質、パフォーマンス、仕様、成熟度について話していただけますか？
JCloudsと多くの代替製品との最も基本的な差は、我々は多くの時間をメタデータの等値に費やしていることです。例えば、アイルランドにUbuntu 10.04 サーバーが必要なときのように、要求を直接見せたい時に、これは非常に役立ちます。これは、ちゃんと動かすのは非常に難しいプロセスで、我々は常にこれをもっと上手く動くように努力しています。
Jets3t (Amazon S3 にフォーカスしたAPI)のJames (Murty)氏が非常に信頼できるライブラリを作りました。 Typica(Amazon EC2 と他の Amazon サービスに的を絞ったAPI で Eucalyptusのようなクローンと動く）の David氏も同様ですね。彼らは二人とも、 JClouds開発で得た経験を共有しており、特にJames氏は設立時からの開発者で、何ヶ月間も猛烈に働きました。 jets3t もtypicaも成熟したライブラリで JClouds以前からありました。ということは、彼らは移植性については考慮していないので、実際どちらも JCloudsとやりとりできません。一般的に言って、我々はAmazonのフィーチャに追いかけていますが、 jets3t や typicaはほとんど、あるいは完全に同じものをより速く作ろうとしました。我々はパフォーマンスを jets3tに対して測定したら、我々の方が良かったです。もちろんテストは、我々が書きました。
Dasein は JCloudsにより近いものです。同時期に設立され、実際に、クラウドプロバイダーのかなりの部分で JCloudsコンポーネントを使っています。 Daseinには JCloudsがサポートしていない若干のプロバイダーがあり、逆のことも言えます。 Daseinは単一サーバー操作に的を絞っていますが、 Jcloudsは複数マシンのセットをブートストラップすることに焦点を当てています。 Daseinの本当に素晴らしいのは、多くの道具を提供していることです。例えば我々がまだモデリングも終わっていないファイアーウォール ルールですね。
Cole氏は続けて Deltacloud について大変「美しいREST API」を持っている、と話した。Deltacloudの焦点はAPIの移植性であり、 JCloudsはユースケースを実行するための、移植性ある方法にフォーカスしている。 Deltacloudはマシンをカスタマイズするのに、もし可能であれば様々な手段を発見することができる。 JCloudsを使えばブートストラップ用のスクリプトを提供でき、その詳細を整理してくれる。 JClouds が Deltacloudを統合できるのは、驚くにあたらない。
InfoQ: JClouds はEucalyptusをサポートしてますか？ Eucalyptusをどう思いますか？
ええ、JClouds はEucalyptusをサポートしてます。Eucalyptusに対する私の意見は好意的ですよ。我々が指摘した互換性の問題を自分達の問題として、その解決に努力しました。
Eucalyptusは Amazon EC2, S3などの人気のあるオープンソースである。プライベートクラウドコンピューティングに使われている。
InfoQ: もし私がプライベートクラウドを始めるとしたら、 JCloudsはどのプラットフォームをサポートするのですか？今は？将来は？
オンプレミスの計算クラウドを意味しているなら、 Eucalyptus, OpenStack, vCloud 1.0が今使えます。まもなく、我々がサポートする cloud.com のCloudStack 2.2.8は非常に成熟しており、有償版とGPLライセンスのある、堅牢な製品です。今年中に、 vCloud 1.5とおそらくOpenShift Powerもおそらくサポートします。他にサポートする予定のクラウドコントローラには、 OpenNebula やAbiquoようなものがまだ2,3ありますが、要望の大きさに依るでしょう。
InfoQ:この3ヶ月で JCloudsが達成した大きな成果に何がありますか（開発において、アーキテクチャの改善など）？
OSGiについては、この3ヶ月で本当に進みました。クラウドリソースにオフラインで接続できたり、アプリケーションが走っている間にアップグレードできることは、非常に意味のある関心事ですよ。典型的なデータセンター運用のように、クラウドは保守が要りますので、動的に調整してこのようなことをやる必要があるでしょう。OSGiと他のモジュールシステムがこのために重要です。OSGiへの我々の最初の一歩は、我々とユーザーにとって実に大きなことです。
別の大事なこととして、 Tibor Kiss氏によるデータ転送の最適化があります。EC2クラスタとS3間で、 300MB/s超のスピードを記録しました。このために、クラウドでペタバイト規模の転送が実現可能です。 Andrew Phillips氏はまた、我々の TweetStoreのデモを何とか蘇らせました。これは、（ありがとうtwitter4j!）ツイッターのアップデートを Google App Engineから BlobStoresに転送します。彼はこれを更に進めて、今や同時に CloudBees Run@Cloud PaaSにも、それをデプロイできるようにしました。我々は IaaS と PaaSを一緒にして旨いことができないか考え始めています。その必要性がある人に何か役立つツールを作りたい、と考えています。
InfoQ:ある人が Google App Engine を EC2 、Rackspace 、Azure あるいは内部のプライベートクラウドで使う際に、何か考えがあります？
そうですね。現在PaaSを選ぶにはたくさんの選択肢がありますので、完全にGAE、Azureなどの決定はいつも用心が要ります。
PaaS や IaaSはコスト、サービスレベル、あるいはあなたの要求との一致具合によって決まるものです。もしあなたの要求が、PaaSが提供する限られたリソースで満足できるなら、それは決めるに値するでしょう。より少ないものの贅沢にお金を払うわけです。もしホストされたPaaSの提供を検討しているのであれば、データ層によく注目すべきです。どうやって作ったもの、ハウスルール、過去の可用性、メンテナンス期間をインポート／エクスポートするのか知りたくなるでしょう。
私は一般的に自分でPaaSを運用することには慎重になるでしょうね。それはRabbit MQ, CouchDB, Nginx, Nagiosなどのような多くのモジュールからできているのが普通です。自分のPaaSを動かしたければ、あなたは依存関係をよく調べ、それらすべてをサポートできる能力が絶対に必要です。あるいはどこでそのようなサポートが得られるかを知らなければなりません。また単一サーバーによる PaaS やIaaSのクィックスタートデモには注意したほうがいいです。現実の、マルチサーバー デプロイは、しばしば難しく、人手に依る、そして／あるいはドキュメントの無いプロセスです。このような懸案すべきことがあるので、ホストされたサービスのほうがずっと魅力的です。
もしあなたが一度に何百ものノードを動かす必要があるなら、あなたは絶対にEC2を使わなければなりません。私がわかったのは、 Rackspaceはより小規模では他のプロバイダーと同ぐらいにいいことです。どのパブリッククラウドプロバイダーにデプロイするのがいいかの決定は、ビジネス価値がもっと重要な要因になるだろう、と予想します。例えば、パフォーマンスが理由で、あなたはほぼ誰に同じになりたいのか？彼らはクラウドXにデプロイしているのか？もしそうならどの地域に？あなたの興味がある管轄をどのクラウドがサービスしているのか？あなたのどの技術パートナーがクラウドXに経験があるのか？オンプレミスはもっともな決定であり、特にあなたが既に専門知識とインフラを持っているなら非常に道理にかなっています。今年は、オンプレミスのクラウドで役立つ製品もたくさんあります。
InfoQ: IaaSのどのプロバイダーが最も協働（統合）し易いのか？一番バグの多いのはどれですか？
最も一緒にやりやすいのは ElasticStackを運用しているプロバイダーです。ほとんどいつも稼動しており、どのプロバイダーでも非常に一貫しており、プログラムの観点からも大変単純です。
バグのチャンピオンについてはかなりの競争があり、多くのプロバイダーがチャンピオン目指して争っているようです。冗談抜きに、名前を挙げて、恥をかかせることはできません。自前のクラウドコントローラを書いているプロバイダーで、コアコンピテンシーとしてソフトウェアを書いてきた歴史のないところは、バグが多い傾向があります。
InfoQ: Amazon BeanStalkをどう思いますか？ Amazon関係、すなわちAmazon Simple Notification Service, Elastic Load Balancing, Auto-ScalingのAPIをもっと抽象化する計画がありますか？
BeanStalkは面白いですし、どこで Amazonが開始して、停止するのかの知見にとてつもなく大きなインパクトを持っています。私はそれは BeanStalkと競争しているISVへの警告の合図だ、と考えています。非常に単純なサービスで、実際設定管理までには立ち入りません。なのでそうなるまで、実際の影響は限られたものです。他のAWSサービスに関しては、JCloudsでElastic Load Balancingサポート を使っていくつかのサービスを既に持っています（例えば OpenShift Flex）。他のAPIは基本的には、我々のサポートがないことで困る人が十分な数になるのを待っている状況です。
JClouds 1.0は急速に進化している世界で、感動的なリリースのようである。 JCloudsはフィーチャと目標において、成長しているようだ。