[Cloud, Integration] 3rd-Generation API Management: From Proxies to Micro-Gateways

原文はこちら。
http://www.oracle.com/technetwork/articles/soa/weir-3rd-gen-api-mgmt-3787102.html

---

今日、digital disruptorsに支配された市場で競争力を維持するためには、革新し、ビジネスの機敏性とスピードを向上させる必要があります。

Who are the digital disruptors redefining entire industries? (2015, TechRadar)
http://www.techradar.com/news/world-of-tech/who-are-the-digital-disruptors-redefining-entire-industries-1298171

このため、あらゆる規模の組織は、TCOを削減する手段としてだけでなく、digital transformationと顧客中心主義を実現する手段としてクラウド（SaaS、PaaS、IaaS）を採用しています。

The NIST Definition of Cloud Computing(2011, National Institute of Standards and Technology)
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf 

しかしながら、クラウドへの移行は1つのクラウドを意味しません。調査から、組織は全てを一つのクラウドベンダーに任せるのではなく、マルチクラウド戦略を選択していることが透けて見えます。

The future isn't cloud. It's multi-cloud (2017, Network World)
http://www.networkworld.com/article/3165326/cloud-computing/the-future-isnt-cloud-its-multi-cloud.html

クラウドの採用に対するこのbest-of-breedアプローチは、ERPのようなオンプレミスのモノリシックシステムやその他のオンプレミスアプリケーションを、個別のSaaSアプリケーションやPaaSと統合もしくはPaaSで拡張されたものとして、クラウドで再実装することを意味します。

Definition: monolithic architecture (TechTarget WhatIs)
http://whatis.techtarget.com/definition/monolithic-architecture

Figure 1 - Cloud transformation

クラウドに同等のものがないか、または単に要件を満たしていないオンプレミスアプリケーションの場合、多くの組織ではクラウドでのアプリケーション開発も選択しています。

Developing cloud applications in the new IT era (TechTarget)
http://searchcloudcomputing.techtarget.com/essentialguide/Developing-cloud-applications-in-the-new-IT-era

マイクロサービス・アーキテクチャがクラウド・ネイティブアプリケーション実装のためのアーキテクチャスタイルとして優勢になってきましたが、こうするために、モノリスをより小さなピースに分割して各々のピースがbusiness capabilityを表すようにした上で、完全に疎結合なサービス（マイクロサービス）として実装します。この実装は通常PaaSで実施します。

A Word About Microservice Architectures and SOA (SOA4U Tech Blog)
http://www.soa4u.co.uk/2015/04/a-word-about-microservice-architectures.html
Open Modern Software Architecture (OMESA) GitHub Repository
http://omesa.io/

Figure 2 - Cloud native application development

クラウドの採用が進むにつれて、（異なるベンダーの）さまざまなSaaSやPaaSアプリケーションだけでなく、多くのオンプレミスのシステム全体で情報が必然的にますます統合されるようになります。
digital transformationを実現するためには、まず既存の（オンプレミス）ITシステムを調整または強化するか（おそらくはクラウドで）モダンなITシステムに置き換えようと試みる必要があります。そうすることで、製品とサービスを複数のチャネル（ウェブ、モバイルアプリ、キオスク、パートナーのオンラインストア、ボットなど）でデジタルの形で提供できます。
Digital transformationの結果、異なるデバイスとのやりとりによって提供されるシームレスなつながりを通じて、ビジネスプロセスを実行できるようになり、労働者の生産性を高めます。
また、関連するビジネスデータへのオンデマンドアクセスを提供し、ビジネストランザクションを電子的に実行する手段を提供することによって、組織のパートナーエコシステムを強化します。
しかし、中核となるビジネス情報資産へのアクセスが利用できなければ上記の事柄は実現できませんし、その状態で情報が統合されると、アクセスが大きな問題になる可能性があります。
Integration platform as a service (iPaaS)ソリューションがこの問題に対処します。

iPaaS. What is it exactly? is it on-premise software running on IaaS? (SOA4U Tech Blog)
http://www.soa4u.co.uk/2017/03/ipaas-what-is-it-exactly-is-it-on.html

