アプローチ
多くの企業では、ビジネスに不可欠なレガシーのJava EEアプリケーションを、10年から15年という長い期間にわたって運用しています。これらのアプリケーションは、理解、維持、強化が難しく、近代化するのも困難です。ユーザーは、これらのレガシーアプリケーションを、アジリティ、選択的なスケーラビリティ、メンテナンス性、経済性のために、クラウドサービスモデルであるContainers as a Service（CaaS）環境に移行したいと考えることが多い。
しかし、シンプルで一般的なリフト＆シフト方式では、選択的なスケーラビリティとメンテナンス性の要求に応えられないことが多く、開発チームは選択したアプリケーション群をマイクロサービスにリファクタリングする必要があります。アプリケーションをリファクタリングする現在のアプローチは、ほとんどが手作業によるものです。
当然のことながら、このような手作業によるアプローチは、時間とコストがかかり、開発者側には専門的なスキルと経験が必要です。手動でのリファクタリングに多大なリソースを費やしたとしても、複雑さ、コード内の予期しないパターンや依存性、元のアプリケーションに関するアーキテクチャの知識と現在の実装との間の不整合などが原因で、取り組みはしばしば放棄されます。
ユーザーは、よく知られているストラングラー・パターンやドメイン駆動設計を利用して、アプリケーションの端にあるいくつかのマイクロサービスをリファクタリングすることに頼ることが多いのですが、実際の複雑さが存在するアプリケーションのコア・ビジネス・モジュールにはほとんど手をつけません。なお、レガシーモノリスのコアビジネスモジュールのリファクタリングを成功させると、一般的にROIが最大になると言われています。
この手作業によるプロセスを改善し、モノリスをマイクロサービスに分割することを容易にするために、IBMはMono2Microツールを構築しました。このツールはIBM WebSphere Hybrid Editionの一部として提供されています。主に学界で使用されている他のマイクロサービス抽出ツールと比較したMono2Microの評価については、本学会発表をご覧ください。
なぜモノリスをマイクロサービスに分解するのは難しいのか？¶
Mono2Microがどのような機能を持ち、なぜ多くのユーザーに適しているのかを説明するために、まず、モノリスを論理的に分解することがなぜ難しいのかを説明します。
まず第一に、アプリケーションのレガシーな部分が圧倒的に複雑であるということです。私たちが出会った、そしてユーザーが最も苦労しているレガシーアプリケーションは、設計が古いだけでなく、当初のアーキテクチャの意図、設計、実装の制約を超えて、時間をかけて拡張、更新されています。
新しいフレームワークやデザインパターンが頻繁にアプリケーションに追加されました。この拡張では、新しいデザインパターンに合わせるために、アプリケーションの特定の機能が重複していることが多く、一方で、古い機能の重複はそのままで、連動して動作していることがありました。以前はうまくカプセル化されていたオブジェクトや明確に定義されていた機能インターフェースに、ショートカットやアンチパターンが導入されました。 これらの融合した実装は、元のアプリケーション・アーキテクチャをきれいに実現するものではなくなりました。その結果、現在のアプリケーションで使用されている実際の運用プロセスを完全に理解することは非常に困難な作業となっています。しかし、この理解は、このようなレガシーモノリスアプリケーションをリファクタリングするためのアイデアや戦略に取り組む前に必要な最初のステップです。
2つ目の課題は、エンタープライズアプリケーションの設計方法と、これらのアプリケーションが実装されたオブジェクト指向のパラダイムにあります。一般的なエンタープライズアプリケーションは、1つまたは複数の集中型ビジネスプロセスを実装しており、シリアル化されたトランザクションに依存し、同期化されたデータオブジェクトと状態を共有しています。一方、マイクロサービスは、分散コンピューティングアーキテクチャをベースにしており、中央集権的なプロセスモデルとトランザクションを放棄し、最終的には同期化と分散オブジェクトの状態を採用しています。このように、マイクロサービスはアプリケーションの設計に大きなパラダイムシフトをもたらします。開発者は、レガシーのモノリスアプリケーションに存在するトランザクションとオブジェクトの依存関係（状態とデータの両方）を完全に理解し、リファクタリング可能な部分を決定し、オブジェクトの依存関係を最小限に抑えることができる「自然な継ぎ目」を探す必要があります。
モノリスの静的解析は、このような発見には適していません。なぜなら、これらの依存関係の多くは、コールグラフやオブジェクトの交換からすぐにはわからないからです。伝統的なオブジェクト指向デザインは、この問題をさらに複雑にしています。例えば、オブジェクトは、継承関係を通じて互いに強い依存関係を持つことがあり、パラメータパスを通じて交換されるオブジェクトは、データの状態だけでなく計算ロジックもカプセル化しています。そのため、あるクラスから別のクラスへ、オブジェクトをパラメータとして特定の呼び出しを行ったとしても、実行時には異なる挙動を示し、異なるタイプのオブジェクトが関与する可能性があります。このようなオブジェクト指向は、リファクタリングされたコードの中で明確なAPIを定義するという作業を困難なものにしています。
細心の注意を払って実行しても、リファクタリング分析では、特定の依存関係や動的な動作を見逃すことがよくあります。このような事態は、分析段階ではなく、開発者がリファクタリングされたサービスの実装を開始する実行段階で発生する可能性があります。ここで、リファクタリングされたアプリケーションにエラーがあることがわかっても、そのエラーの原因を特定するのが難しいというキャッチボールのような状況に陥ります。コードを調整する際に発生したバグが原因なのか？依存関係のミスが原因なのか？壊れたトランザクションがあるのか？あるいは、同期していないデータがあるのでは？などなど、数え上げればきりがありません。結果として、アプリケーションのリファクタリングが失敗した場合、何が悪かったのか、どうすれば改善できるのかについて、検証可能な洞察はほとんど得られません。高価な作業は本質的に "サンクコスト "になってしまうのです。
Mono2Microは、このような課題に対処するために特別に設計されています。Mono2Microは、このような課題に対処するために特別に設計されており、リファクタリングの提案が検証可能な証拠に基づいて行われることを保証します。また、リファクタリング作業を通じて十分なデータポイントが得られるため、問題や予期せぬ依存関係に遭遇した場合でも、迅速に診断して特定することができます。Mono2Micro は、リファクタリングされた各サービスに対するコード変更の影響を局所的に把握するのに役立ちます。Mono2Microは、モノリス・アプリケーションの既存のテストケースを、リファクタリングされたバージョンのテストにほぼ再利用できるようにします。
モノリスの分割に関する一般的なアプローチ¶
Mono2Microのリファクタリング手法に注目する前に、モノリスをマイクロサービスに変換する際によく試みられる2つの戦略について説明しよう。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ドメイン駆動設計¶
ドメイン駆動設計は、モノリスからリファクタリング可能なサービスコンポーネントを特定するための戦略としてよく知られています。よく定義されたビジネスドメインを実装するコードの特定のセットが識別でき、そのドメインのデータとインタラクションの境界がきれいに記述されていれば、そこから独立したマイクロサービスのセットを構築できる可能性が高いという点で、マイクロサービスアーキテクチャの要件に合致します。
しかし、実際には、レガシーアプリケーションできれいなドメイン境界を特定することは非常に困難です。ビジネス・ドメインは、ビジネス・プロセスやアーキテクチャ・レベルでの概念です。この設計をJava EEで実際に実装すると、必然的にさまざまなクラス、メソッド、オブジェクトの状態の依存関係が発生します。また、前述したように、時間の経過とともにアプリケーションの拡張や変更が行われると、元のアーキテクチャ設計とは一致しない可能性のある依存関係がさらに発生します。そのため、意図的にドメイン境界を仮定して始めたとしても、現在のコードの実装がそのようなきれいな境界を持っているかどうかは不確かです。
このようなレガシーアプリケーションでは、アプリケーションのリファクタリングを行う際に、何を書き換える必要があるのか、APIをどのように形成すればよいのか、オブジェクトの状態をどのように交換すればよいのかを正確に判断することが非常に困難であることがよくあります。開発者は、コードレベルでのドメインブレークダウンが実現可能かどうかを示唆する証拠をほとんど持っていません。理想的には、開発者とアーキテクトは、様々なビジネスユースケースの下で、潜在的なドメイン境界を越えてアプリケーションがどのように振る舞うかを観察し、その観察結果を分析して、特にリファクタリングの作業中に、さらに証拠に基づく評価を行いたいと考えています。
ドメイン駆動設計は、グリーンフィールドアプリケーションをマイクロサービス形式で開発するための貴重なアプローチですが、ブラウンフィールドのモノリスをマイクロサービスに変換するためにはあまり有効ではないと考えています。
レガシーアプリケーションの絞め殺し¶
Stranglerパターンは、手間をかけずにメインのアプリケーションから独立させることができるアプリケーションの部分を特定し、その部分をマイクロサービスにリファクタリングしようとするものです。最初は、絞られたモノリスはハイブリッドモデルとして動作し続けることができます。つまり、元のモノリスから取り出された1つまたは少数のマイクロサービスと、分離されてマイクロサービスに変換されたコンポーネントを取り除いた元のモノリスのバージョンとを組み合わせます。最終的には、同じ段階的分離の原則に従って、アプリケーション全体を徐々にマイクロサービス化していくかもしれません。
このアプローチが広く提唱されていても、実際には、レガシーアプリケーションの中で、特にコアビジネスロジックに関しては、そのようなストラングラーを特定することは容易ではありません。
このようなストラングラーを真に独立させるためには、一般的に3種類の依存関係を考慮する必要があります。
* *プロセスの依存性。* *プロセス依存: Java EEアプリケーションは一般的に一連のビジネスプロセスを実装しているため、プロセス全体をカプセル化できれば、ストラングラーは真に独立したものとなります。 * アプリケーション・コードの依存性。アプリケーションコードの依存性：コード構造自体には、継承、呼び出し、包含、パラメータの受け渡しなど、相互に依存関係があります。ストラングラーが独立したものであるためには、これらの依存関係は、APIとして公開され書き換えられるか、コードの書き換えによって除去される必要があります。 * オブジェクトの状態の依存性。アプリケーションやプロセスの異なる部分は、共通の共有オブジェクトの状態のセットに仮定を持っているかもしれません。ストラングラーが独立するためには、共有オブジェクトの状態が同じサービスに存在するか、独立するために変換する必要があります。
実際には、大規模なアプリケーションにおいて、依存関係を決定論的にうまく特定することは非常に困難な作業であることが多いです。特に、これらの依存関係の一部がコードベース自体の分析からは明らかでない場合には、その傾向が強くなります。レガシーアプリケーションは、首を絞めるイチジクの木というよりも、多くの枝が交差している古代のオークの木に似ていると言われています。枝分かれした部分を手作業で追跡し、すべての依存関係を考慮して、実行可能な絞殺者にたどり着くためには、大規模で高度な複雑さに対応できるインテリジェントなソリューションが必要です。
<サイドバー>Mono2Microを使用したシンプルなストラングラーパターンの例は、Strangler Pattern Exampleを参照してください。
このようなソリューションを開発できたとしても、Java EEアプリケーションの動的な性質やレガシーな側面のために、隠れた依存関係を見落とす可能性があります。そのため、リファクタリングされたサービスが実際に有効であるかどうかを検証し、有効でない場合は何が欠けているのかを理解する必要があります。Mono2Microは、AIが支援するリファクタリングアドバイザリーにより前者の問題を解決し、ガイド付きコード生成とリファクタリング後のテストにより後者の問題をフォローします。
Mono2Microのリファクタリングアプローチ¶
Mono2Microツールは、AIを活用したアプリケーションモダナイゼーションのアプローチであり、ユーザーはレガシーアプリケーションからどのセグメントをリファクタリングできるかを、以下の観点から評価することができる。
- 意図したビジネスプロセスやドメインがコードの実装にどのように反映されているか。
- アプリケーションのさまざまなコンポーネントが、特定のビジネスユースケースにおいて、どのように連続的かつ因果的に相互作用しているか
- 処理しなければならないコードとオブジェクトの状態の依存関係は何か？
このように、Mono2Microはボトムアップ型のガイド付きリファクタリング・ソリューションであり、開発者のドメイン・ドリブンなサービス・ビューをコード・レベルで実際に起こっていることに基づかせ、ビジネス、予算、時間、リソースの制約に基づいて何がリファクタリング可能であるかをデータ・ドリブンな意思決定でサポートします。AIメカニズムは、ビジネスロジックの観点から見て賢明なパーティションは何か、実装を検討する上で自然な継ぎ目は何かを推奨するためのすべての証拠を提供します。このガイダンスは、開発者のモダナイゼーションの目的と推定される作業量に応じて、一度に集めることも、段階的に集めることもできます。
Mono2Microはまた、パーティションのコードを自動的に生成することで、ユーザーがパーティションを独立したサービスにリファクタリングすることを支援します。このコードには、自動インターフェイス・ラッピング、パラメータ・パスを含む分散オブジェクト管理、モニタリング、例外処理のサポートが含まれており、何が欠けている可能性があり、なぜ欠けているのかを発見するのに役立ちます。
Mono2Micro は、アプリケーションの動的解析と静的解析を組み合わせ、アプリケーションの包括的なビューを提供します。¶
Mono2Microを構築するにあたり、私たちは現場の経験をもとにレガシーアプリケーションについてあらゆることを学びましたが、その中で、実行中のアプリケーションを分析することが非常に重要であることがわかりました。ランタイム情報は、特定のビジネスユースケースにおいて、アプリケーションのコンポーネントがどのように相互作用し、どのような時間的順序で実行されているかを教えてくれ、静的なコード解析だけでは得にくい因果関係を発見することができます（例えば、Java EEサービスの異なるコンポーネントがサービスセッションを処理するためにどのように使用されているか、フレームワークを通じてオブジェクトがどのように共有され、アクセスされているか、など）。ランタイム・トレースは、実行されたテスト・ケースに大きく依存し、テスト・ケースのセットが不完全である可能性があるため、静的解析は、継承や包含関係、実際のパラメータとして渡されるオブジェクト、特定のJava EEフレームワーク固有のアノテーションなど、リファクタリングに関連するコード・レベルの構造やメタデータを理解するためにも適用されます。
Mono2MicroがAIを使って大規模なサービス・パーティションを推奨¶
Mono2Microは、明確に定義されたビジネスユースケースと、適切なテストケースを実行して生成されたクラス間のランタイムトレースを考慮しています。Mono2Microは、教師なしのアプローチでパーティションを作成する。まず、1つ以上のビジネスユースケースの実行によって収集された入力データとして、ランタイムトレースを取り込みます。ランタイムトレースは、2つ以上のクラスとメソッドコールの時間的シーケンスを構成します。次に、これらのトレースを使用して、クラス間の時空間的な関係を抽出します。この関係に基づいて、階層型クラスタリングアルゴリズムを利用して、クラスを任意の数のパーティションに分割します。生成された各パーティションは、アプリケーションの基礎となる1つまたは複数のビジネス機能を表しています。
パーティションはさらに検証され、3つのメトリクスに基づいて評価されます。
- BCP (Business-context purity)は、パーティションごとのビジネスユースケースの平均エントロピーの指標であり、実装されているビジネスユースケースの観点から見たパーティションの機能的なまとまりを表しています。Mono2Microでは、ビジネスコンテキストの純粋性は、関連するビジネスユースケースをほとんど実装していないパーティションに有利であり、したがってドメインとの整合性が高くなる。
- Inter-partition calls (ICP)：2つのパーティション間で発生するランタイムコールの割合を表す。Mono2Microでは、パーティション間コールは、メソッドの数とコールボリュームの両方の観点から、パーティション間の相互作用が最小となるパーティションを特定しようとするもので、これにより、よりクリーンで必要なAPIの数が少ないサービスが実現する。
- 構造的モジュール性（Structural modularity: SM）とは、パーティション内のクラスの構造的なまとまりとパーティション間の結合の観点から、パーティションのモジュール性を数値化したものです。Mono2Microでは、構造的なモジュール性により、より自立した運用が可能なパーティションを特定することができ、独立性が高くなる。
また、Mono2Microでは、アプリケーションを分割するパーティションの最大数をユーザーが指定することができる。この数の推定は、アプリケーションが持つであろうサービスの数に関するユーザーの初期思考によって得ることができる。さらに、このパラメータを変更することで、前述の3つの異なるメトリクスを参照して、どのような結果が得られるかを実験することができます。Mono2Microは、粒状で、機能的にまとまりがあり、疎結合で、説明可能なマイクロサービスを作成するのに効果的であることが証明されています。
Mono2Micro はコードのリファクタリングやトラブルシューティングを支援します。¶
Mono2Microは、サービス変換、オブジェクト・パラメータのラッピング、分散オブジェクト管理、例外処理などをカバーする自動生成コードを提供することで、独立して稼働するパーティションの作成を支援する。この技術は、ほとんどの場合、オリジナルのアプリケーションコードに手を加えることなく、オリジナルのコードベースのセマンティックな同等性を維持します。そのため、ユーザーは、新しいサービス・パーティションとのすべての依存関係が考慮されていることを確認するだけでなく、既存のテストケースを実行して、隠れた依存関係が見落とされていないことを確認します。このように、Mono2Microはユーザーがリファクタリングされたサービスの事実確認を支援し、プロセス、コード、オブジェクトの状態レベルですべての依存関係が説明されていることを保証する。そしてユーザーは、分割されたサービスがどれほど優れているか、またクラウドネイティブなマイクロサービスにするためには何を調整したり書き換えたりする必要があるかを、根拠に基づいて評価することができる。
AI-partitioning¶
Mono2Microの強力な機能の1つに、AIパーティショニングの仕組みがある。アーキテクトや開発者は、モノリスのリファクタリングに取り組みながら、AIパーティショニングの成果を利用することができる。
モノリスのリファクタリングを行う際に、AIパーティショニングの結果を利用することができます。¶
Mono2MicroのUIでは、パーティション間でクラスを移動させてパーティションをカスタマイズしたり、既存のパーティションからクラスを移動させて全く新しいパーティションを作成してクラスを割り当てたりすることができます。パーティションレベルでの変更は、メトリクスに影響を与える可能性があります。BCP、ICP、SM。AIはすべてのメトリクスを同時に考慮するため、ユーザーがあるメトリクスを他のメトリクスよりも優先させたいと思うことは十分にあり得ます。パーティション間でクラスを移動させることで、ユーザーはwhat-ifシナリオを検討し、希望するパーティショニング戦略がこれらのメトリクスの観点からどれほど効果的であるか、また、現状でパーティションのカスタマイズを使用することに意味があるかどうかを確認することができます。
AIが推奨するパーティションのもう一つの興味深い点は、ユーティリティクラスを特定できることです。現在のMono2Microのソリューションではそのようなフラグは立てられていないが、異なるパーティションの多くのクラスから呼び出され、多くの多様なビジネスユースケースで使用されている場合、ユーザーは1つまたは複数のクラスを潜在的なユーティリティクラスとして特定することができる。特定のアプリケーションでは、これらのユーティリティ・クラスをライブラリとしてパッケージ化したり、クラウド・ネイティブ・サービスに置き換えたりすることで、サービスの独立性を高めることができる。
ビジネスユースケースの定義¶
ビジネスユースケースのランタイムトレースは、ユーザーからMono2MicroのAIエンジンに提供される最も重要なデータです。ビジネスユースケースは、ユーザーがアプリケーションをリファクタリングしたいと考えているビジネスドメインの機能やサービスを反映していることが理想的です。これは、「株を買う」「株を売る」といった具体的な機能であっても、「ユーザーのログイン」といった具体的なサービスであってもよい。ユーザーは、自分にとって意味のある機能性の実世界のビューを自由に作ることができなければなりません。細かいレベルでは、そのような機能性を、アプリケーションの独立した実装として考えることができます。ユーザーは、アーキテクトが Mono2Micro で表示されるパーティショニングの証拠を明確に理解できるよう、意味のあるユースケースのラベルを提供する必要がある。
Cardinalでリファクタリング作業を迅速に進める¶
Cardinalは、Mono2Microのソリューションコンポーネントであり、アプリケーションのコードベース、アプリケーションのメタデータ、クラスのパーティションを入力とし、パーティションの初期コードベースをサービスとして生成する。
Cardinalコンポーネントで、ユーザーは以下のことができます。
- パーティション化されたサービスがアプリケーションの残りの部分とどのように相互作用するかという点で、その意味を理解する。
- リファクタリングされたアプリケーションのパフォーマンスの側面
- リファクタリングされたサービスに関連する潜在的なエラーや問題の検出
これらのデータポイントは、サービスの特定の部分をどのように書き換えれば、スケーラブルでより効率的になるかを判断するための貴重な基礎となります。具体的には、Cardinalは、アプリケーションをモノリスのようにパーティションで動作させるための一連のプロトコルを実装しています。その結果、パーティション化されたサービスは、元のモノリスとほぼ意味的に同等のものとなります。
Cardinalはオリジナルのコードベースを変更しません。そのため、ユーザーはMono2Microが生成したリファクタリングをコードレベルで明確に理解し、リファクタリングされたコードをオリジナルのテストケースでテストすることができる。Cardinalは、以下の自動生成機能をユーザーに提供する。
- パーティション間のメソッドコールをAPIに変換するサービスラッピング
- パーティション間のメソッドコールを容易にするために、リモートオブジェクトをプロキシに変換するクライアントサイドラッピング
- アプリケーション・オブジェクトをシリアル化するのではなく、グローバルにアドレス可能なオブジェクト参照を渡し、どのパーティションでもプロキシ経由で使用できるコール・パラメータ解決機能
- すべてのパーティションで単一のオブジェクト・インスタンスの状態を保証する分散オブジェクト管理とガベージ・コレクション
- ポリモーフィズムをサポートするダイナミックなオブジェクトタイプの解決
- トラブルシューティングをサポートする内蔵の例外処理
Cardinalでよく聞かれる質問は、なぜJava remote method invocation (RMI)のようなリモートオブジェクトプロトコルを使わないのかということです。主な理由は以下の通りです。
- Mono2Microは、クライアントとサービスのラッピングをすべてオリジナルのモノリスのコードレベルで行い、ユーザーが理解しやすく、トラブルシューティングがしやすいようにしたいと考えています。このコードレベルのカプセル化は、最終的にサービスを書き換えるための足がかりとなります。
- Cardinalでは、シリアル化を必要とせずに、RMIよりもはるかに透過的な方法でパラメータオブジェクトを処理します。
- CardinalのリモートオブジェクトはPOJOであり、元のクラスと全く同じように見え、動作します。これにより、既存のコードベースに対する変更の影響が最小限に抑えられ、エラー導入のリスクも大幅に減少します。
- Cardinalのプロトコルでは、オブジェクトの参照が呼び出しに束縛される必要がなく、任意の呼び出しのネストや自己参照が可能です。
Cardinalで生成されるクラスのカテゴリ¶
Cardinalで生成されるクラスの種類は以下の通りで、Cardinal summary reportで報告されるほか、Mono2Microの生成コードのコメントでも報告されます。
- サーフェイスクラス。サーフェスクラスとは、パラメータの受け渡し、フィールドの宣言、メソッドの呼び出しなどにより、複数のパーティションからアクセスされるクラスです。サーフェスクラスには、物理クラス、サービスクラス、プロキシクラスの3つの表現があります。
- 物理クラス.物理クラスは、モノリスのオリジナルクラスです。物理クラスはモノリスのオリジナルクラスで、単一のパーティションサービスに存在します。
- サービスクラス.パーティション内の物理クラスのサービスAPIラッパークラスです。パーティション内の物理クラスのサービスAPIラッパークラスで、パーティション外からのサービスコールによる物理クラスのインスタンスへのすべてのリモート呼び出しを容易にします。
- *プロキシクラス*.プロキシクラス. プロキシクラスは、同じパーティション内に存在しないサーフェスクラスの単純な表現です。物理クラスを含むパーティションへのリモート・サービス・コールによるオブジェクト・アクセスや呼び出しを容易にするために使用されます。
- ダミークラス.ダミークラスとは、Mono2Microが観測できる範囲で、パーティション内で使用されていないクラスのことです。これはCardinalが提供するフェイルセーフ機構で、実行時にダミークラスにアクセスした場合、例外が発生する。ダミークラスは、リファクタリングされたパーティションのコンパイルと実行を簡素化するのに役立ちます。各パーティションは、元のモノリスと同じクラスと宣言を持っているように見えます。ダミー・クラスは、テストと検証が完了した後、各パーティションから削除することができます。
カーディナルが生成したコードをリファクタリング作業のベースにする¶
Cardinalはデプロイ可能なマイクロサービスを生成するものではありません。Cardinalはユーザーのリファクタリング作業を加速させます。APIテンプレートを生成するだけではなく、リファクタリングされたパーティションをサービスとして構築・配備し、その結果を検証（モノリスのテストケースを使用）、トラブルシューティング（見落とされた依存関係の検出）、パフォーマンス評価（パーティション間の呼び出しのおしゃべり度）のために実験するための簡単な方法を、非常に素早く提供します。 これらのデータに基づいて、ユーザーはどのパーティションをより優れたマイクロサービスに書き換えることが理にかなっているのか、それにはどのくらいの労力が必要なのか、あるいは異なるビジネス・ドメインの内訳を反映させるために推奨されるパーティションを修正すべきかどうかを計画することができます。Mono2Microが提供するコード分析、パーティションの推奨と調整、評価のための実行という一連のプロセスにより、ユーザーはリファクタリングの取り組みにおいて、ガイド付きでデータに基づいたアプローチを迅速に行うことができます。
まとめと次のステップ¶
Mono2Microは、開発者やアーキテクトがアプリケーションのモダナイゼーションに活用できる、エビデンスに基づいたAIアシスタントです。Mono2Microの目標は、デプロイ可能なマイクロサービスを初日に生成しようとするのではなく、レガシーアプリケーションを安全かつ健全な方法で高速に変換するためのステップバイステップのガイダンスを提供することであり、これは実際には達成できない目標であると考えています。
Mono2Microは、アプリケーションのモダナイゼーションは旅のようなものだと理解していますが、価値はすぐに、そして適切な方法で解き放たれる必要があります。実際にお客様と接してきた経験や、手動でリファクタリングを行ってきた経験から、アプリケーションモダナイゼーションの取り組みから得られる短期的な利益は、ユーザーによって異なることが多く、またレガシーアプリケーションの状態は、ユーザーの即時的なニーズに適していない可能性があることを学んだ。そのため、Mono2Microは開発者やアーキテクトを迅速にサポートします。
- 想定されるデッドコードやアンチパターンを特定することでコードをクリーンアップし、簡単な変換（例えば、特定の継承をコンポジションに変更するなど）で得られる価値を実現することができます。
- ビジネスドメイン指向のマイクロサービスを特定し、リファクタリングに必要なコードレベルの依存関係を発見することができます。
- リファクタリングの労力と、リファクタリングされたパーティションの効率性を評価することができます。
謝辞¶
著者は、Melissa Modejski (VP, Application Platform and Integration)、Ruchir Puri (Dr. Ruchir Puri, IBM Fellow, Chief Scientist, IBM Research)、Nicholas Fuller (Dr. Nicholas Fuller, Director, IBM Research)、および Mono2Micro の開発チーム全員からのサポートに感謝します。また、本記事をIBM Developerに掲載するにあたり、John Meegan氏（Offering Manager）、Michelle Corbin氏（Content Developer）のご協力に感謝いたします。