ビデオ： skillmatter.com/skillscasts/5235-keynote-an-integrated-services-approach
長さ：1時間、サイトはビデオを表示する前に登録（メール）が必要です。 このサイトには興味深いビデオがたくさんあります。
Udi DahanはNServiceBusの著者であり、非常に才能のあるスピーカーおよび教師です。 私は数年前から彼のパフォーマンスを追い続けてきました。ウディはいつも情報に基づいて興味深い方法でそれを聞いたり聞いたりします。
プレゼンテーションは、マイクロサービスに特化した会議の2日目に開かれ、Udiは楽しく、現在人気のあるマイクロサービスのトピックをargument笑し、論理的および物理的な実装を監視するよう提案されました。 個人的には、「マイクロサービスの作成/展開方法」（戦術のような）ではなく、「なぜ？」そして「なぜこのアプローチの方が良いのか」という瞬間に非常に興味がありました。
このテキストは概要であり、素材を理解して覚えるために一般的に書かれています。 私は「チュクチライター」というよりも「チュクチリーダー」なので、特に韻を踏むつもりはありません。 私は大企業（数え方によっては200-12,000-90,000人）の小さな開発マネージャーとして働いており、参加者と観客がいるいくつかのプロジェクトに参加しています。 最近、組織的および政治的なタスクはその複雑さにおいて顕著であり、「コードを書く」ことは休暇として認識されています。 これは私が「人生について不平を言った」ので、今度はあらすじに戻ります。
」
ビデオはほぼ1時間続きます。 ビデオとサウンドは非常に良いです。 スクリーンショットを撮ったため、スライドが見つかりませんでした。 英語は軽くてわかりやすく、最も難しい単語は「まとまりのある」です。したがって、見ていくことを強くお勧めします。チーム全体で共通の理解と用語を使用することもできます。
マイクロサービスは多くの問題を解決しません-問題の誤った声明、弱いプロセス、従業員の悪い習慣：
- 問題の誤った説明-お客様は、「自分が何を望んでいるかわからない」または「解決策を提供します（このコラムを入手してください）」のいずれかが間違っている可能性があります。
- プロセス-マイクロサービスは、展開に関してモトリスよりも複雑であり、DevOpまたは継続的インテグレーション/展開に問題がある場合、すぐに出てきます。
- 悪い習慣-悪いコードは改善されません。
そして、規律と意識（成熟）だけが私たちを助けます、アーメン。
また、製品のアーキテクチャを組織構造に適合させる法則もあります。
その後、ウディは魅力的な40年の法律を少し歩いて......
さらにもっと-ファッショナブルな概念は古いものよりも事実上優れているとして提示されますが、これは根本的に間違っています。 そして一般的に-誰もがその表現のいずれかでカップリングに苦労し、実際にそれを主要なアーキテクチャ原則に引き上げます：強い依存=モノリス=悪い、弱い依存=マイクロサービス=良い！
Udiは再びカップリングを検討することを提案します。
左側-これは「常に」を記述する方法です-1つのプロセス、クラスC1はクラスC2のメソッドを直接呼び出し、パラメーターを直接渡します。
右側-C1とC2を別のプロセスに配置しました（もちろん、クラスをコンポーネントとしてスタイル設定する必要がありますが、これは論理的には何も変更しません）。 直接呼び出しの間、RPCまたはXML + SOAPまたはJSON + RESTを使用します。 コンポーネントが「論理的に独立」したと言うことは可能ですか？ いや ロジックは「概念的に」変更されましたか？ いや
それからUdiは、自分を最も賢く考え、重要なタスクであるコンポーネント間の明らかな依存関係との戦いを創造的に解決するイニシアチブプログラマを恐れる必要があると言います。 実際、データはデータベース内に「隠され」、「IDのみ」が送信されます。 特にスマートで高度なものは、「非常にスケーラブルであり、まったくSQLではない」「サービス」でDBベースを隠します。 そして、彼らは誇らしげに言っています-ここに2つの疎結合サービスがあります！
しかし、すべてがさらに悪化しました。ソースコード依存関係のレベルで明確に監視され、文書化されたものは、現在では「隠され」、さまざまなプロトコル、言語、テクノロジーの多数のレイヤーによって隠されています。 そして、これはほんの始まりです！
さらに悪いことに、サービスはさまざまなコマンドを記述し、データベース内の回線は「他の誰か」ではなくなります-現在は独立しています。 しかし、「スマート」なプログラマーもここでgiveめず、フィールドの回路の一部を隠します-JSONは文字列ですか？ はい！ そして、ここにあなたのための「拡張性」があります！ そして、ここにはメタデータとビジネスルールがあります-それが必要ですか？ まあ、それはクールでファッショナブルですか？ うん!!!
ここで、「新しいパラメーターxをFoo（a、b、c、d、x）に追加」と「新しいフィールド」を比較して、改善された新しい機能の結果を見てみましょう。
そしてある時点で、「論理的に接続されるべき」ものがあり、これと戦う必要がないことを理解しています。 たとえば、原子内の結合を解くと、ビジネスロジックで多くのエネルギー、破壊的、同じことが得られます。 Udiは、「粘着性」（粘着性）の概念を使用することを提案しています。
そして、それは以前のように簡単になりますが、システム内にはいくつかの原子があり（それらを壊す必要はありません！）、それらは何らかの形でつながっています。
さらに、「HTML / JS / CSSの専門家チームがあります-彼らは私たちのためにすべてを行います、そして私たちは複雑なサーバーパーツについて話します」とき、Udiは「サービス」（アトム、マイクロサービス）の一部であり、従来のアプローチにも注目します適切なアプローチ。 そして、そのUIは、当然のことながら、マイクロビューにも分割する必要があります。 そして、「製品」に価格と名前と写真などの両方が含まれる「伝統的な」アプローチ -これは非常に単純化されたアプローチであり、ビジネスにも現実にも関係ありません。
そして、技術と展開の要件の両方の点で、（マイクロ）サービスが異なる可能性があるという事実について少し説明します。
さらに、Udiはどういうわけか「現実の」生活とプロジェクト管理のプロセスでマイクロサービスの場所に移動しました。そこでは、製品は異なるプラットフォームで実行され、（通常）異なるチームによって作成されます。
そして、すべてが非常にゆっくりと自然に起こりますが、ある時点で、概念的には同じブロックが異なるプロジェクトで繰り返され、それらはより大きなサービスまたはコンポーネントと考えることもできます。
そして、すべてがうまくいくように見えますが、よく見てみると、技術スタックが非常に異なっていることがわかります-どこで.NetとObjective-C。 そして、どういうわけか、1つのマイクロサービス（uS1）内に多くのテクノロジーを見るのは既に奇妙で、「Objective-Cに書き込むチームがあり、T-SQLに書き込むチームがある」などの質問があります。 はい、ここではコンウェイの法則に直面しています-組織はその構造の下でプロジェクトを曲げようとしています。 機能横断型のチームを提供することもできますが、これはコンウェイの法則のプリズムからも認識されます。
Udiはさらに、プログラマーはさまざまなテクノロジーで作業しなければならないことを説明しています。 その後、私たちは、いわば、組織構造内にとどまります...
...ここで私はビデオを止めて一致させようとしました;私の人生でこのようなものを見ましたか？ はい、いいえ。 まず、日中に.Net-CSS-JavaScript-Java-Objective-Cを切り替えることができるプログラマーはあまりいません。 おそらく、誰でも「トーク」に切り替えることができますが、「複雑なコードをデバッグする」に切り替えることができます-いいえ、私はしていません。 しかし、おそらく、日中に、そしてそのようなことを想像するのは難しいです。それは仕事ではなく、完全な緊急事態です。 「1四半期に1回」の切り替えを検討する場合は、より現実的ですが、さまざまなテクノロジーで意味のある新しいことを書くことができる人もいます。 また、中間チームは四半期ごとに人々を再教育する必要があります。平均的なプログラマーは、ライブラリの機能やユーティリティの構成は言うまでもなく、自分のコードさえもすぐに忘れてしまいます。
第二に、現時点では通常、コードを並行して記述する必要があり、テクノロジー言語ごとに別々のチームを入力します。Udiが語る開発者はプログラマではなく、ビジネスアナリストまたは製品（サービス）の所有者です。そこでは、コンウェイの法則の枠内にとどまります...
そして、あなたは自問します-そのような「マイクロサービス」と呼ぶのは正しいですか？ 特に、それがまったくミクロではないことがわかったとき...そして、彼らは別の場所に展開されています-つまり、彼らは異なるサービスのようです。 しかし、「展開から」アプローチは主なアプローチではありません。たとえば、モバイルアプリケーションに詰め込みたいほぼすべてのものが1つのパッケージにパッケージ化されます。 つまり、これがこのデバイスの特異性であるという理由だけで、1つのパッケージに多くの「サービス」を組み合わせます。 まあ良い-これらは物理的なコンポーネントです。
レポートの最後の部分は、本質的に、私たちがこれらすべての年のために使用してきたすべての仮定と習慣を理解するために時々見直すことができることを訴える試みです-それらは以前と同様に機能しますか？ または何か改善できますか？