データセンターに関する議論の中心となるあらゆるテクノロジーと同様に、DevOpsも現在、「定義疲れ」に陥っています。実際のところ、もはや「定義疲れ」を通り越して疲弊しているようにも思えますが、その境界を見極めるのは困難です。要するに、DevOpsには、クラウドやSDNと同じく、広く受け入れられた定義がまだありません。
しかし、DevOpsには、それを構成する概念も混同されがちという特有の問題があります。たとえば、CDは「継続的デリバリー」または「継続的デプロイメント」を意味する場合があります。この2つは同じものではなく、混同すべきでもありません。Puppet Labsは、両者の違いをブログ記事で非常にわかりやすく説明しています:

決定的な違いは、本番環境へのデプロイが「手動」(継続的デリバリー)か「自動」(継続的デプロイ)かという点です。
実際には、「本番環境にデプロイ」と書かれた小さなオレンジ色のボックスには、自動化すべき作業が数多く含まれています。単にアプリとその依存関係(データベース、その他のサービス、インフラストラクチャなど)をデプロイするだけではありません。さらに、そのアプリケーションを最終的な利用者に提供するために必要な、すべてのネットワークサービスとアプリケーションサービスもデプロイする必要があります。ここでアプリケーションサービスが重要になり、アプリケーションデリバリ(開発上の意味ではなく、本番環境での意味)が継続的デプロイのパイプラインに組み込まれます。
継続的デプロイパイプライン内の「本番環境へのデプロイ」ステップを自動化するには、多くの構成要素をプロビジョニング、設定、テストする必要があります。対象となるのは、基本的なネットワークから、セキュリティ(ファイアウォールなど)、可用性(負荷分散)、パフォーマンス(高速化、キャッシュなど)に関するサービスまで多岐にわたります。平均すると、組織は11種類のアプリケーションデリバリサービスを利用しています。これは、高速でセキュアかつ可用性の高いアプリケーションを実現するためです。各サービスをデプロイ(プロビジョニングおよび設定)する必要があり、一部のサービスは、ほかのサービスのデプロイに依存します。
これらのサービスにはそれぞれ(ここまで数えている方には、セント・アイヴスのなぞなぞのようなものです)、設定が必要な特性がいくつもあり、その数はサービスによって異なります。オプションのtrueまたはfalseへの設定、アルゴリズムの選択、ルートの確立なども必要です……
つまり、「手動」から「自動」への切り替えは、言葉で言うほど簡単ではありません。
ネットワーク移行を阻む要因
これらのプロセスを自動化するうえで大きな障壁となるのが、共有コンポーネントとアプリケーションごとのコンポーネントの違いです。アプリケーションインフラストラクチャの領域でInfrastructure as Codeが可能なのは、Webサーバーやロードバランサーなどのインフラストラクチャを特定のアプリケーション専用にできるためです。つまり、その構成ファイルは一種のマイクロサービスのようなもので、対象範囲が限定され、1つのアプリケーションへのサービス提供に特化しています。

ネットワークとアプリサービスの世界では、必ずしもそうとは限りません。たとえば、ルーターやスイッチは、その目的上、複数のアプリケーションに接続性と転送サービスを提供するよう設計されています。そのため、構成ファイルには必然的に複数のアプリケーションが含まれます。バージョン管理が役立つ可能性はあるものの、実際には構成はアプリではなく、デバイスと強く結び付いています。アプリサービスとセキュリティについても同様です。
このように、APIがCLIの役割を担う世界へと移行しているのは望ましいことですが、構成をアプリケーション単位で管理できる、アプリ単位(またはアプリ中心)のパラダイムをサポートする必要性にも対応しなければなりません。
つまり、サービスをアプリ単位でデプロイおよび構成する、マイクロサービス型のネットワークアーキテクチャへ移行する必要があります。その形態としては、専用の「デバイス」(仮想またはハードウェア。この議論ではフォームファクターは問いません)か、テンプレートのようなアプリ固有の構成が考えられます。
目標には到達したのか?
APIを利用してアプリケーション単位でテンプレートをデプロイする(つまり、Infrastructure as Codeを実現する)プロビジョニングおよび管理の宣言型モデルにより、目標には近づいていますが、まだ到達してはいません。継続的デプロイを十分に機能させ、成功に導くために必要な自動化をどのようにオーケストレーションするかについては、まだ多くの検討と取り組みが必要です。
継続的デリバリーから継続的デプロイメントへの移行を完了するうえで重要な「本番環境へのデプロイ」ステップを「手動」から「自動」に移行するには、ネットワーク、インフラストラクチャ、アプリサービス、セキュリティの各サイロも対象に含める必要があります。そのためには、自動化レイヤーでのさらなる取り組みに加え、最終的に本番環境への継続的デプロイメントを実現するプロセスを完全に自動化するための包括的なオーケストレーションも必要です。
著者について

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ブログをご覧ください。