目次


軽量のアジャイル統合アーキテクチャーへの移行

コンテナー化と分権化の手法によるクラウド対応の接続

Comments

この全 2 回からなるシリーズでは、アジャイルなアプリケーションを相互接続する最新の統合アーキテクチャーを、それらのアプリケーション同様にアジャイルにするために採用されている手法を探ります。集中型エンタープライズ・サービス・バス (ESB) パターンは、ESB に意図された目的を果たし、今でもそれなりにふさわしい場所がありますが、多くの企業では、コンテナー化と分権化をより進めた統合アーキテクチャー手法を探るようになっています。現在、アジャイル統合アーキテクチャーと呼ばれているこの手法は、かつては軽量統合という用語で表現されていました。

第 1 回では ESB の宿命を探る中で、サービス指向アーキテクチャー (SOA) がもてはやされた時代に集中型 ESB パターンがどのようにして生まれ、なぜ生まれたのかに目を向けるとともに、このパターンの結果として浮上した課題についても取り上げました。また、全体像の中で API が果たす役割と、ESB パターンとマイクロサービス・アーキテクチャーとの間にある潜在的な関係についても考慮しました。この歴史的背景を踏まえることで、将来のアーキテクチャーを改善する方法について、より自信を持って発言することが可能になります。

この第 2 回で焦点を当てるのは、アジャイル統合アーキテクチャーです。最新のイノベーションのペースとスケールに応じて新しいアプリケーションに必要となる統合を行えるようにするために、マイクロサービスの背後にあるテクノロジーおよび原則を統合アーキテクチャーでどのように利用できるかについて考えます。また、業種ごとの自立性と生産性の強化を目的として、統合を根本的に分権化する仕組みについても説明します。まずは、マイクロサービスの原則が統合アーキテクチャーにもたらす利点を探りましょう。

マイクロサービスの原則を統合の際に利用する

より細分化した形でアプリケーションを構築することが理にかなっているのであれば、この考え方を統合にも適用すべきでない理由はあるでしょうか?つまり、エンタープライズ規模の集中型 ESB コンポーネントを、より小さくて管理しやすい、それぞれに固有の役割を果たす専用コンポーネントに分割するということです。公開するインターフェースごとに 1 つの統合ランタイムという粒度にまで細分化することもできますが、通常はコンポーネントごとに少数の統合にまとめるので十分でしょう。

図 1. 集中型 ESB を、個別に管理してスケーリングできる複数のコンポーネントに分割する
集中型 ESB を、個別に管理してスケーリングできる複数のコンポーネントに分割した図
集中型 ESB を、個別に管理してスケーリングできる複数のコンポーネントに分割した図

極めて集中化された ESB パターンでも、この図のように分割することができます。したがって、かつてのハブとスポークのパターンも分割できます。このように分割された個々のコンポーネントは他とは独立して簡単に変更できるため、アジリティー、スケーリング、回復力が向上します。

このきめの細かい統合デプロイメント手法に従えば、他の統合ランタイムが稼働する環境には不安定な要素をもたらさないという絶対的な確信を持って、個々の統合ランタイムに変更を加えることができます。例えば新しい機能を利用するために、別のバージョンの統合ランタイムを使用することにした場合でも、リスクを伴うアップグレードを他のすべての統合ランタイムに強制する必要はありません。ある特定の統合を、他とは完全に独立してスケールアップできるため、特に、クラウド・ベースのモデルを使用している場合、インフラストラクチャーを極めて効率的に利用できます。

当然、この手法にも考慮しなければならない点がいくつかあります。例えば、可動部分の増加による複雑化にどのように対処するかという点です。また、上記の統合デプロイメントは仮想マシン・テクノロジーを使用して実装できますが、Docker などのコンテナーと Kubernetes などのオーケストレーションを使用すれば、長期的なメリットはさらに大きくなる可能性があります。新しいテクノロジーを導入すると、統合チームがそのテクノロジーを習得するための時間が必要になることが考えられます。けれども、企業がすでに他の分野でマイクロサービス・アーキテクチャーの導入について調査しているとすれば、同じ課題に直面した組織内に、その専門知識がすでに蓄積されていることも考えられます。

