しばらくの間、マイクロサービス フレームワークの高速でシンプルなソリューションを探していました。私はすべての Lightbend 製品と scala にまったく慣れていませんが、非常に興味深いので試してみることにしました。
いくつかの質問:
1) 新しいフレームワーク Lagom が必要な理由がわかりません。
Play が (マイクロサービスとして機能する) 同じソリューションを既に提供できる場合、なぜ別のフレームワークが必要なのですか?
2) play を使用して、「Hello World」プロジェクトを非常に高速に作成することができました。また、展開も非常に簡単で簡単でした (dist 経由)。
すべてを 1 つの ZIP にマージし、スクリプトで実行できるという事実が気に入っています。私が理解していることから、LagomではConductRを使用する必要があります。
私の現在のニーズでは、大きなオーバーヘッドのように見えます。遊びのようなものを展開する簡単な理由はありますか?
皆さん、ありがとうございました
Lagom は Play の上に構築されています。Play は汎用 (非同期) Web フレームワークを意図していますが、Lagom のより具体的な目標は、アプリをマイクロサービスとしてデプロイすることに焦点を当てたツールや意見を追加することです。
Lagom が提供する、マイクロサービス スタイルのアーキテクチャを実現するのに役立ついくつかの例 (Play はそうではありません):-
持続性
たとえば、Play が現在提供している永続化サポートの上にCQRSベースの永続化用の API が追加されています。これは (ご存じない場合)、クエリとコマンドを分離することでマイクロサービス アーキテクチャを実現するのに役立つパターンです。
コンテナ オーケストレーション
25 の異なるマイクロサービスを持つ Play アプリケーションがあるとします。これは、比較的小規模な企業アプリケーションであっても控えめな数字です。これらすべての JVM のデプロイ/オーケストレーションをどのように管理しますか? さて、コンテナは大流行です。これらすべてのコンテナをどのように管理していますか? ConductR は、その作業の負担を軽減するツールです。Lagom は、ConductR を Lagom プロジェクトで簡単に使用できるようにするための統合ツールを提供します。これは、Play だけでは得られないものです。
私はまだPlayでこれを達成することができました
Play プロジェクトで同じことを実現するために使用できる SBT モジュールがたくさんありますが、必要なツールを選択し、利用可能な多くのモジュールのどれがプロジェクトに適しているかを判断し、構成して、必要に応じてそれらを配線します (これは Lagom の目標の 1 つです)。これらの決定と構成タスクをユーザーから切り離して、アプリケーション ロジックの作成に集中できるようにすることです。
私のアプリケーションが小さく、おそらく 5 つのサービスしかない場合、Lagom (またはその他のマイクロサービス フレームワーク) は本当に必要ないとかなり説得力を持って主張できます。ただし、アプリケーションが成長する可能性が高い場合、Play だけを使用すると、長期的にはより多くの時間がかかります。
マイクロサービスを設計する際には明らかに他にも多くの考慮事項がありますが、Play と Lagom の要点がわかります。