配信およびデプロイメント ツールチェーン: 依然として最弱リンク公理の影響を受ける

最近では、DevOps をサポートするツールチェーンについて誰かが言及しないということはまずありません。 誰もが（そう、私たちも）API を持っており、それらはすべて（他の）API エコノミーによって実現されています。 Wikipedia によると、DevOps ツールチェーンとは、「 DevOpsプラクティスを使用する組織によって調整され、ソフトウェア開発ライフサイクル全体にわたってapplicationsの配信、開発、管理を支援するツールのセットまたは組み合わせ」です。

さて、それは主にアプリに焦点を当てていますが、ソフトウェアが一般的にその寿命のかなりの部分（少なくともそうであることを願います）を費やす制作側もあります。 これにも同じ定義が当てはまりますが、その焦点は (私の観点からすると)「DevOps プラクティスを使用する組織によって調整される、アプリのライフサイクル全体にわたるネットワークとアプリ サービスのプロビジョニング、構成、管理」にあるという注意点があります。 従来の DevOps のコンテキストでは、この焦点はサイクルの「リリース」フェーズを拡張し、ソフトウェアのプロビジョニングと本番環境への展開を含む「リリース関連のアクティビティ」をカバーします。 これには、対象ユーザーに安全でセキュアなapplication配信を可能にするために必要なネットワークおよびアプリ サービスが必ず含まれます (または含まれる必要があります)。

問題は、継続的なデプロイメント (ちなみに、これは運用側の話です) という理想の夢を実現するために必要なすべてのツールを備えたベンダーやオープンソース プロジェクトは 1 つもないということです。 実際、アプリ開発側で使用されるツールの一部は、制作側でも使用されています。 2 つの世界の間でのクロスオーバーがますます増えていますが、これはアプリ以外に共通点がほとんどない、伝統的に非常に定着した 2 つの組織間の正常化を示しているため、一般的に「DevOps」にとって良い兆候です。

したがって、Puppet または Chef を VMware および Cisco と組み合わせて使用し、ネットワークおよびアプリ サービスのフルスタックを自動化して、アプリのセキュリティ、ID、スケールのニーズをサポートできます。 そのために必要な適切なテンプレートとスクリプトを作成し、それらが正しいことを確認しました。おそらく、Postman とそのスクリプト機能を使用して、ラボ内の仮想インフラストラクチャに対してテストします。 アプリ開発者がすでに Git を使用しており、ガイダンスを提供したり、場合によっては 1 つか 2 つのトレーニング セッションを開催したりできるため、構成アーティファクトのリポジトリとしてGitが適切な選択であると判断しました。 さらに進んで、プロセスをオーケストレーションし、個々のサービスのセルフサービスを提供するアプリの構築（またはOpenStack実装の立ち上げ）を開始することもできます。 本質的には、デプロイメント ツールチェーンを定義しています。

そして、ここで「最弱リンク公理」が醜い顔をのぞかせ始めるのです。 鎖は最も弱い部分と同じだけの力を持つ、という前提はご存じでしょう。 ここで「強力」が強調されているのは、これを「信頼性」や「安全性」や「拡張性」などの他の特性に置き換えても、この公理が真実のままであるためです。 これが重要なのは、継続的なデプロイメントをサポートするツールチェーンの定義を開始すると、そのチェーン内の各「リンク」が障害点となり、セキュリティ、スケール、可用性が損なわれる可能性があるためです。

計画、検証、監視が DevOps ツールチェーンの重要なリンクであるのと同様に、NetOps ツールチェーンでも同様に重要です。 これは、運用環境でアプリとインフラストラクチャ (ネットワークとアプリ サービス) が最も頻繁に交差する監視にとって特に重要です。 監視（可視性）により、障害発生時にビジネストランザクションから個々のリクエストやレスポンスまですべてを包括的に把握できるようになります。

ネットワークとアプリ サービスの構成は特定のapplicationに固有である可能性があるため (多くの場合、固有です)、構成によってツールチェーンが結合される必要があります。 

パッケージ化とリリースのメカニズムは同様のツールを活用する場合もありますが、それらは別々の問題であり、ニーズの点で大きな相違が見られることがよくあります。 ネットワーク サービスとアプリケーション サービスは共有インフラストラクチャ上に展開される可能性があるため、単一システム アプローチを前提とするツールは NetOps には適さない可能性があります。 逆に、標準化されたサービスを本番環境に迅速に導入するためにテンプレートを使用することはますます一般的になっていますが、applicationsの独自性が極めて高い DevOps ではほとんど適用されません。

いずれにせよ、両方のツールチェーンには共通点があります。それは、1 つのリンクの弱点がチェーン全体に感染するという点です。 スクリプトを活用した主に手動によるデプロイメントに依存している場合でも、配信とデプロイメントの全体的なプロセスを表すツールチェーンが存在します。 人々は、今日のソフトウェアを配信および展開するツールチェーンのリンクになることができますし、実際にリンクになっています。 そして、ボブが最新のインフルエンザで休んでいるなど、重要なリンクが欠落している場合、プロセスは機能しなくなります。 ツールチェーンの配信 (またはデプロイ) に失敗します。

社内のデジタル トランスフォーメーションを推進していく上で、DevOps および NetOps ツールチェーンの重要性を認識し、それを構成するリンクを見逃さないことが重要です。 継続的なデプロイメントの目標に向かって前進する際に、リンクの 1 つに注意を払わないと、チェーン全体が弱体化します。 ビジネスがこれらの相互にリンクされたチェーンにますます依存するようになると、弱いリンクはプロセスだけでなくビジネスも破壊します。