マイクロサービスの前提条件

マイクロサービスアーキテクチャスタイルの使用について人々と話していると、多くの楽観的な意見を聞きます。開発者は、より小さなユニットでの作業を楽しみ、モノリスよりも優れたモジュール性を期待しています。しかし、すべてのアーキテクチャ上の決定と同様に、トレードオフが存在します。特にマイクロサービスでは、運用に深刻な影響があり、運用担当者は単一の明確に定義されたモノリスではなく、小さなサービスの生態系を処理する必要があります。したがって、特定のベースラインコンピテンシーがない場合は、マイクロサービススタイルを使用することを検討すべきではありません。

迅速なプロビジョニング：数時間以内に新しいサーバーを起動できる必要があります。当然のことながら、これはクラウドコンピューティングに適合しますが、完全なクラウドサービスなしでも実行できます。このような迅速なプロビジョニングを実行するには、多くの自動化が必要になります。最初は完全に自動化する必要はないかもしれませんが、本格的なマイクロサービスを行うには、後でそのようにする必要があります。

基本的な監視：本番環境で連携する多数の疎結合サービスがある場合、テスト環境では検出が困難な方法で問題が発生する可能性があります。結果として、深刻な問題を迅速に検出するための監視体制を整えることが不可欠です。ここでのベースラインは、技術的な問題（エラーのカウント、サービスの可用性など）を検出することですが、（注文の減少を検出するなど）ビジネス上の問題を監視することも価値があります。突然の問題が発生した場合は、迅速にロールバックできるようにする必要があります。したがって...

迅速なアプリケーション展開：管理するサービスが多数ある場合は、テスト環境と本番環境の両方に迅速に展開できる必要があります。通常、これには2時間以内で実行できるデプロイメントパイプラインが含まれます。初期段階では手動での介入も問題ありませんが、すぐに完全に自動化することを目指すでしょう。

これらの機能は、開発者と運用間の緊密な連携という重要な組織的変革、つまりDevOpsカルチャーを意味します。この連携は、プロビジョニングと展開を迅速に行うために必要であり、監視が問題を示したときに迅速に対応できるようにすることも重要です。特に、インシデント管理には、開発チームと運用チームの両方が、当面の解決と根本原因分析の両方に関与し、根本的な問題が解決されるようにする必要があります。

このような設定が整っていれば、少数のマイクロサービスを使用した最初のシステムを開始する準備が整います。このシステムをデプロイして本番環境で使用し、その健全性を維持し、DevOpsの連携がうまく機能するようにするための多くのことを学びましょう。これを実行するための時間を設け、そこから学び、サービス数を増やす前に、より多くの能力を養ってください。

現在これらの機能がない場合は、マイクロサービスシステムを本番環境に導入するまでに準備ができるように、それらの機能を開発する必要があります。実際、これらはモノリシックシステムにも本当に必要な機能です。ソフトウェア組織全体に普遍的に存在するわけではありませんが、優先順位を高くする必要がない場所はほとんどありません。

少数のサービスを超えて進むには、さらに多くのものが必要です。複数のサービスを介してビジネストランザクションを追跡し、継続的デリバリーを完全に採用してプロビジョニングとデプロイメントを自動化する必要があります。製品中心のチームへの移行も開始する必要があります。開発者が複数のリポジトリ、ライブラリ、および言語を簡単に切り替えられるように、開発環境を整理する必要があります。私の連絡先の一部は、より多くのマイクロサービスの実装に取り組む組織を支援できる、有用な成熟度モデルがあるかもしれないと感じています。今後数年間で、そのことについての議論がさらに見られるでしょう。