fbpx

レガシーと統合する方法-デジタルプラットフォームの中核を生み出す

インテグレーション(統合)は、コンピュータアプリケーションを連携させて意味のある結果を提供するための接着剤です。統合の概念とベストプラクティスの多くは何十年も前から存在していますが、アプリケーションを作成する新しい方法では、これらの統合パターンを再評価する必要があります。たとえば、複数のモノリシックアプリケーションを統合することは困難ですが、マイクロサービスやその他の分散配置パターンの台頭により、この課題は飛躍的に大きくなっています。

技術ランドスケープ

特にモノリシックレガシーアプリケーションの統合に関する従来の「純粋な」統合を扱う場合、リアルタイムコネクタと非同期メッセージキューという2つのアプローチがすぐに最も一般的に現れます。

これらの2つのアプローチはどちらも、現代のアーキテクチャではまだ実行可能な概念ですが、現実の世界で実装する場合は注意深く検討する必要があります。これらの考慮事項には、次のようなトピックが含まれます。

  • リソースとスキルのトレーニング
  • インフラストラクチャの複雑さ
  • 市場投入までの時間
  • 開発のタイムライン
  • 全体的なライセンスと実行時のコスト

最近のガートナーの予測では、「2020年までの統合により、デジタルプラットフォームの構築にかかる時間とコストの60%が消費される」と推定されています。これは、統合が最新のデジタルプラットフォームのコアであり、それらがもたらすイノベーションと足並みを揃えるべきであるという事実を反映しています。

統合の概念とベストプラクティスの多くは何十年も前から存在していますが、アプリケーションを作成する新しい方法は、これらの統合パターンの新しい見方を指示します。統合は現代のデジタルトランスフォーメーションの中核であり、それらがもたらすイノベーションと足並みを揃えるべきです。

リアルタイムコネクタ

これらのタイプのコネクタは、エンタープライズ統合の初期の頃から存在しています。それらはポイントツーポイント接続プロトコルとして始まりましたが、後にEAIのハブアンドスポークモデルとESBのエンタープライズバスコンセプトに進化しました。これらの場合、それらはアプリケーションへの接続の最後のマイルを提供し、特定のプロトコルまたは言語用に特別に設計されています。

その特異性のため、iWay Softwareなどのベンダーが、サイロ化されたアプリケーションをミドルウェアに接続する一連のコネクタを提供することが一般的になりました。各コネクタには、独自のセットアップとスキルが必要です。このアプローチは、JSON-RESTプロトコルでメインフレームのCOBOLベースのアプリケーションを公​​開し、APIミドルウェアで使用できるようにするIBMのz / OS 接続などの製品で現在でも非常に一般的です。

1.複雑なセットアップとメンテナンス

これらのコネクタは通常、レガシーシステムの実行に依存しており、他の複数の製品と現在のOSバージョンをインストールする必要があります。

たとえば、IBM z / OS Connectには、z / OSおよびCTSの最新リリースだけでなく、場合によってはIBM z / OSエクスプローラー、WebSphereサーバー、WOLA(WebSphere z / OS Optimized Local Adapters) 、IBMのAPI接続およびZos Connect EEサーバーのインストールも必要です。

2.ブラックボックス

ラストマイルコネクタはレガシーアプリケーションと緊密に結合されているため、閉じられて設定できなくなる傾向があります。変更やカスタマイズは、パフォーマンスや複雑さを犠牲にしても、上位レベルのレイヤーで行う必要があります。動的メッセージフォーマット、リクエストコンテキスト、ステートフルな呼び出しの処理は、労働集約的で時間のかかる作業になります。

3.ライフサイクルの自動化

これらのコネクターの閉じた性質から生じる別の問題は、DevOpstype 自動化をサポートできないことです。これらのコネクタによって生成されるAPIのテスト、バージョン管理、および展開はすべて独自仕様であり、通常の開発ライフサイクルと統合するのは困難です。これにより、開発期間が長くなり、リリースサイクルが長くなり、速度と俊敏性に影響します。

4.必要な重いインフラストラクチャ