上記のきめの細かい統合デプロイメントは、アジャイル統合アーキテクチャーとして説明する全体像の 1 つの側面でしかありません。私たちはアジャイル統合アーキテクチャーという用語を、純粋主義的なマイクロサービス・アプリケーション・アーキテクチャーと区別するために使用しています。また、この用語によって、より煩雑な集中型統合アーキテクチャーと密接に関連している「ESB」という用語との違いを明確にするという目的もあります。注目に値すべき点として、この概念を表すために一時期「軽量統合」という用語が使われていましたが、現在は「アジャイル統合アーキテクチャー」のほうが業界に適切な用語であると考えられています。

ここからも引き続き、この記事で取り上げるアジャイル統合アーキテクチャーのさまざまな側面をまとめていきます。このトピックについて詳細に説明している記事の数は増加の一途にあります。こうした一連の記事には、このリンク先のブログ記事からアクセスできます。

最新の統合ランタイムの概要

アジャイル統合アーキテクチャーでは、統合トポロジーを大幅に異なる方法でデプロイする必要があることは明らかです。ここで重要となる側面は、コンテナー・ベースの環境内で実行可能であり、クラウド・ネイティブのデプロイ手法にうまく適合した最新の統合ランタイムです。最新の統合ランタイムは、これまでの統合ランタイムとは似ても似つかないものになっています。具体的には、依存性がまったくないため、データベースやメッセージ・キューは不要です。ファイル・システムに配置して起動するだけでインストールできます。この点は、Docker イメージのレイヤー化されたファイル・システムには理想的です。すべての構成はプロパティー・ファイルとコマンド・ライン・インターフェース内で行うことから、ビルド・パイプラインに簡単に統合できます。また、極めて軽量であるため、数秒で起動および停止できるだけでなく、Kubernetes などのオーケストレーション・フレームワークを使用して容易に管理できます。

このような最新の統合ランタイムの好例は、IBM App Connect Enterprise (旧称 IBM Integration Bus) です。詳細については、このリンク先のブログ記事で説明していますが、IBM App Connect Enterprise は他の統合サーバーと同じく、ESB ではありません。ESB は、このランタイムに使用できるパターンのうちの 1 つであり、他の各種アーキテクチャー・パターンでも使用され、アジャイル統合アーキテクチャーという形での使用が増えてきています。

統合所有権の分権化

統合をさらに一歩進めることができます。統合が個別のコンポーネントに分割されたので、これらのコンポーネントを所有権や管理とは異なる観点で分散させるという選択肢が可能になります。アジャイル統合アーキテクチャーでは、統合ランタイムが軽量になるだけでなく、極めて使いやすくなります。優れた最新の統合ランタイムであれば、統合スペシャリストが関与しなくても使用できるほどです。

テクノロジーに関しては、上の図とまったく異なりません。異なる点は、統合コンポーネントの所有者です。この場合、アプリケーション・チームに統合を担当させることができます。アプリケーション・チームが、アプリケーションに属する統合の作成と保守を自ら担当することができるのです。下の図に示されている公開ゲートウェイによる分散化では、API の公開に関する管理権限もアプリケーション・チームに移ることを意味します。

図 2.アプリケーション・チームへの統合の分権化
アプリケーション・チームへの統合の分権化を示す図
アプリケーション・チームへの統合の分権化を示す図

この統合所有権の分権化手法には潜在的なさまざまなメリットがあります。

  • SOA チームを独立させる際に共通の課題となったのは、チームが自ら公開しているアプリケーションを理解していないことでした。アプリケーション・チームは自分たちが作成したアプリケーションのデータ構造を誰よりもよく知っています。
  • ソリューションの実装にエンド・ツー・エンドで関連するチームの数が少なくなることで、チーム間の意見交換も待ち時間も大幅に少なくなり、多数のチームが関わる場合には避けられないウォーターフォール型開発からも逃れることができます。

繰り返し言うと、分権化された統合は、技術的な課題ではなく、組織に関する課題です。

当然、この手法があらゆる状況に適切であるとは限りません。一部の組織、またはある組織の中の一部には有効であっても、この手法が功を奏さない組織もあります。また、古いアプリケーションを扱っているアプリケーション・チームには、統合作業を担当するのに適切なスキル・セットがない場合もあります。そのよう場合は、チームに統合スペシャリストを参加させる必要があるかもしれません。統合スペシャリストは変更やスケーリングに対するアジリティーを向上させる手段となる可能性がありますが、アプリケーションがしばらくの間、ほとんど凍結されていた場合を考えてみてください。最終的には、集権化された統合チームを維持していたほうが管理しやすいという結論に至る組織もあるでしょう。この手法は、この手法によるメリットが最も必要とされる場合に適用する必要があります。そうは言っても、このような形での統合の分権化は、組織はもとより、アプリケーション・チームの多くがこれまで常に必要としていたものの、特定のテクノロジーの壁を乗り越えなければ達成できなかったことです。

