モノリシックアプリケーションをマイクロサービスとESBアプローチで統合しますか？
私はESBについて理論的な知識しか持っていません。
ユースケース：-
- さまざまな形式で複数のソースから注文を受け取ることができるアプリケーションのようなeコマースがあります。
- 申請書が提出されたら、いくつかのシステムにメールを送信する必要があります
- アプリケーションが送信されたら、1つの出力ファイルをサードパーティシステムに送信する必要があります。現在はXMLのみですが、今後はフォーマットをサポートする必要があるかもしれません
- 同様に、分析とレポートの準備を行う必要があります。
ESBとマイクロサービスの両方が理論的にここに収まると思います。どちらも、単一のモノリシックアプリケーションではなく、アプリケーションを疎結合にしてスケーラブルにします。アプリをマイクロサービスに分解するのではなく、既製のESB製品（有料またはオープンソース）を選択する際に考慮すべき基準/属性は何ですか？
私の理解:- ESBは、アプリケーションをより疎結合にし、1つのコンポーネント/アプリケーションが単にメッセージをチャネル（Javaオブジェクトにすぎない）に配置するため、ここにより適しています。他のコンポーネントがリッスンするJavaベースのESBアプリ）。これで、ルーター/トランスフォーマー/アダプター/エンドポイントなどの他のコンポーネントが登場し、さらなるアクションが実行されます。ここで送信コンポーネントは、単一チャネルアドレスになる宛先アドレスを知る必要があるだけです。
マイクロサービスの場合も同様ですが、ここでは特定の操作ごとにURLを知っておく必要があります。
しかし、今は1日ですほとんどの人がESBよりもマイクロサービスを好むのを観察しました。 ESBには独自の学習曲線/ DSL /有料製品があるのが理由だと思いますが、マイクロサービスは、サービスがより小さな保守可能な安らかなコンポーネントに分割されているだけです。したがって、学習曲線も有料製品もありません。
私の観察では、どちらの方法でもコーディングを行う必要があると思います。
すべてを自分でコーディングする場合、開発給与にコストがかかり、追加したいすべての新しいものをコーディングする時間があります
既成のESBは、優れた構成可能性とドラッグアンドドロップインターフェイスを約束するため、すべてを簡単に接続して、このコストを回避できます。
ただし、実際には、ドラッグアンドドロップインターフェイスの機能を超えるために接続するものはそれほど複雑である必要はなく、特別な関数のコーディングに強制的に戻らなければならないことがわかりました。
すぐに、その製品のみを扱うESBプログラマーのチームを雇うことになり、ESBのセットアップが非常に複雑になり、誰もそれを理解できなくなります。基本的に、ベンダーロックインを使用して1つのプログラミング言語を別のより高価な言語に交換しただけです。
ただし、マイクロサービスとHTTPマイクロサービスを混同しないでください。手でコーディングしたマイクロサービスをあらゆる種類のゲートウェイの背後に隠すことができます。顧客にとってhttpが問題である場合は、ファイルを電子メールで送信してもらいませんか？またはFTPで転送するか、メッセージキューを使用してイベントベースにするなどします。
私はもう1つ（物議を醸す）観察を追加します。企業が大きくなるにつれて、これらのプロセスの一部を自動化することの重要性は低くなります。管理スタッフを雇って半手動で作業を行うと、自動化されたインターフェースでは競合できないレベルの柔軟性と変更への迅速な対応が追加されます。
常にファイル名を間違えるその1人の顧客？ 5年間の技術計画があるためにAPI開発をスケジュールできない大企業ですか？ APIを公開していないサードパーティのソフトウェアはありますか？
これらの問題のいくつかが発生したら、管理チームをビジー状態に保つのに十分な作業があり、開発チームがコア製品に対してより良いことを行うことができます。