DevOps は、今日のテクノロジーの最大トレンドの 1 つですが、マイクロサービスアーキテクチャが DevOps の重要なカギを握ります。
マイクロサービスは、DevOps チームを変革させ、アジャイルにし、フットワークを軽快にする秘訣です。
Solutions Review で Tim King 氏が紹介している、「マイクロサービスは、ソフトウェアアプリケーションを開発する方法の特性によって定義することができます。宇宙に存在するブラックホールを識別する方法と似ていて、周囲のオブジェクトの動きによって見えてきます。」という見解はなかなか絶妙な言い方だと思います。
Microsoft では、Sam Guckenheimer 氏が、比喩を用いない的確な表現で説明しています。「マイクロサービスは、別々にデプロイ可能な、Web インタフェースを介して通信する、特定の業務機能を実行する複数のサービスから、分散アプリケーションを構成するアーキテクチャパターンのことだと記述できます。」
簡単に言えば、マイクロサービスは、アプリケーションが特定のコーディング言語に依存しない独立したサービスに分割され、新しいアプリケーションを作成するときは必要に応じて異なるコンテキストで再デプロイできるような、アプリケーションを構築する新しい手法です。
何かの構造物を作成するのにレゴを使って組み立てることと、何もないところから作成することを比較してみてください。レゴを使う場合は、様々なレゴブロックがすでに用意されているので、それらを組み合わせて自由に簡単に好きな構造物を作り上げることができます。何もないところから構造物に必要なたくさんのピースを木材から切ったり削ったりしなければならない手間がかかりません。そして、完成したら、レゴブロックに分解して、それぞれのレゴブロックをまた好きなように組み立てることができます。木でできたおもちゃは目的に合わせて作られており、そのまま固定されます。
マイクロサービスは、レゴにたとえることができ、特化されたブロック、固有の機能を備えた個々のピースから成り立ちます。そして、レゴと同様、拡張性があります。個々のブロックは、通常は API を介して、より大きなものを構築するために組み合わせられます。さらに、マイクロサービスの各コンポーネントは個別に拡張することができます。ファイル転送機能に追加機能が必要になれば、ファイル転送マイクロサービスを単に拡張することができます。
マイクロサービスには、レゴのメタファーが当てはまらない面もあります。ただし、いい意味においてです。レゴの場合、レゴ・タワーから1ピースを外すとタワー全体が崩壊する可能性があります。一般に単一障害点として知られている現象です。マイクロサービスには、レゴの単一障害点のような問題は発生しません。マイクロサービスアーキテクチャでは、1つのサービスがクラッシュしたとしても、ストラクチャ全体に障害が伝播することはありません。マイクロサービスは、相互に連携するためにオープンである一方で、個々のコンポーネントは接続する他のサービスによって変更されることはできません。それぞれが独立して実装およびバージョン管理されているため、1つのサービスの問題がアプリケーションの他の部分をクラッシュさせたり悪影響を及ぼしたりすることはあり得ず、単一障害点の問題は解消されています。
ここで、最初に指摘した DevOps とマイクロサービスとの関係を再考してみましょう。マイクロサービスのレゴ的な部分、柔軟性と拡張性は、アプリケーションの構築が非常に簡単であることを意味します。アプリ開発に対する従来のモノリシックなアプローチよりもはるかに高速です。このマイクロサービスの敏捷性、つまりアジリティは、DevOps の中核となる継続的デリバリーに結びつきます。そして、レゴを超える部分、単一障害点の解消は、アジリティを強化します。
Jeff Edwards is a tech writer and analyst with three years of experience covering Information Security and IT. Jeff has written on all things cybersecurity, from APTs to zero-days, and previously worked as a reporter covering Boston City Hall.
より優れた業務アプリケーションやウェブサイトの開発に役立つ、ニュース、情報、チュートリアルをご案内します。
The specified form no longer exists or is currently unpublished.