統合および公開の分権化への移行は、必ずしも分散化インフラストラクチャーを示唆するわけではないことに注意してください。各アプリケーション・チームが独自の公開ゲートウェイとコンテナー・オーケストレーション・プラットフォームを担当することは明らかですが、これを当然のこととして受け止めるべきではありません。重要な点は、分権化により、チームが自律して作業を行えることです。API 管理の実装方法としてかなり一般的なのは、インフラストラクチャー (ゲートウェイの HA ペアと、単一の API 管理コンポーネント・インストール環境) を共有しながらも、各アプリケーション・チームが独自のインフラストラクチャーを使用しているかのように API を直接管理するというものです。例えば、IBM API Connect では、この方法に柔軟性を与え、API インフラストラクチャーをマルチテナント方式で共有できるようにする一方、それぞれのチームが公開する API に対して各チームに完全な自律性を与えます。これと同じ仕組みを統合ランタイムに適用するには、集中型コンテナー・オーケストレーション・プラットフォームに統合ランタイムをデプロイできるようにする一方で、アプリケーション・チームがそれぞれ独立して独自のコンテナーをデプロイできるようにするという手法があります。

この手法に不都合な点があるとすれば、それは、アプリケーション・チームによって異なる使い方ができるテクノロジーをどのように管理するかという点でしょう。つまり、標準的な使用パターンとベスト・プラクティスを使用するよう促す方法が必要となります。自律性は多様性につながりがちです。すべてのアプリケーション・チームがそれぞれ独自のスタイルで API を作成するとしたら、それらの API を再利用する必要があるコンシューマーにとって複雑な事態になります。SOA の場合、SOAP プロトコルの使用に関するあらゆる側面に対して厳格な標準を確立する試みが行われましたが、こうした標準はコンシューマーには当然理解しにくく、必然的に SOA の導入が減少することになりました。RESTful API では、厳格な標準ではなく、慣例に基づいてコンバージェンスが行われるほうが一般的です。いずれにせよ、分権化された環境であっても、企業全体で適切なレベルの共通性を確保する方法を見つける必要性があることは明らかです。企業の別の分野でマイクロサービス・ベースの手法をすでに調査したことがあるとすれば、当然、自律性に伴う課題は十分理解していることでしょう。

注目すべき点は、この分権化手法はクラウドに移行する場合は特に効果を発揮することです。この手法では、統合はすでにクラウド対応という形で、基幹システムに合わせて実装されていることになります。アプリケーション関連の統合は、関連のない他の統合とは切り離されているため、アプリケーションとともに手際よく移行できます。さらに、コンテナー・ベースのインフラストラクチャーは、クラウド対応の原則とコードとしてのインフラストラクチャー手法に従っていれば、クラウドに移植するのが大幅に簡単になるとともに、クラウド・ベースのスケーリングとコスト・モデルをより有効に活用できます。しかも統合を所有するのはアプリケーション・チームであることから、アプリケーションの一部として効率的に統合をパッケージ化できます。要するに、分権化された統合は、クラウドへの対応を大幅に迅速化するということです。

以上の手法に従うことで、集中型 ESB パターンからはかけ離れたパターンになります (実に、ESB という用語はこの完全に分権化されたパターンに関しては何の意味もなくなります)。けれども、アプリケーションのデータと機能を企業内外の他のアプリケーションからでも再利用できるようにするという目的を達成しようとしていることに変わりはありません。

「アプリケーション」と「統合」の違い

アプリケーション開発グループが統合に着手した後は、誰もが口にしたくない重要な問題が残ります。それは、アプリケーション開発グループが「アプリケーション」の開発ではなく「統合」の開発を行うのはどの点なのかという問題です。

アプリケーションと統合との間でバランスをとるという行為は、常に SOA を悩ませてきました。この 2 つのバランスをとるために、アプリケーション部門と統合部門に間の亀裂が深まり、その結果、チーム間でのウォーターフォール・スタイルの要件が幾重にも重なって、プロジェクトの進行が遅くなるからです。多くの場合、統合チームは統合ロジックだけを扱い、アプリケーション・ロジックには手出ししないよう指示されます。これは一般に、企業全体にわたってビジネス・ロジックが複数のチームとコンポーネントにまたがることを回避するためです。

