InfoQはサンフランシスコで開催されたMuleSoftのCONNECT 2016のカンファレンスにおいて、CTOであるUri Sarid氏と話す機会を得た。Sarid氏は待望の正式公開版であるバージョン1.0がリリースされたばかりのRAMLの考案者であり、昨年のインタビューの続報や、APIチームのためのMuleSoftのソリューションの関する俯瞰的な観点、APIに対する彼のビジョンを聞く良い機会である。
InfoQ: あなたのMuleSoftにおける役割と、業務の中でAPIとどう関わっているかを教えてください。
Uri Sarid氏: 私の役割はCTOであり、弊社のプラットフォームのアーキテクチャに加え、プラットフォームのビジョンや方向性についても同様に責任を持っています。APIは私たちがやっている全ての物事のフロントと中心に位置しています。これらは私たちのアプローチの中心を成すものであり、私たちはAPI主導の接続性と呼んでいるものです。この概念は私たちがAPIエコシステムと呼んでいるサービスのエコシステムを存在させるために必要なものです。
InfoQ: APIに関するMuleSoftのビジョンは何でしょうか? 大部分は統合の必要性に関するものでしょうか?
Sarid氏: MuleSoftのビジョンは顧客と一般産業がアプリケーションネットワークを作成できるようにすること、またこれにより世界のアプリケーションデータとデバイスを接続することです。アプリケーションネットワークはアプリケーションのネットワークであり、データとデバイスがAPIで接続されることで着脱可能でサービスの再利用ができるようになります。
InfoQ: MuleSoftのどの製品がAPIプロジェクトにおいて開発者とアーキテクトを援助しますか?
Sarid氏: 私たちは完全なAPIのライフサイクルをカバーするために製品スイートを提供するのではなくプラットフォームを提供します。APIを作成しているのであれば、その行為は本当に初期のアイデアを出発点として、作成しているもののトライアルを行い、APIインターフェイスの製品化を通じて実装や配置、運用や管理を考え 、APIをどうしていくかの見識を得てユーザのエンゲージメントと離脱を経験する、ということ全てを意味します。
InfoQ: 大企業やSMB顧客において、APIの採用や成熟度はどのようなレベルにあるのでしょうか?
Sarid氏: まず、APIは認識、興味や投資という意味ではキャズムを超えています。それなりのサイズのビジネスにおいては全く理解されておらず、現在コア戦略とビジネスにAPIが統合されていないというのは私にとっては考えにくいです。
そうは言っても、結果を伴っているか、うまく機能しているかという意味では、市場は成熟しているというにはまだまだというのが現状です。
InfoQ: あなたは統合PaaS(iPaaS)とAPI管理は結局融合するとお考えでしょうか? それとも大部分は分離したままになるとお考えでしょうか?
Sarid:Sarid氏: 私たちの考えでは、それらは既に融合しています。私たちのプラットフォームはiPaaSとAPI管理のための包括的なプラットフォームであり、顧客はこの種の完全なソリューションを期待していると考えています。
顧客はAPI管理と分散ESBに価値を見出しています。iPaaSを必要としている領域が存在し、顧客はこれらを異なるソリューションでではないと考えるようになってきています。
このことに対する完璧な例として、顧客がESBを利用して作成した成果物の頂点に、必要に応じてデータに容易にアクセスできるようよく管理されたAPIを付与したいというものがあります。
InfoQ: 長い成熟期間を経て、まさにRAML 1.0の正式公開版を発表したところだと思います。新機能に関する情報と、なぜそんなに長い期間が必要だったかについて教えて頂けますか?
Sarid氏: 大きな変更としては、形式に依存しない、再利用可能な方法でデータを簡単にモデリングできる機能の追加があります。もっと一般化すると、規則、パターン、そしてあなたや他人が既に作成した全てのものを簡単に簡単に再利用できる機能です。
RAML 1.0により、API開発者はネットワークコンポーネント間にまたがるライブラリの作成や設計の再利用、設計の一貫性の改善やAPI提供の高速化を行うことができます。加えて、アノテーションにより強力かつコントロールされた形で拡張性が提供でき、YAMLベースで名前が付けられた例により人間にも読みやすい形式にすることができるため、協調や開発者の着手がしやすいものです。
競合に比較してRAMLの採用の度合いはどのようなレベルにありますか?また主な差別化ポイントはどこでしょうか?
Sarid氏: 私たちが注目し始め、またそうなることを望んでいるのは、人々がAPIの重要性が契約であるという見方をすることです。この価値観により開発者はこの契約が組織に意味がある記述方法を選択するようになります。そしてその時、そうするためのベストプラクティスは何なのかを考えるようになるのです。
SwaggerとRAMLを比較すると、RAMLはOpen API仕様(正式にはSwagger仕様として知られるOAS)の上に幾つかの概念のを加えたものであるということに気づくでしょう。RAMLは再利用のための多くの機能を提供しています。
RAMLはAPI記述のソースコードを記述するために選択したものであり、APIエコシステムをフル活用できるように互換性ツールを提供するコミュニティにも期待していると、あるRAMLユーザは話していました。現在互いの機能性の仕様に関して互換性があります。
InfoQ: RAML 1.0を完全にサポートするツールのリリースはいつを予定していますか?
Sarid氏: 早期アクセス版に関しては既に提供しています。しかし正式版との間に少しギャップがあります。リリースしたパーサに関しては既にギャップは完全に埋められており、最終段階にあります。これらのパーサを取り込み、完全に機能するプラットフォームの一部としてリリースします。
パーサとAPIワークベンチは現時点でオープンソース化されているため、コミュニティは平行して1.0のためにサポートを仕上げることができます。
非常に多くのコミュニテイプロジェクトが進行しています。ここ数週間から数ヶ月中に動きがあるでしょう。これらをサポートするために大量のドキュメントがあり、仕様に完全の準拠していることを保証するためテスト互換性キット(TCK)についても用意しています。
また、APIワークベンチを他のプロジェクト加速するために、個々に使用することができる個別のツールにモジュール化する作業についても進めています。
InfoQ: RAMLの統制は進んでいるのでしょうか?SwaggerがOpen API Initiativeの立ち上げを行ったように、標準化団体に移行する計画はありますか?
Sarid氏: 統制はよりコミュニティ駆動となっており、今のところ形式ばった面は少ないです。私たちは作業を進めるための方法にこだわりはありません。私たちは現時点でOpen API Initiativeと作業を進めることに対する興味をを維持しており、これは統制すべき一面に過ぎませんが、対話を行っている最中です。
InfoQ: APIは本来技術的なものではありますが、ソフトウェアプロジェクトにおいて重要な位置を占めるようになってきています。どのように事業に関連する人々と技術に関連する人々のギャップを埋めることができるとお考えでしょうか?
Sarid氏: 私は技術部門により気軽にアクセスになったからといってそれほど劇的に物事が進むとは思っていませんが、どうすればAPIがよりビジネスにアクセスしやすくなるかについて考えています。企業のある部門がある程度のデータソースのセットを持っているとすると、アプリケーションネットワークを構築してこれらのデータを再利用可能な資産とするのは自然なことですよね?ビジネス側がそのような要請をすることは明白です。これらを提供可能にすることはAPIそのものであり、それはそのデータに対するアクセスを主導するものです。これは単にAPIコンソールを作成することに注力するより価値があり、アクセスを容易にします。
InfoQ: あなたの経験上、API開発者がコード駆動から契約駆動のAPI開発ワークフローに迅速に移行するにはどうしたらよいでしょうか?APIツールはこのような普及フェーズをサポートする全般的な準備が出来ているでしょうか?
Sarid氏: 数字を出すことは難しいですが、この動きは確実に起きています。私たちはこれを支持する動きを確かに確認しており、これは3年前RAMLを立ち上げた時に感じた砂漠で孤独な声のような反応とは対照的です。そしてAPI契約を成熟させるためのツールにより、実用性が増し、設計主導による時間削減ができることを開発者は感じています。ですので、これは単なるベストプラクティスではなく、本当に実践可能なものなのです。
InfoQ: GoogleのgRPCなど、WebにおいてRPCが継続的に再燃しているように思われるのですが、このような状況をどうお考えでしょうか?
Sarid氏: 私は振り子のようなものだと考えており、APIを強い型付けと仕様にするか、緩やかな型付けと構造を欠如させたものにするかは何度も振れています。他の例としてはAPIにとても構造化されたセマンティック(CRUD)を持たせるか、全く構造化しないか(リモートシステムの関数を起動する)、テキストベース(JSONやヘッダ)対バイナリ(gRPCやProtobuf)があり、これからもこれらの振り子が行ったり来たりするのを見ることになるでしょう。
私はAPIエコシステムの中でいつどちらの選択肢を使うべきかを特定し、その選択肢に対するサポートを提供することが役割です。新旧のシステムを取り扱うことができるようにすること、行うべき最良の選択とともに新しいAPIに誘導することが必要です。
InfoQ: あなたの視点から見て、ハイパーメディアAPIの現状はどうでしょうか? 通常のAPIの代替でしょうか? それともMicrosoft Graph APIが暗示するように補完する概念なのでしょうか?
Sarid氏: 私は代替だとは思っていません。それは進化以上のものです。ハイパーメディアはAPIにデータに以上のものを埋め込む手段で、他のメタデータを制御することです。
ですので、私はまだこのアプローチが最大限価値を発揮する場面を理解している最中だと思っています。私は楽観的であり、既に完成させた作業に基づいて来年にはそれを理解し、最適な場面を見つけているでしょう。
InfoQ: 以前のインタビューで、Daniel Jacobson氏は短命のAPIに対する形式的なAPI記述言語の価値について疑問を呈していました。彼に賛同しますか?またRAMLを用いてAPIを形式的に仕様化する際の、あまり適切ではない他の例をご存知でしょうか?
Sarid氏: 全く価値がないとは言えません。
多くのAPIがクライアントアプリケーションのAPIのように日々進化しています。コード生成や、CI/CDを実行するならリリースを破壊していないかの自動テストを行うことができます。また、APIの設計に全く時間を割くことなく、API仕様を単に作成して価値が“ 傍らから ” APIに付与されるのに従い継続的に進化させていくことができるのです。
一方で、時々迅速に開発を進めるために並行して作業を進めることが必要ですが、API仕様はこのようなことを可能にします。APIはより上位のUIほどは頻繁に変わっていく必要はありません。このような場合、API仕様を境界で定義して摩擦を最小化することにより、並行かつ少し違う速度で進化できるようにできるので好都合です。
InfoQ: APIに関してMuleSoft内で発見した苦労する点、およびベストプラクティスは何でしょうか?特定のツールやワークフローを用いていますか?
Sarid氏: 当然ながら私たちは自分たちが開発したプラットフォームを使用しています。私たちは全ての企業が抱える、顧客に発信していることを信じるという問題を持っています。これは物事を構築する際に発生しがちな問題で、どういうことかというと、何かを提唱し、そのためのツールを構築するのですが、構築するためにはこれらのツールを使用する必要があり、当然ながらこれらはまだ開発中なのです。従って、問題は絶え間なく改善の必要性を発見し、この必要性を満たすために私たちのプラットフォームを世に広めることなのです。これらの必要性により私たちのプラットフォームを私たち自身と顧客に利益を与えるためにプラットフォームを構築します。ですから私は、これを取り組むべき素晴らしい問題だと考えています。
私たちは、チーム内や、もしくは複数のチーム間で既にサービスAPIを持っておりAPI主導で開発中している場合でさえも、どうやれば迅速にコラボレーションすることができるかということに対して必ずしも解を持ったとはいえないと思っています。私たちは自身のAPI基盤はまだ十分に効率的でないため、ロードマップにおいて課題を順番付けしています。なぜなら、これらの解決は顧客のためだけではなく、私たち自身が製品を提供する能力を改善することにもなるからです。
InfoQ: CONNECT 2016では、Netflixと共同でアプリケーションネットワークとマイクロサービスについて発表されていました。このような成長著しい状況でのAPIとDevOpsの役割は何でしょうか？
Sarid氏: 私たちはAPIと手続き化はマイクロサービスにおける2本の柱であると理解しています。DevOpsにおけるOps、コンテナの考え方、そして自動オーケストレーションは人々の興味を引きます。例えばDockerやKubernetesなどです。しかし、市場はAPIが効果的なマイクロサービスにおいて重要な役割を果たすことを実感しており、まさにそのことが発表のデモにおいて示されたことです。
APIはマイクロサービスの境界を定義します。細胞の境界が細胞の生存にとって致命的であるように、入力と出力を統制することが必要であり、APIはこれと同様にマイクロサービスが生存するエコシステムを統制するのが役割となります。
強固なAPIに対する価値観とOpsの価値観を持って初めて、Netflixが見せたようなChaos Monkey、Hystrixなどのベストプラクティスを組み合わせていけるようになるのです。
InfoQ: Java APIに関するOracleとGoogleの間の最近の法的決定がありました。何が起こり、Web APIプロジェクトにどのような影響があるのでしょうか?
Sarid氏: 私たちが生きているこの時代はとても面白いですね。USAではAPIには著作権がありますが、ヨーロッパではありません。裁判所はGoogleのJava APIの使用法は“フェアユース”であり、規制や罰則の支払いにあたる対象ではないとに当たると結論付けられました。Web APIは経済に活力を与える決定的な方法であるという考えは変わっていません。
楽観的である理由は2つあります。一つは、最近の裁判で陪審員がGoogleはOracle Java APIを“フェアユース”したと結論付けたのは、開発者がこれらのAPIに親しんでいるためフェアユースであるというGoogleの主張を受け入れたからであり、相互運用性を高めようとしたからではないからです。目的が実際には相互運用性である将来の事例では、裁判所がフェアユース受け入れの議論より更に進み、著作権訴訟の脅威を減らしていくと予想しています。
第2の理由は著作権が本当は何を守っているのかを振り返ってみることに関連します。これはアイデア特有の表現を表現したものであり、アイデアそのものでもなければ、純粋な実利上の表現でもないのです。例えば、実質的に一つの方法もしくは何かの表現方法しかなければ、それは著作権を主張可能ではなく、表現そのものが完全に実利的で創造性を差し挟む余地がないのであれば、それもまた著作権がの対象ではではないのです。
現在、API経済が共通の語彙や構造という実利的で明確なものを用いることで、APIをより標準的な、もっと平易で予測可能なものにする方向に推進しています。APIがどんどんこの方法で実利的になる、つまりおそらく創造性がずっと少なくなるため、将来裁判所がそのようなAPIが実際には著作権適用可能なものですらないと決定することを私たちは望んでいます。
より詳細に興味がある場合は、私たちがこの重要な法的決定的に関する詳細を記したブログ記事を参照してください。
InfoQ: Web APIの将来に関するビジョンをお聞かせ願えますか？全てのサイズのエンタープライズに渡りAPIの使用を加速するためには次にどんな大きなことが起こる必要があるのでしょうか？
Sarid氏: 現在APIはある成熟のレベルに達しました。将来のビジョンはどう組織が価値を駆動し、それらを再利用していくかです。Web APIの価値はアプリケーションのネットワークを創造するためにAPIを利用する時に出てくるのです。
構成・再構成可能な継ぎ目のないアプリケーションの集合を創造するためにAPIを使用することにより、ビジネス側はAPIから価値を得ることができるのです。
APIをビジネスプロセスに組み入れることにより価値を得ることができます。例えば、もしWeb APIが自身のメタデータ情報をより開示すれば、探索はより簡単になりビジネスプロセスに組み込むことが容易になります。これによりビジネス側はWebサービスを運用する方法を理解することができます。
私は探索と消費体験にもっと力を注ぐ必要があると思っています。もっと改善する必要があります。例えばRAMLの形式非依存のデータタイプにより支援することができます。つまり、(特にアマチュアの)開発者はJSONスキーマやXMLスキーマのような形式依存の複雑さに悩まされることはなくなります。
私たちはRAML仕様の例とAPIメモの作成にも力を入れており、開発者はどうこれらのAPIを使用すれば良いか、ユースケースは何であるか、などを簡単に理解することができます。そして、もっと強力かつ簡単にするために私たちや他の開発者が探索と消費体験を得ているか、APIを作成するための選択肢も確認することができます。
Rate this Article
- Editor Review
- Chief Editor Action