統合の最後のマイルであり、ソリューションを生成するために他の多くのレイヤーを必要とするコネクターを使用する場合、必要なアーキテクチャトポロジーとインフラストラクチャは、重く、多層化され、低速で複雑になります。

これらのアーキテクチャは、ミドルウェアをほとんど必要とせず、統合を障害ではなく機能として扱う、モダンで軽量でフラットなマイクロサービスアーキテクチャとは対照的です。組織が古いスタイルのESB統合スタックの上に最新の最先端のマイクロサービスアーキテクチャを展開して、組織が努力のメリットを享受できないのは、あまりにも一般的です。

非同期メッセージキュー

繰り返しになりますが、非同期性は新しい統合概念ではありません。1990年代と2000年代には、サービス指向アーキテクチャー(SOA)の標準となり、IBMのMQなどの製品に広く普及しました。

非同期メッセージングモデルを使用する多くの理由があるかもしれませんが、その過去の成功に貢献した2つの要因がありました:

  • 非同期メッセージングは、pub-subなどのSOAのオーケストレーションの概念とよく相関しています。
  • 非同期メッセージングは、規制産業で必要とされる保証配信機能を使用してフォールトトレランスを提供し、ハードウェアの可用性とスケーラビリティが現在と比較して制限されている世界で特に重要な役割を果たしました。

これらの非同期ソリューションに支払う代償は、主に複雑さとパフォーマンスにありました(ミドルウェア(例:MQ)製品の実際の価格は、かなりの額になるとは考えていません)。この価格は、限られた内部のデータ消費者、すでに複雑なアーキテクチャ、限られた速度のニーズに牽引されている世界では、比較的小さく見えました。

今日の要件は、これらの仮定に困難な課題を投げかけています。フォールトトレランスは新しいアプローチを使用して達成でき、データの消費者は数と種類がはるかに多く、アーキテクチャの複雑さが軽減され、変更を展開する速度の必要性がかつてないほど高まっています。

もちろん、これは非同期メッセージングが関連していない、または最新のアーキテクチャで使用されるべきではないという意味ではありませんが、どこにいつ展開するかについての計算を変更します。簡単に言うと、メッセージキューイングはもはやデフォルトではなく、慎重に決定する必要があります。

これらの非同期ソリューションに支払う代償は、主に複雑さとパフォーマンスにありました(ミドルウェア(例:MQ)製品の実際の価格は、かなりの額になるとは考えていません)。

優れたレガシー統合のソリューション

優れたレガシー統合のソリューションは、これらの問題の多くに対する解決策を提供し、統合への新しい、モダンでユニークなアプローチを表しています。コード生成、マイクロサービス、標準のオープンソースフレームワークなどの概念を活用することで、次世代の統合プラットフォームを提供します。

優れたレガシー統合のソリューションは、統合のレイヤーごとにレイヤーの背後に隠されたブラックボックスコネクタの代わりに、実行可能なマイクロサービスである単一のデプロイ可能なユニットを自動的に生成します。このマイクロサービスは、APIインターフェース、ビジネスロジックペイロード、およびレガシー機能をラップするJava SDKで構成されています。

このアーティファクト全体は、注釈を使用して読み取り可能な標準Javaコードで表示および変更できます。

このアプローチでは、セットアップや追加のインフラストラクチャは必要ありません。マイクロサービスはどこにでもデプロイでき、レガシーシステムとネイティブに通信します。サードパーティ製品、追加のインストール、レガシースキルは必要ありません。

コードベース全体が利用可能で表示可能なため、ビジネスロジック、統合ロジック、チャネルロジック、またはコネクタロジックの変更は、特定のマイクロサービスに直接、またはテンプレートを使用して、生成されたすべてのマイクロサービスに加えることができます。これにより、Git、Jenkinsなどの標準ツールを使用したDevOpsおよび自動化プロセスとのシームレスな統合も可能になります。

ソリューションの性質上、アプリケーションアーキテクチャを一致させ、基本的にミドルウェアなしで統合を可能にすることで、フラットな統合アーキテクチャを実現します。フォールトトレランスは、サーキットブレーカーと水平方向のスケーラビリティ、および回復性のログ分析を使用して管理されます。

SNSでもご購読できます。

コメントを残す

*