けれども、個別のチームという境界がなかったとしたらどうなるでしょう?前のセクションでの場合と同じように、それぞれに特化された各種のツールを集めた 1 つのチームが統合を担当する場合を考えてください。例えば、あるツールはユーザー・インターフェースに特化していて、別のツールはソリューションの特定のニーズ (ルール・エンジンや機械学習など) に特化しているという場合です。もちろん、そこには常に統合の必要性もあります。

マイクロサービス・アプリケーションでは、個々のマイクロサービス・コンポーネントは比較的小さく、特化されています。通常は、その役割が統合エンジンにうまく適合するコンポーネントを見つけることができます。例えば、すべてのマイクロサービス・コンポーネントが API を提供していて、それぞれの API が他のシステムに対するいくつかの呼び出しを行い、それらの呼び出しの結果を照合してマージした上で、呼び出し側にレスポンスを返していたとします。この状態は、ほとんど統合と同じことです。将来的には、数百行を超えるコードよりも単純なグラフによるフローを使用したほうが、保守が容易になります。つまり、API によって呼び出されるシステムをグラフで示し、そのグラフからデータ項目がマージされる場所を簡単に見つけて、視覚的にマッピングを表現できるようにするという方法です。

ですが、この方法は実際に何を意味するのでしょうか。これまでのセクションで説明したように、アジャイル統合アーキテクチャーでは、統合ランタイムが実に軽量のコンポーネントになり、クラウド・ネイティブのスタイルで実行できるようになります。マイクロサービス・アーキテクチャーの主な利点の 1 つは、1 つの特定の言語またはランタイムに束縛されなくなることです。つまり、それぞれの目的を果たす異なるランタイムの集合として、多言語ランタイムを使用できます。したがって、マイクロサービス・アプリケーションの単なる別のランタイム選択肢として統合を導入できない技術的理由はありません。

図 3. マイクロサービス・コンポーネントとして軽量統合ランタイムを使用
マイクロサービス・コンポーネントとして使用されている、軽量の統合ランタイムを示す図
マイクロサービス・コンポーネントとして使用されている、軽量の統合ランタイムを示す図

別の例を見ていきましょう。マイクロサービスの世界では、イベント・ソーシング・アプリケーションや結果整合性手法を使用したパターンが高く評価されるようになっていることから、メッセージングへの関心が復活してきています。この先、キューやトピックからメッセージを取得して、ほんのわずかな変換を行った後、結果をデータ・ストアにプッシュするというだけではないマイクロサービス・コンポーネントを頻繁に見かけるようになるでしょう。けれども、こうした処理を行うコンポーネントには、驚くほど多数のコード行が必要になることが考えられえます。統合エンジンであれば、構成可能なコネクターとグラフィカル・データ・マッピングを使用して、この処理を実行することが可能です。したがって、メッセージやデータ・ストアとの接続の詳細の多くを理解する必要はありません。また、統合エンジンでは、簡単に保守できるフロー図とデータ・モデル・マッピングを使用して、移行の保守を容易にすることもできます。

この手法を話題にするときに必然的に浮かび上がってくる疑問は、マイクロサービス・アプリケーション内で ESB を使用することになるのかというものです。この懸念に真っ向から対処することが、極めて重要になります。前に定義したように、統合ランタイムは ESB ではありません。ESB は、統合ランタイムを組み込むことができるアーキテクチャー・パターンの 1 つであるというだけの話です。極めて集中化された ESB は、第 1 回 で説明したエンタープライズ・スコープのアーキテクチャー・パターンです。最新の軽量統合ランタイムは、この集中型 ESB パターンとは大きく異なり、アプリケーションの統合関連の側面を実装し、各統合を個別のコンポーネントに独立してデプロイするために使用します。したがって、前述の疑問に対する答えは「ノー」です。軽量統合ランタイムを使用して個別の統合をコンテナー化するとしても、ほぼ確実に、マイクロサービス・アプリケーション内に ESB パターンを再現させていることにはなりません。

ここでは、統合ランタイムの目的を、当初意図された目的とは根本的に異なって解釈しています。従来、統合ランタイムは主に個別のアプリケーションを統合するために使用されていました。その役割はこれからも果たすはずですが、ここではアプリケーションを構成するコンポーネントとして統合ランタイムを使用することについて話しているのです。

