ファブリックは、多数のコンピューティングリソースにわたって信頼できる実行と簡単な操作でアプリケーションサービスの仮想化を可能にする、グリッドベースのソフトウェア基盤です。InfoQは、AppistryのVPであるSam Charrington氏と共に、コミュニティエディションおよびグリッド/ファブリックコンピューティング分野におけるAppistryの総合的な地位について話し合った。
1) なぜ、5サーバー/10コアまで無料の製品を発売するのですか（ビジネスおよび技術的戦略は何ですか）?
私たちは、この新しいモデルを「オープンディストリビューション」と呼んでおり、それがオープンソースと商業界のベストを提供すると考えています。つまり、オープンソースの導入の容易さに加えて、成功した商用ソフトウェアプロバイダーが提供できるセキュリティとサポートオプションを提供できます。オープンディストリビューションにより、コミュニティの全員に、制限なくAppistry EAFを体験する機会を与えることができます。そうすることで、ユーザーはコストをアプリケーションから受ける経済的価値とより良く調和できるようになります。
ビジネスの観点から言えば、これはいずれ次の3つの方法で当社にチャンスをもたらすであろうと信じています。当社との、より積極的なサポート関係を希望するという理由で、有料顧客になるユーザーがいるでしょう。プロジェクトの成功によって、5台より多くサーバーをスケーリングする機会がもたらされるという理由もあります。また、複数のアプリケーションを単一の大規模なファブリックに統合し、結果として生じる運用効率を得たいという理由もあります。
技術的に言えば、現在ダウンロード可能な無料のコミュニティエディション製品は、Appistry EAFの有料顧客が受け取るものと同じ優れた製品です。時間とともに、コミュニティエディションは、Appistry EAFが得るコア機能拡張とバグ修正を受け続けることになるでしょうが、有料製品を購入する顧客には、大規模な展開の管理を対象とした追加機能が提供されるでしょう。
2) どのような種類のアプリケーションが貴社の製品の恩恵を受けるのにうってつけですか?
顧客の大半が、データとCPU集約型のアプリケーションの開発と展開を簡易化するためにAppistry EAFを使用し、一般に、極めて信頼性の高い方法で大量のデータを処理しています。この種のアプリケーションの格好の例として、Appistry EAF上で動作するFedExの次世代ロジスティクスシステムや、毎日テラバイト単位の衛星画像を処理するGeoEyeのアプリケーションがあります。これらのアプリケーションは、ほとんどどんな定義でも大規模（ラージスケール）であり、当社が「アプリケーションファブリック」と呼ぶものを形成する数百のCPU上で動作します。
これと並行して、「名詞としてのスケール」アプリケーションは「動詞としてのスケール」アプリケーションです。
これらは、ISVやSaaS（Software-as-a-Service；サービスとしてのソフトウェア）プロバイダーの傾向があります。場合によって、前者は後者になろうとします。彼らは、要求に応じてアプリケーションを追加的にスケーリングできるアジリティのレベルを達成したいと思っています。さらに重要なことに、彼らは開発者のために物事を簡易化し、より多くのことをより迅速にこなせるように抽象度を上げたいと思っています。
アプリケーションは、自然にスケールアウトされた、従来のビジネスアプリケーションに似ている傾向があります。
3) Spring統合の話はどんな内容ですか?
4) APIロックイン/コードの移植性に関する批評にどのように対応しますか?
プラットフォームのロックインは、顧客にとって重要な問題であり、私たちは移植性に対する障壁を排除するために懸命に取り組んできました。その結果、現在のファブリック顧客は、ファブリックからもファブリックへもコードを容易に移行できます。私たちは、開発者がBean自体も、それを使用するクライアントアプリケーションも変更せずに、既存のSpring Beanをアプリケーションファブリックに展開できるSpring統合への優れたアプローチを手に入れました。それはすべて、アプリケーションのワイヤリング方法を変更するだけで行われます。一例として、私たちは、XMLの約10行だけを変更してjPetStoreアプリケーションをファブリックに展開しました。
あなたのアプリケーションがSpring、Java、.NETのどれで記述されていようと、ビジネスオブジェクトはファブリックに依存しないPOJOまたはPONOで記述されるため、それらをどこでも実行できます（また、これによりユニットテストを容易に行うことができます）。
C/C++アプリケーションを開発する顧客のために、私たちは、Javaや.NETにあるようなイントロスペクション機能を備えてない言語もサポートしているため、それに束縛されずに当社プラットフォームの多彩さを利用することは少々困難ですが、それは確実に可能です。多くの顧客が、既存のバイナリ実行ファイルを利用し、ファブリックにまったく触れずにそれらを展開しています。
5) 貴社の製品をXTP、グリッド、またはクラウドのどれに位置付けているかと、その理由は何ですか?
6) グリッドとクラウドコンピューティングの違いは何ですか?
私たちは当社製品を「グリッドベースのアプリケーションプラットフォーム」として位置付けています。完全な記述子とは言えませんが、製品が何に使用され、それを従来のオプションとどのように区別するかを技術部門の人々にうまく示しています。GartnerのMassimo Pezzini氏が、その用語と、XTPすなわちExtreme Transaction Processing（超高速トランザクション処理）という用語の両方を作成しました。XTPは顧客に関係するビジネス課題を示しているため、私たちはその用語も好んでいます。一方、グリッド（Grid）およびクラウド（Cloud）という用語は「ソリューション」を示していますが、それらが解決する問題は必ずしも明確なわけではありません。それは、スケーラビリティでしょうか？リソース共有でしょうか？外部ホスティングでしょうか？
私たちの経験では、エンドユーザーは用語の意味を理解しようとするとき、「最小公分母（common denominator）」アプローチを取ります。グリッドの場合はつまり、私たちが話をするほとんどの人々がその用語を、多数のコンピュータにわたってアプリケーションをスケールアウトする方法として見なしていることを意味します。
私たちは、クラウドコンピューティングがユーティリティ配信モデル、インターネットスケール、および極度のアジリティの概念をグリッド上に重ねていると信じています。しかし、ユーティリティ、オンデマンド配信がサードパーティ配信と必ず同義であるとは思いません。当社の顧客の多くは、当社製品を、EC2もAppEngineも使わずにエンタープライズ内でクラウドコンピューティングを有効化するものとして考えています。ありがとうございます。
7) Appistryの見解で、最近アプリケーションスケールに関連すると考えられる最も興味深い動向をいくつか教えてください。
最も興味深いことは、スケーラビリティ自体が、クラウドコンピューティング、SaaS、Web 2.0のような技術動向に突き動かされて、私たちの目の前で再定義されているという事実です。10年前にJ2EEが出現したとき、スケーラビリティのレベルはかなり低いものでした。エンタープライズ内のほとんどの問題が、単一サーバーまたは小さいクラスター上で解決できました。もはやそう単純にはいきません。今日のアプリケーションはますます高度なアルゴリズムで処理する必要があるデータとトランザクションを抱えています。
過去の技術は、それ自体の複雑さによって新世界では崩壊しつつあります。新世界は、開発者とアーキテクトに、より新しく、より軽量で、よりスケーラブルかつアジャイルなアプローチに取り組む機会や、大衆の対話にとはいかないまでも重役レベルの議題にスケーラビリティを押し上げる機会をもたらします。
これらは、アプリケーションスケーラビリティに関心を持つ私たちにとって非常にエキサイティングで重要な時です。
また、Appistryは最近、販売とマーケティング活動を拡大するためにシリーズC(source)の資金調達ラウンドを完了した。
原文はこちらです：http://www.infoq.com/news/2008/06/appistry-interview