どのようなテクノロジートレンドにも、たちまち過剰な期待を集め、実質的に意味をなさなくなる言葉が必ずあります。当初の「クラウド」がそうでした。ある意味では、今もそうです。DevOpsは、その意味が整理されるまでに数年を要しました（今も整理されたとは言い切れません）。現在、機械学習とAIは誇大宣伝の波を裸足で乗りこなし、当分の間、波にのまれる気配はありません。
これらに続くのが「as code」です。
突如として、あらゆるものが「as code」になりました。市場は「as code」に夢中です。その大半がC、C++、C#の違いすら分からなくても、勢いは止まりません。「as code」は、生命、宇宙、そして万物についての究極の答えとなりました。「as code」で解決できない問題はなく、誰もが取り組んでいます。
用語の範囲や明確な定義がないまま言葉だけが独り歩きしているときは、いったん立ち止まり、*私たち*がその用語をどう定義しているのかを明確にすることが重要です。参照できるRFC形式の定義を策定する標準化委員会があればよいのですが、実際には存在しません。最も近い存在はNISTですが、クラウドをめぐる混乱をどれほど収められたかは、すでにご存じのとおりです。
「as-code」は、単なるInfrastructure as Code（IAC）にとどまりません。PythianのAiman Najjar氏が、現在のInfrastructure as Codeを取り巻く状況について、優れた概要をまとめています。コンテナを独立したレイヤーとする点（ネットワークおよびアプリケーションサービスの観点では、コンテナも単なるインフラストラクチャです）と、Jenkinsを含めない点には同意できませんが、全体として彼のブログは、「as code」の各レイヤー間の関係を理解し、用途に適したツールを対応付けるうえで非常に役立つ内容でした。また、Infrastructure as Codeに関する議論の多くは、継続的デリバリー、つまりアプリケーションをビルド、テスト、統合し、本番環境向けにリリースするパイプラインに焦点を当てています。これは、リリース済みのアプリケーションを、必要なネットワークサービスおよびアプリケーションサービスとともに本番環境へデプロイすることに重点を置く継続的デプロイメントとは異なるプロセスです。
注記 アプリケーションの理想的な世界では、デリバリーパイプラインとデプロイメントパイプラインが統合されています。しかし、私たちの多くが（今なお）直面している現実では、本番環境と開発環境は分かれており、それぞれ要件や制約が異なります。そのため、パイプラインを自動化する際には、この違いを認識する必要があります。
ITとデプロイメントパイプラインに固有の複雑な事情に対応するため、3つの明確なレイヤーが形成されています。その中でも特に重要なのが、環境そのものに内在する複雑さです。ネットワーク図でクライアントからアプリまでを一直線で結んでも、実態がそれほど単純ではないことは誰もが知っています。内部では、図にする時間（と根気）が足りないほど多くの処理が行われています。
パイプライン自体が多様であること、つまり専用ハードウェアに加え、COTS上にデプロイされる仮想ソフトウェアやコンテナベースのソフトウェアで構成されていることも、「as code」を複数のレイヤーに分割する理由となります。比較的新しいハードウェアはas-codeアプローチで管理できますが、レガシーな（共有）ハードウェアをこのプロセスに組み込むことは、ほぼ不可能な場合があります。そこで、デプロイプロセス自体をより忠実に反映するようレイヤーを分離することで、レガシーと最新のハードウェアベースのソリューションに加え、ソフトウェアベースのサービスもパイプラインに組み込めるようになります。
目標は、マルチクラウド環境でアプリケーションごとのデプロイスケジュールとアーキテクチャをサポートできる、継続的なITスタックを構築することです。また、デプロイはアプリケーションの稼働ライフサイクルの始まりにすぎないため、デプロイ後の運用に重点を置く第4のレイヤーが必要です。これは、インフラストラクチャのプロビジョニングとオンボーディング、サービスの構成と管理、デプロイパイプラインをそれぞれ担う3つのコアレイヤーに追加されるものです。
このツール一覧は、すべてを網羅したものではありません。ほかにも多くのツールやツールセットがあります。たとえば、複数の調査や研究から、NetOpsの多くがネットワークおよびアプリケーションサービスの自動化に専用のPythonスクリプトを使用していることが分かっています。また、Cisco ACI、VMware NSX、OpenStack、Red Hat OpenShiftなどのネットワーク自動化システムやスタックも、継続的運用スタックのさまざまな機能を実装する手段として広く利用されています。図にすべてのツールを掲載するスペースはないため、DevOpsでの普及度に基づいて一部を例示しています。これは、デリバリーおよびデプロイのパイプライン全体にわたる標準化が成功に不可欠であり、「as code」のデリバリーパイプラインの実装に最もよく使われるツールについて、組織内にすでにあるスキルや専門知識を活用することが合理的だからです。なお、「operations as code」向けのツールは記載していません。少なくとも現時点では、その多くが専用のもの（カスタムスクリプト）か、特定ベンダーのテクノロジーに固有のものだからです。
注記Operations as Codeは、ITにおけるビジネスプロセス管理（BPM）に相当します。BPMでは、ビジネスプロセスを自動化します。BPMには、非常に限定的なワークフローのみに重点を置くものもあれば、購入から支払い、納品に至るまで、顧客とのやり取り全体を対象とするものもあります。Operations as Codeは、現在のIT分野ではまだ発展途上のプラクティスですが、企業がBPMを活用してきたのと同様に、運用プロセスの最適化を活用できるようにするには、運用プロセス管理へと成熟させる必要があります。
継続的運用スタック
Infrastructure as Code（IaC）
クラウドでもデータセンターでも、ネットワークの構成は必要です。上位レイヤーのサービス（レイヤー4～7で動作するサービス、別名アプリケーションサービス）でさえ、動作するにはネットワークトポロジーに関する一定の知識が必要です。まったく新しいパイプラインをデプロイする場合、その一部を有効化（ライセンス付与）する必要があることもあります。Infrastructure as Codeは、デプロイをセルフサービス化するために不可欠です。インフラストラクチャ（ソフトウェアとサービス）が整っていなければ、構成する対象も、アプリケーションのデプロイ先も存在しないためです。
担当範囲：インフラストラクチャの導入、ライセンス付与、プロビジョニング
Configuration as Code（CaC）
これは構成とは別の問題です。構成とは、対象となるサービス固有のポリシーや動作を設定する必要性を指します。構成作業は、アプリケーションのメジャーアップデートのたびに発生する可能性があります。マイナーアップデートのたびに発生する場合もあります。セキュリティ関連サービスでは、特定のサービスにパッチの適用、更新、またはアップグレードを行うため、緊急に構成作業が必要になることもあります。Configuration as Codeは、アプリケーションごとのデプロイスケジュールとパイプラインをサポートし、本番パイプライン全体の安定性を確保するうえで重要なアプリケーションデータパスの分離を徹底するために不可欠です。
担当範囲：サービスの構成、アップグレード、パッチ適用
Pipeline as Code（PaC）
さらに、アプリケーション全体とそのサービスを最初から最後まで定義する包括的なプロセスがあります。これがパイプライン全体であり、デプロイを自動的に進める実行可能なプロセスとしてコード化されます。Pipeline as CodeはIaCとCaCを結び付け、両者を統合して、いわゆるデプロイメントパイプラインを構成します。パイプラインでは、プロセスに必要な各ステップ間の待ち時間をなくせるため、速度と効率を最も大きく向上できます。
担当範囲：デプロイメントプロセスの自動化
Operations as Code（OaC）
このレイヤーは、継続的な運用を担います。監視とアラート、自動スケーリング、ディスカバリは、このレイヤーで行われます。ここでは、運用プロセスをコード化し、システムが自律的に実行できるようにすることが重要です。自動スケーリングは、コード化されることが特に多い運用プロセスの1つであり、複数のシステムが関与します。一方、分析用のテレメトリ収集も注意を要する運用プロセスです。また、そのテレメトリに基づいて実行可能なアクションにより、データパスやアプリケーションのパフォーマンスを最適化するための（自動）調整が可能になります。これらの運用プロセスにはそれぞれ固有の設定があり、デプロイプロセスの完了後に機能します。
役割：運用ワークフローの自動化
継続的運用スタックの観点から継続的デプロイメントを捉えることで、本番パイプラインの自動化に戦略的に取り組めます。レイヤーと責任範囲を分離すれば、多くの組織が望み、ビジネス部門からの要求も高まっているセルフサービス方式を実現しながら、IT業務の自動化という非常に困難な課題に取り組みやすくなります。また、ITにおける自動化活用の進化に不可欠なOperations as Codeを通じて、継続的運用への道筋も開かれます。
これは、デプロイメントパイプラインに関連する自動化の取り組みを捉える唯一絶対の方法ではないかもしれません。しかし、1つの見方ではあり、市場の各社が何に対応し、何に対応していないのかを明確に説明できるようになります。
つまり、特にF5製品に関して、私が「Infrastructure as Code」や「Configuration 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ブログをご覧ください。