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


30

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

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

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


10
マイクロサービスが提供する利点が必要な場合にマイクロサービスを使用し、それらの利点はコストを上回ります。個人的には、自分で教えるか、より大きなアプリケーションの長期的な展望がない限り、一人が書いた個々のアプリケーションでマイクロサービスが必要になる理由はわかりません。
ロバートハーベイ

回答:


49

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

  • さまざまなサービスをさまざまなチームによって独立して開発および展開できます
  • さまざまなサービスを個別にスケーリングできます

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

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

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

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

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


31
TL; DRバージョン:実際に抱えている問題を解決する場合にのみ複雑さを追加します。
jpmc26

1
後でマイクロサービスアーキテクチャに簡単に移行できるように設計します。たとえば、懸念の分離と大きな泥の塊、そして今では維持しやすく、後で別のサービスに部分を移動するのが簡単になります。他のサービスに電話をかけたりメッセージを送信したりすることなく、マイクロサービスに着想を得た職務/ドメインの分割を引き続き行うことができます。
ps2goat

1
ファウラーの分散オブジェクトの第一法則:禁止
K.

1
3番目の利点がありますが、OPには同様に役に立たないものがあります:とにかく分散システムを構築する必要があり、既に分散システムに適したツールを構築している、または構築する予定がある場合、マイクロサービスはそのツールとより簡単に統合されますまた、多くの面でよりきめ細かな制御を可能にします。これにより、トラブルシューティング、プロファイリング、統合テスト、トレースなどを簡素化できます。しかし、それは明らかに、既存のマイクロサービスアーキテクチャをサポートするツールに依存します。このサポートエコシステムがなければ、マイクロサービスは複雑さを増すだけです。
ケビン

2
うん、いい答えだ。マイクロサービスが実際複雑さを追加することを人々は忘れているようです。したがって、より複雑なものを削除しない限り、それは価値がありません。そして、ほとんどすべての場合、1人の開発者がMSAを行うことで十分なメリットを得られません。
エンダーランド
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.