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)このため、あらゆる規模の組織は、TCOを削減する手段としてだけでなく、digital transformationと顧客中心主義を実現する手段としてクラウド（SaaS、PaaS、IaaS）を採用しています。
http://www.techradar.com/news/world-of-tech/who-are-the-digital-disruptors-redefining-entire-industries-1298171
The NIST Definition of Cloud Computing(2011, National Institute of Standards and Technology)しかしながら、クラウドへの移行は1つのクラウドを意味しません。調査から、組織は全てを一つのクラウドベンダーに任せるのではなく、マルチクラウド戦略を選択していることが透けて見えます。
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
The future isn't cloud. It's multi-cloud (2017, Network World)クラウドの採用に対するこのbest-of-breedアプローチは、ERPのようなオンプレミスのモノリシックシステムやその他のオンプレミスアプリケーションを、個別のSaaSアプリケーションやPaaSと統合もしくはPaaSで拡張されたものとして、クラウドで再実装することを意味します。
http://www.networkworld.com/article/3165326/cloud-computing/the-future-isnt-cloud-its-multi-cloud.html
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)マイクロサービス・アーキテクチャがクラウド・ネイティブアプリケーション実装のためのアーキテクチャスタイルとして優勢になってきましたが、こうするために、モノリスをより小さなピースに分割して各々のピースがbusiness capabilityを表すようにした上で、完全に疎結合なサービス（マイクロサービス）として実装します。この実装は通常PaaSで実施します。
http://searchcloudcomputing.techtarget.com/essentialguide/Developing-cloud-applications-in-the-new-IT-era
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 |
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)iPaaSのセールスポイントは、クラウドおよび/またはオンプレミスのシステムに接続し、必要なアクセスを提供できるという点です。堅牢なiPaaSプラットフォームは、RESTfulアプリケーションプログラミングインターフェイス（別名Web API）を使って情報へのシームレスなアクセスを提供するために、クラウドおよび/またはオンプレミスアプリケーションに接続できる必要があります。
http://www.soa4u.co.uk/2017/03/ipaas-what-is-it-exactly-is-it-on.html
Representational state transfer (REST) (Wikipedia)情報への標準的で一貫した安全なアクセスを提供する手段としてAPIを使えば、マルチチャネルアプリケーションは必要なときに必要な資産を利用できます。
https://en.wikipedia.org/wiki/Representational_state_transfer
 |
| Figure 3 - iPaaS solution with API management capabilities |
3rd-Generation API Platform
クラウドが採用され、情報が地理的に分散するにつれて、アクセスがますます重要になります。 接続性を提供するVPNを確立することは、早晩実現困難になります。SaaSベンダーはデータベースへの直接アクセスを提供しないため、多くの場合、問題を解決できないからです。代わりに、情報にアクセスするための唯一の手段としてAPIが提供されます。現時点では、第2世代のAPIプラットフォーム（基本的にESBやAPI管理機能を強化したXMLアプライアンス）では能力不足で、クラウドの採用とdigital transformationから生じる最新の要件を満たすことは難しいのです。
 |
| Figure 4 - 3rd-generation APIs everywhere |
- うんざりするようなオペレーションや膨大なコストをかけずに、（任意のベンダーのクラウドやオンプレミスでも）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 |
 |
| Figure 6 - 1st- and 2nd-generation API platforms architectures compared |
API Capability Model
以下のケイパビリティモデルは、第3世代APIプラットフォームで期待される機能を示したものです。すべての機能がプラットフォームの中核を占めるわけではありませんが、エンドツーエンドのソリューションのために重要と考えられるため、関連する機能が含まれています。個々のケイパビリティを実現するために採用可能なテクノロジーを決定するための、構造化されたフレームワークを提供するため、このようなモデルを利用することを強く推奨します。 |
| Figure 7 - API capability model |
このモデルには明示されていませんが、第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 |
0 件のコメント:
コメントを投稿