iPaaSのセールスポイントは、クラウドおよび/またはオンプレミスのシステムに接続し、必要なアクセスを提供できるという点です。堅牢なiPaaSプラットフォームは、RESTfulアプリケーションプログラミングインターフェイス（別名Web API）を使って情報へのシームレスなアクセスを提供するために、クラウドおよび/またはオンプレミスアプリケーションに接続できる必要があります。

Representational state transfer (REST) (Wikipedia)
https://en.wikipedia.org/wiki/Representational_state_transfer

情報への標準的で一貫した安全なアクセスを提供する手段としてのAPIの使用により、マルチチャネルアプリケーションは必要なときに必要な資産を利用できます。

Figure 3 - iPaaS solution with API management capabilities

しかし、iPaaSソリューションが堅牢な第3世代のAPIプラットフォーム機能を提供しない限り、前述のニーズに対処するのは難しいでしょう。APIはできるだけ情報源に近くあるべきで、そうでなければ、ネットワークの待ち時間や他のネットワークの問題（予期しない停止など）に起因し、遅延応答などの問題が発生する可能性があります。情報が複数のクラウドとオンプレミスシステムに分散されている場合は、APIが必須です。

3rd-Generation API Platform

クラウドが採用され、情報が地理的に分散するにつれて、アクセスがますます重要になります。 接続性を提供するVPNを確立することは、早晩実現困難になります。SaaSベンダーはデータベースへの直接アクセスを提供しないため、多くの場合、問題を解決できないからです。代わりに、情報にアクセスするための唯一の手段としてAPIが提供されます。
現時点では、第2世代のAPIプラットフォーム（基本的にESBやAPI管理機能を強化したXMLアプライアンス）では能力不足で、クラウドの採用とdigital transformationから生じる最新の要件を満たすことは難しいのです。

Figure 4 - 3rd-generation APIs everywhere

Figure 4で記載しているように、クラウドの採用とdigital transformationのイニシアチブが成功するために必要な機能を提供するために、より洗練された第3世代のAPIプラットフォームが必要です。これは、モノリシックアーキテクチャという技術的な荷物を持たず、以下の要素を備えています。

• うんざりするようなオペレーションや膨大なコストをかけずに、（任意のベンダーのクラウドやオンプレミスでも）APIを実装できる
• 開発者コ​​ミュニティに、セルフサービスの開発者ポータルを介してAPIを発見して利用登録させることができる
• エンドツーエンドのAPI開発ライフサイクルとAPI-firstのためのシームレスなツールを提供するため、開発者はAPIの設計、作成、テストに必要なツールを手に入れることができる
• 情報所有者に対し、誰にどのように所有アセットにアクセスするかを決定させることによって、情報所有者に情報の完全な可視性とコントロールを提供できる
• すべての主要な脅威（すなわち、OWASPトップ10）から情報資産を保護する強力なセキュリティを提供できる
• 軽量、アプライアンス/ESBは不要で、マイクロサービスアーキテクチャに適している
• Elasticである（容易にスケールできる）
• ゲートウェイやAPIの個数およびその配置場所に関係なく一元管理できる
• 統計情報を有意義に使って、運用データを使って監視とトラブルシューティングだけでなくビジネスへの洞察を得ることができる
• CPUベースのライセンスではなく、サブスクリプションベースである

The End of "Fat" Middleware

モノリスをより小さなピースに分割して、SaaSもしくはPaaSで個別のクラウドアプリケーションとして再実装するため、そうしたモノリスに含まれていたビジネスロジックや情報もまた分散します。第1世代、第2世代の統合ミドルウェアで見られた、多くのロジックを含みながらだんだん大きくなっていくという傾向は、まさに破裂するバブルのようによろしくない方向に進んでいます。

An Ode to Middleware (OpenLegacy Blog)
http://www.openlegacy.com/blog/an-ode-to-middleware/

Figure 5 - Logic distribution in 3rd generation

