BipIOは軽量なオープンソースのIPaaSで、さまざまなクラウドサービスをマイクロアプリやパーソナルワークフローとして通信できる。プライベートベータとしてサービスを提供し、BipIOはサービスを公開した。InfoQはBipIOの創業者であり、テクニカルリードを務めるMichael Pearson氏にNodeJSとたくさんの公開APIを使ってこのプラットフォームを開発した経験を聞いた。
InfoQ: BipIOのパブリックベータ公開、おめでとうございます。簡単にBipIOについて教えてください。
MP:ありがとうございます。このプロジェクトにとてもわくわくしています。BipIOは軽量なオープンソースのIntegration Platform As A Service (IPaaS)で、自分自身のデジタル情報を編成することができます。これを使うことでマイクロアプリやパーソナルワークフローとしてさまざまなクラウドサービスと通信します。Yahoo Pipesに着想を得ましたが、RSSフィードの変換ではなく、さまざまなAPIを活用してストリーム処理やパーソナルコンテンツのキュレーションと生成ができます。毎週新しいAPIが追加されます。お気に入りのサービスがサポートされていなくても心配いりません。コントリビュータに公開されているからです。
BipIOは‘bips’のコンセプトを活用します。これは、揮発性のグラフベースのパイプラインです。グラフの各頂点は外部APIの呼び出しで、エッジを通じてメッセージが変換されます。明示的に変換する場合もあれば、学習して変換する場合もあります。このアプローチのもっとも良い点は高度な多能性があることです。各頂点はとても簡単にホットスワップでき拡張できます。しかも、‘bip’が扱うコンテンツがウェブフックから来ようが、メールであろうが、イベントトリガであろうが問いません。制約なしに使え、企業のオーバヘッドはありません。まじめに使おうとすべてそうすることもできます。人、ロボット、プログラム向けに作られたサービスなのです。
InfoQ: 40の異なるAPIに向けてコネクタ(Pods)を作りましたね。この開発からどんなことを学びましたか。APIの設計は改善されているのでしょうか。それとも、まだGeorge Reese氏がその著書で嘆いたままの状態なのでしょうか。
MP:現時点でBipIOがサポートとしているAPIをあつかってみた限りでは、どれもが一貫性のある設計になっていたことは良い意味で驚きでした。各プロバイダともそれぞれ固有の癖がありますが、私が思うに、どの開発チームもREST、セキュリティ、OAuth、ストリーム、リアルタイムなどを理解し、互換性を目指して開発しています。それが自然な進化だからです。ある種の標準化への圧力が良い方向に働いているようです。
しかし、私が行った統合は100%ハンドメイドです。というのは、機械が理解できるスキーマを提供していないAPIがほとんどだからです。APIファーストは多くの組織にとって文化のシフトです。APIファーストの中でどのように最大限の価値を発揮するかについて製品サイドと開発サイドでは常に考えの相違が生まれます。APIが製品化され開発自体は楽になりましたが、APIの自動的検知の仕組みという重要な仕事はまだなされていないのです。例えば、RAMLファイルやJSON-Schemaをインポートできる(MuleSoftのRAML Notebookのように) ようになれば、だいぶ楽になります。ツールはありますが、汎用的ではありません。これは大きな難点です。
統合を実施する上で、問題があったり、統合できなかったりしたAPIはいくつかありましたが、全体的には混沌とした状況ではなくなっていると思います。
“標準の良いところは選択肢がたくさんある点だ。”
- Andrew S Tanenbaum
InfoQ: BipIOのひとつの特徴にダウンロードしてオンプレミスで実行できる点があります。なぜこれをできるようにしたのですか。このような使われ方は多いのでしょうか。それともSaaSプラットフォームを経由して利便性を提供するためということでしょうか。
MP:サーバがオープンソースでダウンロード可能なのは、私自身がそのような製品が欲しいからです。データとセキュリティに完全な所有権があり、かつ、最低限の投資で素早くプロトタイプを作りたい場合は、個人的に使うという選択肢が欲しいのです。GPLv3でオープンソースにすることでこの目的を達成できます。BipIOはメーカのプラットフォームと研究開発で使うプラットフォームの間で、現実の問題を解決します。自分でホストして使うのとパブリックなサイトで実行するユーザは半々という感じで、パワーユーザの中にはこのプラットフォームの限界を探っている人(月間に数十万のメッセージを送ってみたり)もいて、価値あるフィードバックを提供してくれます。プラットフォームはより便利になり、多くのユーザがBipとメッセージ変換を共有しています。それゆえ、API統合のソーシャルな側面を開拓すること、そして広くアピールするSaaSにすることが現在の注力点になります。
InfoQ: 実装にNodeJSを使っていますね。コールバック地獄については恐ろしい話を聞きますが、今回の開発ではどうでしたでしょうか。
MP:NodeJSは軽量なBipIOのようなネットワークアプリケーションを開発するためには自然な選択肢でした。私が注力したのはNodeJSの最高の性能を引き出すことです。しかし、製品のすべてに関連する銀の弾丸にならないように注意もしました。パイプ&フィルタのパターンはNodeJSの中核にあるデザイン原則に合致します。例えば、初期の段階ではグラフの解決はノードのネイティブパイプを外部API(のチャネル)と一緒に使って実現していました。これは単一ポイントでのI/Oになり、並列性に問題が起きたときにRabbitMQへスワップするにも時間はかかりませんし、データ構造も変える必要はありません。この柔軟さが大好きです。ノードランタイムの非同期特性はそれ自体が難点です。というのは、ウェブの開発ツールキットに比較的新しく導入されたものだからです。また、多くの同期(あるいは同期のような)ライブラリがあります。例えばasyncやQのようなものです。これらのライブラリを使うことでアプリケーションは簡単にデバッグし計測し最適化できる構造になります。これはとてもよいやり方でした。
またNodeJSには活発な開発者コミュニティがあります。モジュールもあり、何かを動かすにはとても便利です。さまざまな種類のモジュールがあるのは、ある意味では諸刃の剣であり、サーバにとって最適なモジュールをキュレートしようとする努力が行われています。開発者に現実の世界の例とフィードバックを与えることによってNodeJSが正当なウェブアプリケーションプラットフォームになることを望みます。
InfoQ: あなたのAPIは2つに分離できます。RESTfulと他のRPCです。このようにしたのはどのような理由ですか。設計に理由があるのですか。それともユーザビリティを考慮したのでしょうか。
MP:サーバは‘APIファースト’の考えで作りました。したがって、この考え方で設計上の選択をしていきました。例えばパブリックなサイト/ダッシュボードはサーバの後に開発されました。とても小さなクライアントでサーバが提供するすべてのエンドポイントを利用します。これを使ってユーザはブラウザからBipIOサーバを‘マウント’します。ファイアウォールの後ろでもVPN経由でもかまいません。
APIを設計するときはパラダイム同士を統合するのは重要ではないと思います。というのはそのような統合をすると誰もが避けようと奮闘している標準の断片化が発生するからです。RESTとRPCの両方をサポートすることで、APIはクライアントを開発するときにリソースに対して意味論的に正しいアプローチになります。RESTのエンドポイントが中核にあるシステムのリソースであり、一貫性のある挙動を提供します。一方、RPCはより複雑なフローを持ち、一般的にはブラウザがそのようなフローを解釈しリソースを解決します。サードパーティのOAuthネゴシエーションがRESTfulなアプローチの良い例です。また多くの場合、RPCのサーバはサードパーティのAPI呼び出しをカプセル化したり、プロキシします。これはBipIOの責務領域の外で行われます。機械が解釈できるスキーマがもっと標準化されれば、REST/RPCのセマンティックは今よりも重要ではなくなるでしょう。
InfoQ: BipIOは優れたグラフ処理の構造を持っていますね。Apache Stormに着想を得たのですか。
MP:鋭いですね。その通りです。最初のサーバは1年前、Pylons/Storm/Postgresを使って個人的なツールとして開発しました。そのとき、Stormの静的なトポロジを使って私が実現したいと思っていた動的なパイプラインをモデリングするのに困難を抱えていました。そのときはNodeJSとRabbitMQを使って毎日仕事をしていましたので、完全に別のスタックを使って分散グラフシステムのプロトタイプを作ろうと思い立ったのです。BipIOはStormやKafkaや他の似たようなもの代替ではありません。インフラまで詳しく計画したいとは思わない、またはその必要のない開発者が機会費用を少なくするために特に軽量に実装されています。
このグラフシステムはパイプ&パターンを使います。このパターンの出力は隣接するエッジ間で変換されます。グラフはとても簡単にUIをコーディングでき、小さなデバイス上で大きなワークフローを表示するのに十分な大きさです。BipIOはサポートしているすべてのAPIリソースをJSONスキーマへインポート/エクスポートできるように抽象化、標準化することによってこれを実現しています。したがってビジュアライズするのに必要なのはチャンネル同士のつながりだけです。開発者はこのようなアドホックな標準をAPIの深い部分を知らなくても使うことができます。グラフを構成しているのはスキーマと変換です。BipIOはこのグラフを何度も学習して、初心者ユーザに対して最良の推量によるメッセージの変換を提供します。
InfoQ: APIマーケットの最先端は提供から利用へ動いているようです。今後数年はどのように展開するでしょうか。
MP:APIは製品へと進化しています。すぐにではなくても、大きな製品の一部として、ドキュメントがあるアクセス可能なAPIが既存のサービスを強化します。APIの製品化の長所、アクセシビリティの強化、ユーザの使いやすさによって、開発者であれば、異なるサービスが提供するコンテンツを組み合わせることで優れたものを生み出すことができます。また、Internet Of Thingsによって利用と自動化への流れが生まれています。というのは、Internet Of ThingsはAPIの力を文脈がはっきりしていて日々の生活に直結する家庭に持ち込むからです。この観点からの自然な進歩としては、‘なぜ、他のチャネルに同時に割り込みが発生したときにIoTのセンサはアラートを上げることはできないのか’ということです。したがって、APIを開発ツールやB2Bのものからより組織的なタイプのマーケットプレイスに変換する圧力が強まると思います。より興味深いのは、個人的な自由と制御のレベルを選択できるということです。
私はBipIOでAPIに対してより顧客指向でアプローチしたいと思っています。BipIOでコンテンツとサービスの制御し、より個人的で便利で関連性のある何かを生み出すのです。このプロジェクトはコンテンツ、パーソナルオートメーション、データ所有権を家庭に持ち込みます。API利用の自動化、機械による検知もありますが、このような話題は開発者の関心事です。私は未来のAPIの偏在性、開発者だけでなく、利用者も含めた世界での偏在性に着目しています。
InfoQ: Michael、ありがとうございました。