マイクロサービスに移行すると、実行時の問題がどのように発生しますか？

次のコメンテーターは書いています：

マイクロサービスは、組織の機能障害をコンパイル時の問題から実行時の問題に移行します。

このコメンテーターは、問題について次のように説明しています。

機能はバグではありません。実行時の問題=>製品の問題=>責任者への機能障害に関するより強力で迅速なフィードバック

今、私はそれを取得しmicroservicesあなたは：

• スループットのレイテンシーを潜在的に増加させます-これは生産および実行時の懸念です。
• 解析の実行時エラーが発生する可能性があるコード内の「ネットワークインターフェイス」の数を増やします。
• 潜在的に青緑の展開を行うことができます。これらは、インターフェイスの不一致によって保持される可能性があります（ネットワークインターフェイスを参照）。ただし、青緑の展開が機能する場合は、実行時の懸念が大きくなります。

私の質問は、マイクロサービスに移行すると実行時の問題が発生するということです。

私は問題があります。マイクロサービスを使用しましょう！現在、13の分散問題があります。

システムをカプセル化された、まとまりのある、分離されたコンポーネントに分割することは良い考えです。さまざまな問題に個別に取り組むことができます。しかし、モノリシックな展開でそれを完璧に行うことができます（Fowler：Microservice Premiumを参照）。結局のところ、これはOOPが何十年も教えてきたものです！コンポーネントをマイクロサービスに変えることにした場合、アーキテクチャ上の利点は得られません。テクノロジーの選択に関して柔軟性が得られ、場合によっては（必ずしもそうではありませんが）スケーラビリティが得られます。ただし、（a）システムの分散された性質、および（b）コンポーネント間の通信に起因する頭痛の種は保証されます。マイクロサービスを選択するということは、他の問題があり、これらの問題にも関わらず、マイクロサービスを喜んで使用できることを意味します。

コンポーネントにきれいに分割されたモノリスを設計できない場合、マイクロサービスシステムを設計することもできません。モノリシックコードベースでは、痛みはかなり明白です。理想的には、コードがひどく壊れている場合、コードは単にコンパイルされません。しかし、マイクロサービスでは、各サービスは個別に開発され、場合によっては異なる言語でも開発されます。コンポーネントの相互作用における問題は、コンポーネントを統合するまで明らかになりません。その時点で、アーキテクチャ全体を修正するには遅すぎます。

バグの一番の原因はインターフェイスの不一致です。パラメータの欠落などの明らかな間違いや、エラーコードの確認を忘れたり、メソッドを呼び出す前に前提条件の確認を忘れるなどの微妙な例があります。静的型付けは、コードが実行される前に、IDEおよびコンパイラでこのような問題をできるだけ早く検出します。動的システムにはこのような贅沢はありません。その欠陥のあるコードが実行されるまで、それは爆発しません。

マイクロサービスへの影響は恐ろしいものです。マイクロサービスは本質的に動的です。正式なサービス記述言語に移行しない限り、インターフェイスの使用方法が正しいことを確認することはできません。テスト、テスト、テストする必要があります！しかし、テストは高価であり、通常は網羅的ではないため、実稼働中に問題が依然として存在する可能性が残ります。その問題はいつ明らかになりますか？実稼働環境で実行中にその障害のあるパスが取られた場合のみ。製品の問題がフィードバックを高速化するという考えは、陽気に データ損失の可能性に面白がっていない限り、危険なほど間違っています。

最初のツイートは私のものだったので、私はそれを拡張します。

モノリシックアプリケーションで作業している100人の開発者がいるとします。あまりにも多くの人が互いに効果的にコミュニケーションをとれないため、会社は彼らを小さなチームに分割し、チーム間で良好なコミュニケーションパターンを作成するために一生懸命働く必要があります。組織が「機能不全」である場合、チームはおそらく互いに話し合っておらず、より大きな目標に合わせられておらず、優先順位などに同意していません。その結果、何かを出荷するには永遠に時間がかかります。これは、ソフトウェアが生産される前に機能障害が明らかであるという意味での「コンパイル時の問題」です。このプロジェクトは、おそらく死の行進であるか、出荷されません（「コンパイル」）。