かつては、統合ランタイムはアプリケーション開発者のツールボックスの一部とみなされていなかったため、アプリケーションのコンポーネントとして統合ランタイムを使用するのは困難でした。JEE アプリケーション・サーバー上の Java のように、アプリケーションは土台からして単一言語に制約されたサイロ型アプリケーションとして作成されていたため、チームには統合を作成するスキルも実行するスキルもありませんでした。当時の統合ランタイムは、統合製品と統合パターンでのスキルに長けた、完全に別個のチームが所有して実装していました。

統合ランタイムとツールの単純化が進んだことから、別の専属チームを設けて統合ランタイムを実装し、運用する必要はなくなりました。現在は、統合ランタイムを作成するのも保守するのも、かなり簡単になっています。コンテナー・オーケストレーションからルーティング・フレームワーク、ソース・コード・リポジトリー、ビルド・パイプライン、テスト・ツールまでに至る他のマイクロサービス・コンポーネントに使用するツールと手法と同じものを使って、統合ランタイムをモニタリング、管理、スケーリング、診断することができます。

マイクロサービス・アーキテクチャーの主要な利点は、目の前のタスクに最適なランタイムを自由に選べることです。これまでの説明を踏まえれば、マイクロサービス・ベースのアプリケーションには統合に似た処理を行うコンポーネントがあることから、軽量統合ランタイムを使用できない理由は何もないことは明らかです。

取るべき道

ここまでで、集中型 ESB パターンを一部のケースで次の新しい手法によって置き換える方法を説明してきました。

  • きめの細かい統合デプロイメント。コンテナー化を利用して、アジリティー、スケーラビリティー、回復力にはるかに優れた方法で統合ランタイムを使用できるようにします。
  • 統合所有権の分権化。統合の所有権をアプリケーション・チームに渡すことで、ソリューション全体の作成および運用に関与するチームと手法の数を減らします。
  • クラウド・ネイティブの統合インフラストラクチャー。マイクロサービス・アーキテクチャーの多言語の特性を生かし、軽量統合ランタイムを使用して統合に特化したマイクロサービス・コンポーネントをより生産的な形で実装します。

現時点の組織にとって以上の手法が適切であるかないかは、個別に決定することです。この記事ではこれらの手法を導入する際に考えられる手順を説明してきましたが、他にも完全に有効な手順はあります。

例えば、組織がアプリケーション・チームごとに固有の ESB パターンを実装できるようにしたいと考えている場合は、統合所有権の分権化への移行は、よりきめ細かい統合デプロイメントへ移行する前段階になります。厳密に言えば、これは実際にはアプリケーション・サービス・バスまたはドメイン・サービス・バスになるでしょう。アプリケーション・チームが独自の統合の所有権を持つことは確かに統合所有権を分権化すると言えますが、きめ細かい統合デプロイメントということにはなりません。それは、チームのアプリケーションに関連するすべての統合を含む 1 つの大きいインストール環境があることには変わりがないためです。

実際には、複数の手法を使用したハイブリッド統合アーキテクチャーの可能性が見えてくることでしょう。例えば、組織がすでに構築している集中型 ESB を使用して対応している統合が、比較的安定していて、リファクタリングによって直ちにビジネス利益がもたらされることはないとします。その場合、既存の ESB を引き続き使用しつつ、近いうちに変更することが見込まれる新しい統合については、コンテナー化された軽量統合ランタイムの使用を調査することが考えられます。

最終的な考え: ポイント・ツー・ポイントへの復帰

第 1 回で記載した元のポイント・ツー・ポイントの統合図を、この第 2 回で記載している最終的に完全に分権化された統合図 (図 3) と比較すると、一周して元のポイント・ツー・ポイント統合に戻ったという結論を出したくなるかもしれません。データを必要とするアプリケーションが直接プロバイダー・アプリケーションにアクセスするということは、出発点に戻ったということでしょうか?

この難問を解決するには、そもそもポイント・ツー・ポイント統合で問題となっていた内容を振り返る必要があります。ポイント・ツー・ポイント統合で問題として受け止められていたのは、インターフェース・プロトコルが多種多様であったこと、そして必要となる技術的統合機能が、アプリケーション・プラットフォームですぐに使用できる状態にはなっていなかったことです。こうした問題により、2 つのアプリケーションを統合するときには、そのたびに、新しい複雑な統合を中心としたコードをサービス・コンシューマーとサービス・プロバイダーの両方で作成しなければなりません。

