web-dev-qa-db-ja.com

自分でシステムを開発する場合、マイクロサービスを使用する必要がありますか?

私は仕事で新しいプロジェクトを始めています。おそらく1人か2人の開発者が既存のアプリケーションまたは単純なスクリプトをメインプロジェクトに統合する必要がありますが、プロジェクトのほぼ単一の開発者になるでしょう。プロジェクトは、小規模のバルクデータとストリーミングデータの取り込み/処理、およびイベント駆動型とオンデマンドの両方のコード実行を処理する必要があります。フレームワークの一部はCPUに大きく依存し、一部はI/Oに大きく依存する可能性があります。ほとんどのデータは単一のマシンに存在する必要がありますが、クラスターを作成してVMを接続することで、利用可能なコンピューティング能力を向上させることができます。このコアフレームワークが提供するサービスに依存する1つ以上の小さなWebアプリケーションが存在する可能性があります。主な言語は、ほぼすべてのPythonになります。

私の質問は、開発の大部分を自分で行うことを考えると、マイクロサービスアプローチをこのような取り組みに取り入れるべきか、モノリシックアプリケーションに固執すべきかどうかです。私の考えは、マイクロサービス(Namekoを使用)は、異なる実行モデル(データパイプライン、イベント起動、オンデマンド、Webアプリケーションなど)を持つフレームワークの要素を自然に分離し、ワークロードを分散する明確な方法と複数のプロセスにわたる通信。私の懸念は、おそらく管理するためのKubernetesクラスター(私はDockerに精通していますが、それでもKubernetesにはかなり新しい)と、システムの実行を容易にするためだけに必要な複数のサービス(rabbitmq、redisなど)になることです。フレームワークで必要となるすべての必要な機能を実際に実装するためのコードの小さなチャンクが多数含まれている可能性があります。

開発者が1人にすぎないプロジェクトの場合でも、マイクロサービスはこのような複雑なシステムの開発と保守を簡素化しますか?代わりに使用することを検討する必要があるメソッド/システム/フレームワークはありますか、またはこの方法でシステムを設計することに伴うオーバーヘッドを削減するためですか?

30
scnerd

マイクロサービスは、ソフトウェアを分散システムに変えるため、一般的に望ましくありません。分散システムでは、すべてがはるかに困難になります。ただし、サービス指向アーキテクチャにはいくつかの重要な利点があります。

  • さまざまなチームが独自にさまざまなサービスを開発してデプロイできます
  • さまざまなサービスを個別にスケーリングできます

あなたが唯一の開発者になるので、独立してサービスを開発する柔軟性は必要ありません。

ただし、一部の部分がCPUに依存している場合があります。そのため、アプリケーションの他の部分から独立してそれらをスケーリングすることが望ましい場合があります。その場合でも、プロジェクト全体をマイクロサービスアーキテクチャに変換する必要があるという意味ではありません。 CPUを集中的に使用する部分を独自のサービスに移動するだけで、残りの部分を便利なモノリスに収めることができます。システムがどのラインに沿って分割されるべきかを判断することは困難ですが、一般に、「境界付きコンテキスト」というDDDの考え方は良いガイドラインです。

モノリスは悪くないことに注意してください。モノリスは、大規模で面倒でメンテナンス不可能なプロジェクトとは異なります。システムを異なるマイクロサービスに分割できる場合、モノリス内でシステムを異なるコンポーネントに分割することもできます。これらのコンポーネント間の分離は、サービス指向アーキテクチャーでより明確になり、より明確に適用されます。これは、適切に設計されたシステムの場合、後でコンポーネントをサービスに変換するのがかなり簡単になることも意味します。そのため、今すぐ決定する必要はありません。モノリスが不適切であることが判明した場合は、マイクロサービスに移行できます。

Martin Fowlerの Microservice Premium (2015)の概念も考慮してください。マイクロサービスは、システムの基本的な複雑さに加えて、独自のかなりの複雑さをもたらします。生産性の低下という観点から、この「プレミアム」を支払う必要があります。つまり、単純なプロジェクトの場合、マイクロサービスは生産性を低下させます。より複雑なプロジェクトでのこの変更:モノリシックソリューションは操作がますます困難になる可能性がありますが、マイクロサービスアーキテクチャははるかに適切にスケーリングされ、ほぼ一定の労力が必要です。マイクロサービスの追加の初期作業がソフトウェアシステムに与えられる価値があるかどうかを知る必要があります。この質問をしているので、答えはおそらく「いいえ」です。ファウラーは続けます:

したがって、私の主要なガイドラインは、モノリスとして管理するには複雑すぎるシステムがない限り、マイクロサービスを考慮しないことです。ソフトウェアシステムの大部分は、単一のモノリシックアプリケーションとして構築する必要があります。そのモノリス内の優れたモジュール性に注意を払いますが、それを個別のサービスに分離しようとしないでください。

49
amon