写し
これは、コンテナによるアプリケーションのモダナイゼーションです。 このプレゼンテーションでは、コンテナの理想とモノリシックなアプリケーションの現実について説明します。 コンテナの利点は何ですか? コンテナに関するベストプラクティスは何ですか? また、モノリシック・アプリケーションの現実とは何でしょうか? 次に、モノリシック アプリケーションとコンテナのモダナイゼーションについて説明します。 アプリケーションのモダナイゼーションに関する戦略はどのようなものですか? モダナイゼーションのためにアプリケーションをどのようにトリアージしますか? サービスとモノリスをどのように比較し、モノリスをサービスに分解する方法は? そして、まとめをまとめます。
目次
- コンテナの理想とモノリシックな現実 (0:35)
- モノリシックアプリケーションの現実 (2:26)
- Docker コンテナのベストプラクティス (5:53)
- 近代化戦略 (9:48)
- モノリスに対するサービスの利点 (19:49)
- サービスの課題・落とし穴 (22:13)
- モノリシック アプリケーションをサービスに分割するにはどうすればよいでしょうか。 (24:56)
- 概要 (30:21)
- さらに詳しく
コンテナの理想とモノリシックな現実 (0:35)
コンテナ化について話すとき、開発者とデプロイの両方にとってさまざまな利点があります。 基本的に、コンテナはプロセスレベルの分離を提供します。 つまり、各コンテナは、同じシステム上の他のコンテナから分離して実行できます。 これには、リソースを 1 つのシステムにパックし、複数のものを互いに干渉せずに実行する方法など、多くの利点があります。 コンテナには、アプリケーションに必要なすべての依存関係が含まれており、アプリケーションをホストから切り離します。 つまり、ホストマシンで何が実行されているか、またはホストマシンでどのように実行されているかがコンテナに影響を与えることを心配する必要はありません。 だから、「私のマシンで動作する」というのはもうありません。 コンテナを使用すると、アプリケーションの移動と配布が容易になります。 コンテナイメージは、複数の異なるハードウェアで同じように実行し、実際に同じように動作させることができます。 つまり、そのコンテナイメージをピックアップして必要に応じて移動し、そのコンテナの実行方法に一貫性を持たせることができます。 次に、すべての主要なDevOpsツールとクラウドベンダーによってサポートされているOpen Container Initiative標準があります。 つまり、OCI標準に準拠したコンテナイメージを構築すると、どこでも実行でき、主要なDevOpsツールを自信を持って使用できます。 そして最後に、開発者は、前述のすべての理由から、コンテナを使用してアプリケーションを構築する経験が向上し、個々の開発者またはクロス開発者チームがアプリケーションをコーディングするときに、アプリケーションの操作がはるかに簡単になります。
モノリシックアプリケーションの現実 (2:26)
では、多くのお客様が対処しなければならないモノリシックなアプリケーションの現実と比較してみましょう。 そこで、アプリケーションを見ていきます。 このアプリケーションは、 2010 年に最初に本番環境にデプロイされ、時間の経過とともに機能が追加されました。 このアプリケーションは、ビジネスにとってミッションクリティカルであると考えられています。 つまり、アプリケーションはどこにも行かないものです。 それは私たちが対処しなければならないことです。 そこで、Javaアプリケーションから始めます。 したがって、ここでは最下位のレイヤーとしてJava仮想マシンがあります。 次に、Java EEサービスを備えたアプリケーションサーバーがあります。 その上に階層化されているのが、これらのJava EEサービスを利用するSpringフレームワークです。 さらに、Log4Jのようなフレームワーク、検索用のLucene、必要なJavaライブラリ、その他多くのサポートファイルがあります。 そして最後に、検索、在庫、販売、CRM、レポート、およびサポート機能が時間の経過とともに組み込まれてきたeコマースJavaアプリケーションがあります。 これが私たちがサポートしようとしているアプリケーションです。 それはモノリスとして動いているのです。 私たちは今、それを全体的なシステムとして見ています。 データベースに戻るか、バックエンドシステムへのMQ呼び出しか、SOAPを介した外部Webサービス呼び出しなど、10年以上前のアプリケーションであるため、依存しているシステムは他にもさまざまであることがわかります。 これが、私たちが取り組んでいるアプリケーションの全体です。 したがって、このアプリケーションは 12する必要があります。5GB のサイズは、それに関連するすべてのコンポーネントを考慮して GB。 つまり、これは非常に大きなモノリシックなアプリケーションであり、多くの人がこのようなものを持っているのが現実です。
では、先ほど見たようなモノリシックなアプリケーションを持つことで、ビジネスにどのような影響があるのでしょうか。 1つ目は、デプロイメントの頻度です。 このような大規模なアプリケーションがある場合、デプロイするのは困難です。 つまり、スケジュールは四半期ごとから 6 か月以上になる可能性があり、これは、すべてが一度に行わなければならないため、それに合わせて調整しようとしているものが多いためです。 つまり、変更のリードタイムが長くなります。 そのため、小さな変更でも四半期ごと、またはそれ以上に行うことで、実際に本番環境に出すことができます。 次はスケーリングです。 したがって、このモノリシックなアプリケーションをスケーリングする場合は、全体をクローンしてスケーリングする必要があります。 あなたが利用できる唯一の選択肢は、水平タイプのスケーリングです。 次に、信頼性の低下です。 アプリケーション内のどこかに問題が発生すると、全体に影響を及ぼす可能性があります。 そのため、メモリリークが発生し、どこかに小さな関数が1つあると、すべてが1つのプロセスであるため、アプリケーション全体がダウンする可能性があります。 そして、より複雑な開発者エクスペリエンスでは、アプリケーションの一部を開発するだけでは不十分です。 それはオール・オア・ナッシングであり、それはあなたが実際にそれを使ってどんな種類の開発も行うことができるようにすべてをセットアップして実行しなければならないことを意味します。 そして、これらすべてがコストの上昇につながります。 このモノリシックなアプリケーションでは、チームの規模が大きくなり、運用コストやハードウェアが増え、あらゆるもののコストが高くなります。
Docker コンテナのベストプラクティス (5:53)
それでは、コンテナのベストプラクティスについて話しましょう。 ですから、コンテナについて話すとき、私たちが望むのは、各コンテナが1つのことを行い、それをうまく行うことです。 つまり、コンテナは特定の側面に焦点を当て、自己完結型になる必要があるということです。 そして、そのコンテナはそれを一つのことを行うことができます。 それ以上のことをする必要はありません。 次に、開発者ツールを本番環境に出荷しないでください。 開発に必要な開発者ツールがある場合は、それらが運用イメージに含まれないようにしてください。 可能な限り、画像のサイズを小さくします。 本番環境に追加のものを含める意味はありません。 せいぜい、そこにあるのは単に余分なバイト数です。 最悪の場合、セキュリティ上の問題やその他の問題を引き起こす可能性があります。 アプリケーションの実行に必要なもののみを含めます。 したがって、繰り返しになりますが、そのイメージにアプリケーションの実行に必要のないものがある場合は、削除する必要があります。 そして、最終的にはシンプルから始めて、必要に応じてさらに複雑になります。 そして、これはSDLC全体でコンテナを操作する方法に実際に当てはまります。 現時点で必要ない場合、追加のピースを用意する必要はありません。 もちろん、後で追加することもできます。
では、なぜこれらのベストプラクティスについて話しているのでしょうか? さて、戻ってアプリケーションを見てみましょう。 これが私たちのアプリケーションです。 そして、問題は、これをコンテナ化できるかということです。 今話していたことを考えると、これをコンテナに入れることはできますか? では、このアプリケーションをコンテナに入れるとしたら、これは私たちのベストプラクティスとどのように一致するでしょうか? 各コンテナは1つのことを行い、それをうまく行う必要があります。 いや、これは全然そんなことじゃない。 開発者ツールを本番環境に出荷しないでください。 そして、実際には、そこに開発者ツールがあるかどうかはわかりません。 私たちは、調べて、見つけ出さなければならないでしょう。 可能な限り、画像のサイズを小さくします。 いいえ、私たちもそれに同調していません。 アプリケーションの実行に必要なもののみを含めます。 いいえ、私たちはそうしていません。 そして、シンプルから始めて、必要に応じてより複雑になります。 私たちは確かにそうしていません。 したがって、このモノリスをコンテナ化するとしたら、コンテナのベストプラクティスのほとんどを満たしていません。 では、問題は、それをすべきかということです。 そして、私が与える答えは、はい、このモノリシックアプリケーションをコンテナ化できるということです。 全部コンテナに入れることができます。
では、ベストプラクティスのいずれにも準拠していないのであれば、なぜそうするのかという疑問が生じます。 コンテナ化の利点に戻りましょう。 コンテナはプロセスレベルの分離を提供するため、より多くのリソースをパックできます。 はい、たとえそれがそのコンテナの中にあるモノリスであっても、これはまだ真実です。 コンテナーには、アプリケーションをホストから切り離すために必要なすべての依存関係が含まれます。 「私のマシンで動作する」ことはもうありません。 はい、このモノリス全体がコンテナ内にある場合、それはマシン、パス、そのようなものを持っている他のJVMバージョンから分離されていることを意味します。 ですから、そのメリットはまだあります。 コンテナを使用すると、アプリケーションの移動と配布が容易になります。 はい、モノリスがその特定のコンテナ内にある場合は、その画像を拾い上げて移動させ、実行すれば、同じように実行されます。 コンテナはOCI標準を使用しているため、どこにでもデプロイできます。 はい、これは、そのコンテナ内にあるモノリスであっても、まだ真実です。 また、開発者はコンテナを使用してアプリケーションを構築するエクスペリエンスが向上します。 はい、これはモノリスであっても真実です。 したがって、ベストプラクティスに準拠していなくても、モノリスをコンテナ化することで、実際にはそれ以外のメリットを提供できます。
近代化戦略 (9:48)
それでは、モダナイゼーション戦略について話しましょう。 このモノリシックなアプリケーションがあります。 容器の中に入れることができます。 コンテナの中に入れることは、それ自体が本当に近代化しているわけではありません。 もしかしたら、コンテナ化が役立つ他の戦略があるかもしれません。 ですから、ここで最初にお話しするのは、この会話をしているときに頭の片隅に置いておくために、コンウェイの法則です。 コンウェイの法則では、システムを設計する組織は、組織のコミュニケーション構造のコピーを構造とする設計を作成すると述べています。 つまり、特定のアプリケーションに取り組んでいる部門が異なる場合、それらの各部門がその特定のアプリケーションに表示されるということです。 また、アプリケーションのモダナイゼーションを検討しているときは、組織を複製しようとする過ちと、アプリケーションが満たす必要のあるドメインを複製するという過ちを繰り返さないようにするために、この点を念頭に置く必要があります。
さて、アプリケーションのモダナイゼーション戦略です。 これは、ガートナー社によって5つのRとして最初に普及しました。 今日、さまざまなバージョンがありますので、見てみてください。 しかし、これからお話しする5つのRはRe-hostingです。これは最小限の変更で、アプリケーションのリフト&シフトです。 リファクタリング – アプリケーションにいくつかの非常に軽い変更を加え、おそらく技術的な負債を返済します。 リアーキテクト – アプリケーションの大幅な変更またはコンポーネントへの分割。 再構築 – 書き直し、アプリケーションをゼロから再設計し、最後に Replace – アプリケーションを廃止するか、他のシステムに置き換えます。 このプレゼンテーションでは、オプションとしてリホスト、リファクタリング、リアーキテクト、リビルドに焦点を当てます。
さて、最初に考える必要があるのはトリアージです。 アプリケーションをモダナイズするための考慮事項は何ですか? 通常、モダナイゼーションの取り組みを行っているとき、焦点を当てているアプリケーションはありません。 モダナイゼーションが必要なアプリケーションは、数十または数百ある可能性があります。 そして、どのアプリケーションがどの方法で、どの優先順位でモダナイズされるかについて、何らかの思考プロセスが必要です。 では、その考慮事項にはどのようなものがあるのでしょうか? 1つ目は、ビジネスの優先事項です。 ビジネス上の優先事項は何か、そしてそれらはこの特定のアプリケーションのモダナイゼーションにどのように整合するのか? このアプリケーションはビジネスの優先事項にとって重要ですか? もしそうなら、モダナイゼーションはそれにどのように適用されるのでしょうか? それとも、このアプリケーションはビジネスの優先事項にとって重要ではないのでしょうか。 おそらく、それは運用上の優先事項にとってより重要ですか? それは優先順位付けにどのように影響しますか? 次に、アプリケーション知識です。 したがって、この例のアプリケーションは 10 年以上前のものです。 アプリケーションがどのように機能するか、またはどのようにデプロイされるかを本当に理解している人はいますか? そして、これらの質問のいずれかに対する答えが「いいえ」の場合、一歩下がって、さまざまなタイプのモダナイゼーション戦略に必要な労力のレベルについて考えることを余儀なくされます。 次は、アプリケーション技術スタックです。 繰り返しになりますが、このアプリケーションが古い場合、現在のアプリケーション技術標準に準拠していますか? そして、答えが「いいえ」の場合、それはこのアプリケーションのモダナイゼーション戦略にとって何を意味しますか? 次は、アプリケーションの寿命です。 アプリケーションは現在の形式でまだ必要ですか? アプリケーションが十分に古く、状況が十分に変更されている場合は、このアプリケーションの戦略と優先順位付けに影響を与える可能性があります。 組織の能力 – 開発チーム、テストチーム、運用チームは、このアプリケーションに取り組むためにどのくらいの能力を持っているか? 誰もがやるべき日常の仕事を持っています。 この特定のアプリケーションのモダナイゼーションを必要な時間枠で行うのに十分な容量が実際にあるのでしょうか? そして最後に、コストとリスクです。 現在のモデルを現状のまま実行する場合のコストとリスクと、アプリケーションをモダナイズするコストとリスクはどの程度ですか? どのようなモダナイゼーション戦略をとっているかに関わらず、コストがかかり、ある程度のリスクも伴います。 そして、それらを測定して電流と比較することは、トリアージの重要な部分です。 したがって、トリアージを行い、このアプリケーションのモダナイゼーションの作業レベルと優先事項を決定したら、さまざまな戦略とその適用方法を確認できます。
そこで、最初に見ていくのはリホストです。 これは、通常、現在実行されているハードウェアがサポート対象外になる場合や、実際のインフラストラクチャを変更する必要がある場合に必要となる、アプリケーションの非常に基本的なリフト アンド シフトです。 したがって、モノリスを保持しているDockerコンテナを使用すると、これは非常に簡単になります。 そのコンテナイメージをピックアップできます。 この場合、そこの小さな雲に預けて、そのクラウド環境で実行することができます。 オンプレミスでの実行とまったく同じように動作します。 データベース、MQ サービス、および Web サービスへの接続は引き続き必要です。 ただし、アプリケーション自体は以前とまったく同じように動作します。 そのため、コンテナ化により、このリフト&シフトが容易になります。
さて、次はリファクタリングです。 次に、アプリケーション自体にいくつかの簡単な変更を加えます。 したがって、この場合、技術的な負債を減らすことを検討し、おそらくいくつかのバージョンを更新し、それが理にかなっている場合はいくつかの小さな変更を加えます。 では、ここで何をしているのかを見てみましょう。 左側にある最初のことは、以前に存在していたSOAP呼び出しをRESTに変更していることです。 そのため、必要な呼び出しに使用されているAPIをモダナイズします。 次に行うことは、アプリケーションに組み込まれたレポート作成機能を確認し、それを削除して、バックエンド・データベースにアクセスできるサードパーティのレポート作成ツールに持ち込むことです。 このサードパーティのレポートツールは、独自のコンテナにも配置できることに注意してください。 したがって、この方法では、アプリケーションの実行に重要でない無関係な機能がアプリケーションに存在しないようにします。
さて、次の戦略はリアーキテクトです。 これは、アプリケーションの大幅な変更またはコンポーネントへの分割です。 では、なぜアプリケーションをコンポーネントまたはサービスに分割する必要があるのでしょうか。 サービスには、私たちを助ける多くの機能があります。 1 つ目は、各サービスが独立してデプロイ可能であることです。 これには、チーム、タイムテーブル、テクノロジーなど、これらすべての要素に関して、すぐに多くのメリットがあります。 したがって、個々の独立したピースを持つことは、開発とデプロイの両方に多くの波及効果をもたらすでしょう。 これらのサービスは、他のサービスと疎結合されています。 ここでのゆるさは非常に重要です。 これについては、ここですぐに詳しく説明します。 したがって、通常、サービスはビジネス機能または機能によって定義されます。 例えば、アカウントや顧客など、定義したいものがあり、その定義方法はサービスによって定義されるかもしれませんし、複数のサービスによって定義されるかもしれません。 したがって、各サービスには単一の責任モデルがあります。 そのため、特定のコンポーネントを担当し、それに関連付けられたビジネスロジックとデータを処理します。 先ほど述べたように、実際には、単一の責任のための独自のビジネスロジックとデータ管理が含まれています。 そして、彼らはある種のAPIまたはブローカーを介して相互に通信します。
では、サービスの適切なスコープとは何でしょうか? ご存知のように、サービスは大きいですか? 小さいですか? それは何であるべきですか? そうですね、私たちが話すサービスにはさまざまな規模や範囲があります。 最初にお話ししたのは、マクロサービスまたはモノリスです。 すべてのビジネスサービスは、緊密に結合されてデプロイされます。 つまり、これはモノリスの単一プロセスバージョンです。 次はマイクロサービスです。 マイクロサービスは、通常、サービスについて話すときに広く話題になります。 これらはビジネスコンポーネントをカバーしています。 これらは独立してデプロイされ、疎結合され、APIを介して通信します。 他のスケールもあります。 ミニサービスがあり、これはビジネスニーズやプロセスに対応するマイクロサービスのグループです。 そして、ナノスケールは単一のビジネス機能であり、非常に細かい粒度のスコープです。 ページ上のインベントリウィジェットは、サービスとして定義された特定のアイテムのインベントリの可用性を表示するだけのナノサービスであると考えることができます。 大丈夫です。 では、適切なスコープとは何でしょうか? サービスに適切なスコープは 1 つではありません。 適切なスコープとは、真の価値を提供するのに十分な大きさであり、それ以上ではないスコープです。 つまり、これはアプリケーションごと、作成するサービスごとに異なるということです。 ですから、すべてがマイクロサービスになるとか、すべてがナノサービスになるとか、単純に言うことはできません。 自分が何をしようとしているのか、そのサービスからどのような価値を得ているのか、そしてそのサービスを維持するために費やさなければならない努力に対して、その価値が意味をなしているのかを本当に見なければなりません。
モノリスに対するサービスの利点 (19:49)
では、モノリスに対するサービスの利点は何でしょうか? さて、これらのいくつかについてはすでに話しましたが、それらをさかのぼってみましょう。 つまり、独立した開発チームは小規模で、各チームはモノリス全体に取り組むのではなく、特定のサービスに取り組むことができるため、これらのチームは互いに独立して作業でき、それほど大きくなる必要はありません。 次に、独立したサービスのリリーススケジュールです。 これは、これらの独立したサービスが独自のスケジュールでリリースできるため、変更の市場投入までの時間が短縮されることを意味します。 サービスを個別に拡張する – そのため、製品サービスではなく顧客サービスをスケールアップする必要がある場合でも、今すぐアプリケーション全体をスケーリングする必要はありません。 これは、全体的なリソースコストが削減されることを意味します。 次は、スコープが小さい開発者エクスペリエンスです。 繰り返しになりますが、アプリケーション全体を自分のマシンで実行する必要はないので、たとえば、ラップトップを使用してアプリケーションの一部を実行し、作業を完了するために必要な部分だけを実行できます。 ブルー/グリーンのデプロイメントのようなものもできました。なぜなら、今は個別のサービスがあるので、実際にそこに出て、独立したサービスの異なるバージョンをデプロイし、モノリスレベルでそれを試みなければならないのに対して、どのような反応があるかを確認することができるからです。 再利用性サービス – ここでの典型的な例は、税額計算サービスまたは在庫サービスであり、複数の場所で同じサービスが必要な場合があり、そのサービスを再利用できます。 技術にとらわれないサービス – これらのサービスが互いに独立しているため、理にかなっている場合は、個々のサービスに対して個別の技術スタックを検討し始めることができます。 そして、アプリケーションの信頼性が向上し、障害モードの制御が向上します。 そのため、1つの小さなサービスでメモリリークなどの問題が発生した場合でも、アプリケーション全体がダウンすることを心配する必要はありません。 アプリケーションの一部が機能していない障害モードがありますが、残りの部分はまだ機能しているため、失敗したサービスの修復が行われている間に一部のビジネスを完了できます。
サービスの課題・落とし穴 (22:13)
さて、以上がサービスの利点です。 サービスの課題と落とし穴にはどのようなものがありますか? ですから、サービスを見るのはポジティブなことばかりではないのは確かです。 まず、複雑さです。 これは大きな問題です。 アプリケーションを分割する部分が多いほど、その一部として処理する必要がある可動部分が多くなります。 つまり、技術的な複雑さ、プロセスの複雑さ、そして組織的な複雑さがあり、これはモデルをサービスベースのアーキテクチャに変更することの一部です。 これは、あなたがこのタイプの動きをしているときに考慮しなければならない非常に、非常に大きなことです。 次はレイテンシーです。 ネットワークホップは実在します。 そのため、同じマシンで複数のサービスが実行されている場合は、それらの間で API 呼び出しが発生しています。 これらの API 呼び出しには、わずか数マイクロ秒しかかかりません。 ああ、それは大したことではないと思うでしょう。 しかし、1つのリクエストを満たすために何十回、あるいは何百回もサービスコールが行われている場合、その時間は合計されます。 ですから、サービスの数が増えるにつれて、そのことを考える必要があります。 配布モノリス。 したがって、疎結合ではなく密結合されたサービスが作成されている場合、つまり、個々のサービスが周囲に他のすべてのサービスを持っていないと実行できない場合、実際には独立したサービスが作成されていません。 作成したのは分散モノリスであり、これは以前と同じ問題ですが、現在は1つの特定のアプリケーションではなく、複数のマシンと複数のグループに広がっています。 きめ細かなサービス。なぜすべてをサービスにしないのですか? サービスのすべてのページのすべてのフィールドにすべてのアイコンを作成しないのはなぜですか? さて、これらのサービスからビジネス価値を得ていますか? そのレベルでサービスを受けることは理にかなっていますか? それとも、単に複雑さを増しているだけなのでしょうか? そして、テクノロジーが目標です。 私が知っているビジネスパーソンは、投資家に出て、Istioが私たちの目標だとか、このオーケストレーション技術が私たちの目標だとか、そういうことを言う人はいません。 ビジネスはビジネスの結果に関心があります。 そのため、テクノロジーをビジネスの成果ではなく、何をしようとしているかの目標として考えると、それは課題になる可能性があります。
モノリシック アプリケーションをサービスに分割するにはどうすればよいでしょうか。 (24:56)
では、次に、モノリシック アプリケーションをサービスに分割する方法は次のとおりです。 つまり、モノリシックアプリケーションがあります。 次に、それをサービスに分割したいと思います。 どうすればいいのでしょうか? そこで、広く使用されているパターンの一つは、ストラングラー・フィグ・パターンと呼ばれ、その名前を持つことで、なぜその名前が付けられたのか、その背景を少し掘り下げる必要があります。 これは、このパターンを思いついたマーティン・ファウラーからのものです。 彼は、ある休暇で、巨大なストラングラー・イチジクに出くわし、木の上部の枝に種をまき、徐々に根系を土まで構築していく話をしていました。 彼らが土に着くと、彼らは木の周りで成長し始め、成長するにつれて木を殺します。 ですから、マーティンはこれが重要なシステムを書き直す方法を説明するための比喩だと感じました。 したがって、アプリケーションの書き換えの代替ルートは、古いシステムの端の周りに新しいシステムを徐々に作成し、古いシステムが絞め殺されるまでゆっくりと成長させることです。
さて、まず最初に、モノリスからサービスを特定して作成する必要があります。 ですから、これらのサービスがどうなるのかを理解する必要があります。 したがって、アプリケーション内の論理コンポーネントを特定する必要があります。 それはどのようなものになるのか:顧客、製品、在庫、販売、それはさまざまな異なるものになる可能性があります。 そこでは、これらのコンポーネント間の依存関係を理解する必要があります。 最初は、これらのサービス間にはあらゆる種類の接続があります。 私たちは、そのモノリスの中でそれがどのようなものかを理解する必要があります。 そして、モノリスのコンポーネント間の機能の重複を見つけて削除する必要があります。 それを行い、APIにより近いものを手に入れたら、それらのコンポーネントのグループをサービスに作成し、マクロからナノまで、それらのサービスの粒度を決定できます。 次に、それらのサービスをリモートで呼び出すためのAPIまたはブローカーを作成します。
そこで、eコマースアプリケーションを取り上げ、いくつかのコンポーネントに分割しました。 つまり、注文、検索、顧客、支払い、在庫、サポートケースがあります。 したがって、これらは私たちが並べたコンポーネントであり、これらの間の呼び出しを見つけ出し、重複した機能を削除しました。 そして、私たちはこれらのピースを分解し始める準備ができていると感じています。 つまり、コンテナ内ではアプリケーションは次のようになります。 最初に行うことは、このアプリケーションの前にプロキシを追加することです。 プロキシを使用すると、エンドユーザーエクスペリエンスに影響を与えることなく、これらの個々のコンポーネントを分割できます。 したがって、他のコンポーネントから最も孤立していると感じるコンポーネントを取ることができます。 したがって、この場合、支払いを受け取り、それを独自のコンテナに分割します。 そのため、現在、支払いは2か所で行われています。 元のアプリケーションで実行し、別のコンテナで実行し、プロキシを介して実行しているものの間にAPIがあります。 これを行い、新しいコンテナの決済サービスが適切に機能し、トラフィックを処理していることを確認したら、モデルから決済機能またはコンポーネントを削除することができます。 そして、これにより、これらの個々のサービスをStrangler Fig Patternでゆっくりと分割する能力が与えられています。 そして最終的には、それぞれの異なるサービスがそれぞれのコンテナで実行されるようになりました。 また、ここでは、前の例のサードパーティのレポートコンテナも表示しています。
さて、リアーキテクトの部分、つまり大幅な変更やアプリケーションの分割について説明しました。 次は「再構築」です。 そこで、アプリケーションを完全に書き直し、再設計します。 ですから、今では、これまでやろうとしていたこと、つまり既存のものを新しいテクノロジーに近代化することで、これまでやろうとしていたことに対して、大規模な変更を加えることができます。
ですから、今見てみると、突然、機能に多くの変更が加えられています。 Java以外のさまざまな言語が含まれているだけではありません。注文と支払いシステムにはGolangがあります。 既存のレビューやディスカッション、ソーシャルメディアの統合など、これまでアプリケーションに存在しなかったものをPHPコンポーネントとして追加する予定です。 サードパーティのCRM検索およびレポート機能を追加する予定です。 カスタマーサクセスのためにAI/MLチャットボットを使用し、在庫管理にはRustサービスを使用します。 これで、サービスが再び利用可能になったことがわかりますが、以前にアプリケーションを再設計したときとは大きく異なる外観になっています。
さて、リホスト、リファクタリング、リアーキテクト、リビルドについて説明しましたが、Replaceは単にアプリケーションを削除して他のものから始めるため、Replaceは取り上げていません。
概要 (30:21)
それでは、ここで締めくくりましょう。 そこには多くのモノリシックアプリケーションがあります。 近代化は今後何年にもわたって続くでしょう。 近代化への正しい道は一つではありません。 組織と各アプリケーションにとって最適なパスは、トリアージと優先順位付けのプロセスを通じて決定する必要があります。 コンテナは、そのジャーニーのどこにいても、モダナイゼーションプロセスを支援します。 コンテナは、モノリスをコンテナ化しているかマイクロサービスをコンテナ化しているかに関係なく、価値を提供します。 ありがとうございました。
さらに詳しく
- ドッカーは初めてですか? 始めましょう。
- 注目のガイドでDocker製品を深く掘り下げます。
- Docker Newsletter を購読してください。
- Docker デスクトップの最新リリースを入手します。
- 質問がありますか? Docker コミュニティがお手伝いします。