その状況と比べると、最新の分散型統合パターンでは使用するインターフェース・プロトコルが単純化および合理化されていて、多数のプロバイダー・アプリケーションが RESTful API (少なくとも Web サービス) を提供できるようになっています。また、ほとんどのコンシューマーにはこれらの標準に基づくリクエストを行うのに必要なものが十分に備わっています。

アプリケーションでプロトコルに基づくインターフェースを提供できない場合でも、アプリケーション・チームは、主に単純な構成と最小限のカスタム・コードを使って迅速に API/サービスを公開できる強力な統合ツールを利用できるようになっています。こうした統合ツールは、広範囲にわたる新旧のデータ・ソースとプラットフォームを接続できるだけでなく、共通の統合ニーズを満たすこともできます。つまり、データ・マッピング、解析/シリアル化、動的ルーティング、復元パターン、暗号化/復号、トラフィック管理、セキュリティー・モデルの切り替え、アイデンティティーの伝播などのさまざまな統合ニーズに、同じく単純な構成を使用して対応できるため、複雑なカスタム・コードを作成する必要がさらに軽減されます。

さらなる利点として、API 管理ツールが成熟したおかげで、これらのインターフェースをコンシューマーに公開できるだけでなく、次の目的も達成できるようになっています。

  • 潜在的コンシューマーが簡単にインターフェースを検出できるようにする。
  • 新しいコンシューマーのセキュアな自己管理型オンボーディングを可能にする。
  • 使用状況と依存関係を理解するためにアナリティクス機能を提供する。
  • 外部へのインターフェース公開を促進し、外部の関係者がインターフェースを使用できるようにする。
  • API を収益化する (API を単なる技術的インターフェースではなく、企業が提供する製品として扱うことで、API の収益化を実現できる場合もあります)。

この標準ベース寄りの API 主導の統合では、あるアプリケーションがコンシューマーとして別のプロバイダーのアプリケーションによって公開されている API を利用する際に、どちらの側にも負担はほとんどありません。

まとめ

テクノロジーの進化を踏まえ、アジャイル統合アーキテクチャー手法を調査する方法の例をいくつか簡単に振り返りましょう。

  • 最新の統合ランタイムは、せいぜい数分でインストールできます。実際、ビルド済み Docker イメージを使用すれば、数秒以内で Docker コンテナーを起動することができます。
  • Kubernetes や Docker Swarm などの標準的なコンテナー・オーケストレーション・プラットフォーム内で統合ランタイムを実行することにより、専門知識がなくても、統合ランタイムのクラスターを管理できます。
  • スケールアップとスケールダウン、および復元ポリシー、ルーティング・ポリシー、セキュア通信チャネルのセットアップは、その他すべてのアプリケーション・コンポーネントと同じく標準化された方法で行うことができます。
  • 標準的な継続的デリバリー・ツールによってビルド・パイプラインを自動化するために使用できる、コマンド・ライン・インターフェースとテンプレート・スクリプトが提供されます。これにより、インターフェースを実装するために必要な知識が少なくなるとともに、デリバリーのペースが上がります。
  • 統合ツールは、ほとんどのインターフェースを構成のみで作成できるまでに改善されています。したがって通常は、統合の経験がない個人でも実装できます。共通の統合パターンに対応するテンプレートに加え、統合タスクをさらに単純化する、統合のベスト・プラクティスがツールに焼き付けられています。統合に深い知識を持つスペシャリストが必要になることが少なくなり、場合によってはアプリケーション・チームが統合を担当できることもあります。

かつてのポイント・ツー・ポイントの時代は、明らかに遠い過去になっています。アプリケーション・チームがその役割に適した統合機能を使用できれば、企業内外にわたるデータを、(正しい方法で行えば) アジリティー、スケーラビリティー、回復力を確保した保守しやすい方法で公開および使用できます。

謝辞

この記事の情報提供および資料のレビューで協力してくれた、Andy Garratt、Nick Glowacki、Rob Nicholson、Brian Petrini、Claudio Tagliabue に感謝の言葉を贈ります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1064639
ArticleTitle=軽量のアジャイル統合アーキテクチャーへの移行
publish-date=02142019