ポイント: マイクロサービスとナノサービスは、複雑なコードを小さな管理可能なサービスに分割することでアプリケーション開発を向上させるために設計されたアーキテクチャフレームワークです。ナノサービスは迅速なデプロイメントのために軽量で焦点を絞った機能を提供し、マイクロサービスは分散システムのための堅牢なソリューションを提供します。
- ナノサービスは、迅速なコードリリースと柔軟なサービス統合を可能にします。
- マイクロサービスは、アジャイル開発と大規模なチームにより適しています。
これまでの数年間で、ソフトウェア開発は従来のモノリシックアーキテクチャから移行し、その複雑さに対処するために緊密に結合された相互接続されたコードを採用しました。これにより、マイクロサービスが採用され、複数の小さなサービスを通じて分散コンピューティングを可能にする効率的なクラウドネイティブアプローチが生まれました。
マイクロサービスが主流になった今、過去数年でナノサービスが登場し、主にマイクロサービスの複雑さを克服するために設計された別のパターンとして進化しました。基本的に、ナノサービスはサービスをさらに分割して追加の効率をもたらします。
この記事では、アプリケーションを構築するために小さなコンポーネントを開発することが好ましいアプローチであることを説明しますので、私は：
- マイクロサービスとナノサービスの両方を説明します
- 利点と課題を探ります
- ニーズに合った適切なフレームワークを決定するための例とベストプラクティスを共有します
開発プラクティスの改善
基本的な設計のため、モノリシックアプリケーションにはいくつかの深刻な課題があります：
- 扱いが難しいです。
- 多くのディスクスペースを使用します。
- スケールが難しいです。
モノリスアプリケーションが成熟すると、最新のテクノロジーを導入したり、強化されたフレームワークを採用したりすることは多くの複雑さを伴います。これらの障害は、コードレベルの統合に限定されません。テストとデプロイメントもさらに難しくなります。
さらに、アプリケーション全体を再構築するためのプロジェクトは、しばしば時間がかかり、高リスクです。
(アプリの モダナイゼーションの複雑さについて学ぶ および コードリファクタリングについて。)
モノリスよりマイクロサービス
マイクロサービスは以下のために構築されました：
- モノリシックアプローチの問題を克服するため。
- 分散型クラウドベースアプリケーションを開発するための効果的なソリューションを提供するため。
マイクロサービスはアプリケーションを複数の緩く結合されたサービスの集合体に分割します。通常、マイクロサービスは：
- 孤立して開発およびテストされます
- 処理するプロセスによって整理されます
- 独立してデプロイされます。
これらのサービスのそれぞれは独自のプロセスを持ち、リソースを共有せずに独立して機能するように設計されています。これにより、競合を回避します。
ナノサービス
典型的なイラストは、モノリスの中央のマルチティアフレームワークがマイクロサービスアーキテクチャの分散サービスとどのように異なるかを示します。
(マイクロサービスアーキテクチャとモノリシックアーキテクチャを比較する。)
マイクロサービスは通常、クラウドベースのコンテナ内に含まれ、他のサービスとウェブAPIを通じて通信します。このようなAPIは、ユーザーインターフェース、他のサービスの呼び出し、データの受け入れなどの受信イベントに応答するメッセージキューとして機能します。
分散モデルのため、マイクロサービスは他のサービスに影響を与えることなく開発および保守されます。これは本質的に、DevOpsモデルを助けます：
(マイクロサービスとAPIの違いを確認するが、共に機能する。
マイクロサービスの利点
マイクロサービスフレームワークのコンポーネントベースの設計は、以下のような複数の利点を提供します：
- マイクロサービスは維持、スケール、共有が容易です
- コンテナとよく連携します。
- 開発とテストが迅速で、デプロイメントサイクルを短縮し、DevOpsプラクティスに最適なフィット感を提供します。
- サービスの孤立した性質は、安全なデプロイメントとエラーの迅速な解決を提供します。
- マイクロサービスは、同様のサービスを構築するための再利用性を許可することにより、より大きな柔軟性を提供します。
- 使用する特定のテクノロジーに制限がないため、より大きな開発生産性（そしておそらく革新）を可能にします。
- 相互運用性が本質的にあるため、マイクロサービスはオープンソースまたはクローズドソースプラットフォームの両方で使用できます。
ナノサービスとは何ですか？
2つのフレームワークの基本的な違いは、ナノサービスがマイクロサービスの小さい兄弟と見なされていることです。ナノサービスは、特定のAPIエンドポイント（コマンド）を通じて出力される単一の機能を実行するように設計されています。
ナノサービスはお互いに完全に発見可能です。それぞれが他のサービスとリンクして追加のアクションを実行し、機能を拡張することができます。
設計上、ナノサービスは：
- 自己完結型
- 再利用可能
- マイクロサービスよりも複雑さが少ない
- 各サービスに対して独自の機能ファイルでサポートされています。
ナノサービスは、特に以下の理由からマイクロサービスよりも効率的と見なされています：
- 初期設定の容易さ
- サービス間のレイテンシの低下；各ナノサービスの機能コードは、個々のサービスをホストするための専用コンテナやサーバーを使用せずにオンデマンドで実行できます。
ナノサービスの実世界のユースケース
以下のイラストは、BBCウェブサイトが数千のナノサービスを使用して動的なウェブページをレンダリングする興味深いユースケースを強調しています。各サービスは、ウェブページの特定のコンポーネントにフィードする役割を果たします。例えば：
- 見出しを生成する
- 天気データを取得する
- 試合のスコアを更新する
- その他。
BBCのサイトの高レベルのナノサービスアーキテクチャは、複数の小さなサービスが協力してウェブページのコンテンツを提供する方法を概説しています：
ナノサービスの利点
ナノサービスは、特定の機能をカプセル化する容易さのために特に有益です。これにより、以下のような利点を持つアプリケーションフレームワークが実現します：
- マイクロサービスよりも集中化され、軽量です
- 複数のチームが特定のサービスまたは複数のサービスで作業できます
- 各サービスが独自のセキュリティプロトコルを持つことができます
- 独立して開発、テスト、およびデプロイできます
- コードリリースをより迅速かつ頻繁に行うことを促進します
- 機能を拡張するために異なるサービスをリンクする柔軟性が追加されます
現在の課題
マイクロサービスとナノサービスは、モノリスに比べて大きな改善をもたらしますが、課題がないわけではありません。
特定のユースケースでは、より小さなサービスを組み合わせてアプリケーションを開発することは、さまざまな方法で複雑さを増すことを示唆しています。これには以下が含まれます：
- 重複サービスの作成と維持に費やす労力が増える
- 非常に効率的なインフラストラクチャが必要で、構築が複雑で維持が高コストになる
- サポートしているサービスの数が多いため、リソース消費が増加する
- サービスレベルの依存関係が厳密になると、複雑なエラートラッキングが生じる可能性があります
最初の印象では、ナノサービス内の分離が増すことは魅力的に見えるかもしれません。しかし、ナノサービスの広範な使用は、一連の問題と複雑さを引き起こす可能性があります。
さらに、適度に複雑なアプリケーションにとって、ナノサービスフレームワークの採用は実際にリソースを過剰利用し、手動作業を増やすかもしれません。これはDevOpsプラクティスが最小化したいものです。
(他の 一般的なマイクロサービスの課題について準備する。)
マイクロサービスまたはナノサービスの選択
マイクロサービスとナノサービスは、従来のアーキテクチャに対して効率をもたらすために進化してきました。複雑なアプリケーションコードを複数の小さなサービスに分散させることで、クラウドネイティブなセットアップ内で実現されます。
これを念頭に置いて、最適なフレームワークを選択する際の重要な考慮事項は、最終的には2つの重要な要素に帰着します：
- 開発者の経験
- アプリケーションの機能要件
マイクロサービスを使用するタイミング
ナノサービスと比較して、マイクロサービスは確立されたよく知られた設計アプローチであり、幅広いテクノロジーで動作できます。
業界の主要プレーヤーであるNetflixとAWSのいくつかの成功したユースケースがあり、すでにマイクロサービスアーキテクチャを使用して最先端のサービスを提供しています。つまり、マイクロサービスには学習または成熟したマイクロサービス戦略をサポートするリソースとグループが豊富にあります。
マイクロサービスは通常、以下のような場合に適しています：
- アジャイル開発プロセス
- 開発チームが機能的または地理的に分散している場合
- 時間をかけて機能を拡張する最小限の実用的製品（MVP）を作成する場合
これを念頭に置いて、マイクロサービスがすべてのアプリケーションタイプに適しているわけではないことも同様に重要です。特定のユースケースでは、徹底的なデューデリジェンスと効率的な計画がなければ、サービスの無秩序な拡張がフレームワークをモノリシックアーキテクチャのように大きくて扱いにくくする可能性があることが示されています。
(すべての計画から保守までのマイクロサービスのベストプラクティスをフォローする。
ナノサービスはまだ新しく、その可能性を完全に発揮する成功したユースケースはまだ発見されていません。ナノサービスは小さく、柔軟で、より孤立しており、機能的に焦点を合わせていますが、以下のような未知数が残っています：
- 新興技術との互換性
- 指数関数的なスケーリング
その結果、マイクロサービスをどのように使用するか、またはいつ使用するかについては対立する意見があります。
まず、ナノサービスの自然な性質が、アプリケーションで広く使用されるときに攻撃ベクトルから保護されているかどうかという疑問を投げかけます。
一部の人はまた、ナノサービスをアンチパターンと見なしています。これは、その断片化された機能のために、メンテナンスのオーバーヘッドがフレームワークの利点の価値を超えることが知られています。
ナノサービスはまだ発展段階にあるため、保守的で大規模な組織は通常、今のところそれを避けます。主にフレームワークのスケーラビリティに対する不確実なサポートが理由です。それを採用する人にとっては、フレームワークを使用する際のベストプラクティスは：
システムを複雑にする場合はナノサービスを避ける。
意図的に設計する
ナノサービスとマイクロサービスを選択するか、またはその逆かは、ユースケースによって常に異なります。ただし、最終的な目標は同じです。自動化を支援し、回復力があり、スケーラブルで安全なアプリケーションを開発するために適切なアーキテクチャを採用することです。
関連リーディング
これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも表すものではありません。