最近では、どこにいても誰かがDevOpsを支えるツールチェーンについて話していると言っても過言ではありません。誰もがツールチェーンを持っており（もちろんF5も例外ではありません）、そのすべてを支えているのが、もう1つのAPIエコノミーです。 Wikipediaによると、DevOpsツールチェーンとは、「DevOps プラクティスを採用する組織の調整のもと、ソフトウェア開発ライフサイクル全体を通じて、アプリケーションのデリバリー、開発、管理を支援する一連のツール、またはツールの組み合わせ」です。
ここまでは主にアプリに焦点を当ててきましたが、ソフトウェアが通常、そのライフサイクルの大半を過ごす（少なくとも、そうであることが望ましい）本番環境の側面もあります。同じ定義は本番環境にも当てはまりますが、私の見方では、「DevOpsプラクティスを採用する組織が連携して行う、アプリのライフサイクル全体にわたるネットワークおよびアプリサービスのプロビジョニング、構成、管理」に重点が置かれます。従来のDevOpsの文脈では、この重点領域はサイクル内の「リリース」フェーズを拡張し、ソフトウェアを本番環境にプロビジョニングしてデプロイする作業を含む「リリース関連のアクティビティ」を対象とします。これには当然、対象ユーザーにアプリケーションを安全かつセキュアに配信するために必要なネットワークおよびアプリサービスも含まれます（少なくとも、含めるべきです）。
実際のところ、継続的デプロイという理想を実現するために必要なツールをすべて備えた単一のベンダーやオープンソースプロジェクトは存在しません（ちなみに、継続的デプロイは本番環境側の領域です）。アプリ開発側で使用されるツールの一部は、本番環境側でも使われています。この2つの領域の垣根を越えた連携はますます増えています。これは「DevOps」全般にとって好ましい兆候です。従来はアプリ以外にほとんど共通点がなく、それぞれ独立性の強かった2つの組織の間で、一定の共通化が進んでいることを示しているためです。
そのため、PuppetまたはChefをVMwareやCiscoと組み合わせて使用し、アプリケーションに必要なセキュリティ、アイデンティティ、スケーラビリティを支えるネットワークサービスとアプリケーションサービスのフルスタックを自動化することが考えられます。そのために必要なテンプレートとスクリプトを作成し、正しいことを検証します。たとえば、Postmanとそのスクリプト機能を使用して、ラボ内の仮想インフラストラクチャに対するテストを行うこともできます。また、アプリケーション開発部門ですでに使用されており、助言を得たり、場合によっては1、2回のトレーニングを実施してもらったりできるため、構成アーティファクトのリポジトリにはgit が適していると判断したとします。さらに一歩進めて、プロセスをオーケストレーションし、個々のサービスをセルフサービスで利用できるようにするアプリケーションの構築（またはOpenStack環境の構築）に着手することも考えられます。つまり、デプロイメントツールチェーンを定義しているのです。
ここで、「最も弱い環の公理」が厄介な問題として姿を現し始めます。「鎖の強さは最も弱い環によって決まる」という考え方はご存じでしょう。ここで「強さ」を強調しているのは、これを「信頼性」「セキュリティ」「スケーラビリティ」などの特性に置き換えても、この公理が同じように成り立つためです。この点は、継続的デプロイを支えるツールチェーンを定義し始める際に重要です。そのチェーンを構成する各「環」が障害点となり、セキュリティ、スケーラビリティ、可用性が損なわれる可能性があるからです。
計画、検証、監視がDevOpsツールチェーンの重要な要素であるのと同様に、NetOpsツールチェーンでもこれらは不可欠です。特に監視は重要です。本番環境では、アプリケーションとインフラストラクチャ（ネットワークおよびアプリケーションサービス）が最も密接に関わるためです。障害発生時には、監視（可視化）を通じて、ビジネストランザクションから個々のリクエストとレスポンスに至るまで、全体像を把握できます。
ネットワークサービスとアプリケーションサービスの構成は、特定のアプリケーションに固有となる場合があり（実際、多くの場合そうなります）、構成も必然的に両方のツールチェーンを結び付けます。
パッケージ化とリリースの仕組みでは類似したツールを活用する場合がありますが、両者は別個に考慮すべき事項であり、要件が大きく異なることも少なくありません。ネットワークサービスとアプリケーションサービスは共有インフラストラクチャにデプロイされる場合があるため、単一システムのアプローチを前提とするツールはNetOpsに適さない可能性があります。一方、本番環境に標準化されたサービスを迅速にデプロイするためにテンプレートを使用するケースが増えていますが、アプリケーションごとの独自性が高いDevOpsでは、テンプレートが適用できることはほとんどありません。
いずれにせよ、どちらのツールチェーンにも、1つのリンクの弱点がチェーン全体に影響を及ぼすという共通点があります。スクリプトを活用しつつ、主に手作業でデプロイしている場合でも、デリバリーとデプロイのプロセス全体を構成するツールチェーンは存在します。現在、ソフトウェアのデリバリーとデプロイを担うツールチェーンでは、人もリンクになり得ますし、実際にその一部となっています。そして、Bobが流行中のインフルエンザで休んでいるなどの理由で重要なリンクが欠けると、プロセスは機能しなくなります。ツールチェーンはデリバリー（またはデプロイ）に失敗します。
社内のデジタルトランスフォーメーションを推進するにあたり、DevOpsとNetOpsのツールチェーンの重要性を認識し、それらを構成するどのリンクも見落とさないことが重要です。継続的デプロイという目標に向けて前進する中で、リンクの1つにでも注意を払わなければ、チェーン全体が弱体化します。ビジネスが相互につながったこれらのチェーンへの依存を強めるにつれ、脆弱なリンクはプロセスだけでなく、ビジネスそのものも機能不全に陥らせます。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。