多くの人々がマイクロサービスに惹かれており、彼らに動いているのは、固有の技術的/建築的利益のためではなく、組織の機能不全を無視できるからだと思います。100人の開発者を揃えようとする代わりに、彼らはサイロで働く小さなチームを持ち、それぞれが自分の小さなマイクロサービスに焦点を合わせることを望んでいます。あなたがそのような機能不全の組織にいる場合、これは非常に魅力的です：それはあなたが好きではない人を避けるために、あなたが通信しないようにあなたにはるかに大きな許可を与えます。

残念ながら、ソフトウェアが実稼働環境で実行されると、良好なコミュニケーションが同様に重要になるため、「実行時の問題」になります。組織の問題-チームとチームの調整とコミュニケーション-は、「実行時」に現れます。

私のツイートのポイントは、もしあなたが持っているものが人々の問題なら、新しいアーキテクチャは役に立たないだろうということでした。問題の影響を遅らせるだけです。多くの人々にとってマイクロサービスの魅力は、これらの人々の問題を魔法のように解決するという希望だと思います。

私の質問は、マイクロサービスに移行すると実行時の問題が発生するということです。

それはそれらのツイートが言っていることではありません！彼らはマイクロサービスへの移行について何も言わず、問題を引き起こすことについても何も言わない。彼らは問題を変えることについて何かを言うだけです。

そして、彼らの主張、つまりあなたの組織が機能不全であるという文脈上の制限を課しています。

したがって、最初のツイートが基本的に言っているのは、2つのことです。

• 「現在、マイクロサービスのない複雑なシステムをエンジニアリングできない組織では、魔法のようにマイクロサービスを備えた複雑なシステムをエンジニアリングすることはできません」
• 「コンパイル時、つまり開発中に表示されるようになったことが原因で発生する問題は、実行時、つまり実稼働中に表示されます」（技術的には、テスト中にも表示される可能性がありますが、おそらく標準以下のテスト体制を持っている機能不全の組織に対して）

第二のつぶやきは、顧客がそれらを参照してくださいどこの顧客が文句を言うとき、それは時にビルドブレークとは異なる場所で聞かれる傾向があるので、問題はのみの生産に現れるということは、つまりは、すなわち、機能ではなく、バグであることを述べています組織の機能不全について何かをすることができる場所（例えば、高レベルの管理）。通常、組織の機能不全は高レベルの管理の失敗であるため、不満のある顧客はその不満の最終的な責任者にひどく反省しますが、高レベルの管理の失敗によって引き起こされるコード品質の低さは、通常、 、しかし、過失ではなく、それについて何かをすることができません。

そのため、最初のツイートでは、マイクロサービスは、不適切な管理に起因する問題を、開発者だけが見るコンパイル時から、顧客が目にするランタイムに移すと述べています。2番目のツイートは、それが良いことだと言っています。なぜなら、問題はそれらの責任者を傷つけるからです。

コンパイル時の問題ではなく、実行時の問題が発生します。

モノリシックアプリはコンパイルが難しく、高価です。しかし、コンパイルすると、型システムがそれらをキャッチできるため、コンポーネント間に極端に愚かな非互換性がないことを合理的に確認できます。microservivesのシステムで同じエラーが発生するのは、2つの特定のコンポーネントが実際に特定の方法で相互作用するまで です。

モノリシックシステムとマイクロサービスの両方で、サブシステム間のインターフェイスを定義する必要があります。インターフェイスは、適切に設計、文書化され、可能な限り安定している必要があります。これは、OOPと同じです。

組織がこれを実行できない場合、マイクロサービスも問題を解決しません。マイクロサービスには、パブリックWebインターフェイスがあります。そのため、インターフェイスの設計により多くの労力を費やす必要があります。

インターフェイスが適切に設計されていない場合、2種類のランタイムの問題が発生します。

1. インターフェイスが正しく使用されていない場合、コンパイル時ではなく実行時にエラーが発生します。
2. Webインターフェースの呼び出しは非常に遅いため、パフォーマンスの問題が発生する可能性があります。

実行時の問題を生成することは、組織の問題を責任者に伝える正しい方法ではないと思います。