第3世代のAPIプラットフォームはAPIプラットフォームは、ソフトウェア・アーキテクチャとソフトウェア開発の変曲点を真に目の当たりにしています。つまり、もはやレイヤー構造でアーキテクチャを表現できない、ということです。これは、異なるアーキテクチャを比較し、その中でどのように情報が流れるかで、評価されるというパラダイムシフトです。

Figure 6 - 1st- and 2nd-generation API platforms architectures compared

API Capability Model

以下のケイパビリティモデルは、第3世代APIプラットフォームで期待される機能を示したものです。すべての機能がプラットフォームの中核を占めるわけではありませんが、エンドツーエンドのソリューションのために重要と考えられるため、関連する機能が含まれています。個々のケイパビリティを実現するために採用可能なテクノロジーを決定するための、構造化されたフレームワークを提供するため、このようなモデルを利用することを強く推奨します。

Figure 7 - API capability model

図からわかるように、API Gatewayは、APIを実行するエンジンであるだけでなく、情報資産へのエントリポイントであり、ポリシーが適用される場所でもあるため、中心的な役割を果たします。APIが情報への入り口であれうば、API Gatewayはまさに扉です。
このモデルには明示されていませんが、第1世代および第2世代のAPI Gatewayとは異なる第3世代のAPI Gatewayを決定付ける基本的なケイパビリティがあります。

• 軽量（Lightweight）
  モノリシックでなく、アプライアンスを必要とせず、ESBも不要。軽量で、任意の場所、の展開が非常に簡単。理想的には、コンテナを利用。
• 自立（Self-sufficient）
  集中管理ユニットからAPI、ポリシー、さらにはシステムパッチを取得することが自らの責任であるべき。
• マイクロサービス指向（Microservice oriented）
  以下のことが実現できること
  • ステートレス。任意のトランザクションで状態を管理しない。
  • 任意の言語でサービスを実装できる、もしくはテクノロジーを選択できる。
  • 条件に基づいてElasticにGatewayをスケールイン、スケールアウトできる。
  • （Consul、Eurekaなどの）レジストリと統合し、動的にアクティブなサービスエンドポイントやルートをインテリジェントに判断することで、APIのロードバランサを実装できる
  • Gatewayにない機能を提供しないことで、開発者がGatewayにロジックを追加できないようにできる

Conclusion

第3世代のAPIプラットフォームは、モダンなアーキテクチャの採用を容易にする機能を提供しています。これにより、企業は新しい製品やサービスを生み出し、迅速かつ安価に提供して、関連性や競争力を維持します。
GoogleやLinkedIn、AmazonといったDigital Giantsにとって、これは旧聞でしょう。

Gartner Reveals Top Predictions for IT Organizations and Users in 2017 and Beyond  (2016, Gartner Newsroom)
http://www.gartner.com/newsroom/id/3482117

しかしながら、世界の多数の組織にとって、クラウドやDigital Transformation、顧客中心主義への旅路はまだスタートしたばかりです。
情報や機能を連携する傾向は止まらないでしょう。なぜなら、アナリストは2020年までに接続デバイスの個数が210億に達すると予測しているからです。あらゆる企業は、IoT (Internet of Things) テクノロジーを利用して顧客やパートナーとより密接に関わるため、対話の方法やサービスの提供方法が完全に変わります。
その結果、クラウドを超えて、数十億のインターネット対応デバイスに管理と接続機能を提供する第4世代のプラットフォームが必要になることでしょう。

Figure 8 - 4th generation API platforms

About the Author

Oracle ACE DirectorのLuis Weirは、Capgemini UK PLCのChief Architectで、Oracle API Management 12c Implementation (2015, Packt) およびOracle SOA Governance 11g Implementation (2013, Packt) 、数多くの記事やホワイトペーパーの著者の一人でもある。LuisはOracle OpenWorldを含む業界イベントでの登壇も多く、直近では2017年4月20日のOracle Code Londonにも登壇した。LuisはUniversitat Politecnica de Valencia (UPV)でCorporate Networks and Systems Integrationの修士号を取得、Universidad Nueva EspartaでElectronics Engineeringの学士号を取得している。