コード通り: 継続的なITスタック
どのようなテクノロジートレンドにも、すぐに誇大宣伝になりすぎて実質的に役に立たなくなる用語が必ず存在します。 クラウドは、最初は一つでした。 ある意味、今でもそうです。 DevOps が解決されるまでには数年かかりました (解決できたとしても)。 機械学習と AI は現在、熱狂の波に素足で乗っており、すぐに消滅する兆候は見られません。
それらすべてに次いで多いのが「as code」です。
突然、すべてが「コードどおり」になります。 市場のほとんどは C、C++、C# の違いを区別できないにもかかわらず、「as code」には飽き足りません。 「コードとして」は、人生、宇宙、そしてすべてのものに対する答えとなりました。 「as code」で解決できない問題は存在せず、誰もがそれを行っています。
用語が境界や明確な定義なしに乱用されているときは、立ち止まって、自分たちの定義が明確であることを確認することが重要です。 参照できる RFC スタイルの定義を持つ標準化委員会があればよいのですが、そのような委員会は存在しません。 最も近いのは NIST であり、彼らがクラウドの難問をいかにうまく解決できたかを私たちは見てきました。
「as-code」には、インフラストラクチャ・アズ・コード (IAC) 以上のものが含まれます。 Aiman Najjar @ Pythian は、現在のインフラストラクチャ・アズ・コードの状況について素晴らしい概要を書きました。 コンテナが独自のレイヤーであるべきであること (ネットワークとアプリケーション サービスの観点からは単なるインフラストラクチャです) や Jenkins が属さないことには同意しませんが、一般的に彼のブログは、「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」配信パイプラインを実装するために最も一般的に使用されるツールを使用して、組織内の既存のスキルと専門知識を活用することに異論を唱えることは難しいからです。 注目すべきは、現時点では、これらの多くが特注品 (カスタム スクリプト) であるか、ベンダーのテクノロジに固有のものであるため、「コードとしての操作」用のツールはリストしていないことです。
注:コードとしての運用は、ビジネス プロセス管理 (BPM) の IT 版です。 BPM により、ビジネス プロセスが自動化されます。 一部の BPM は非常に特定のワークフローにのみ焦点を当てていますが、他の BPM は購入から支払い、配送までの顧客とのやり取りの全範囲をカバーする場合があります。 オペレーション・アズ・コードは、今日の IT では初期の実践ですが、企業が BPM を活用する方法を学んだのと同じ方法で、運用プロセスの最適化を活用できるようになるには、運用プロセス管理へと成熟する必要があります。
継続的オペレーションスタック
インフラストラクチャ・アズ・コード (IaC)
クラウドでもデータセンターでも、構成が必要なネットワークが存在します。 さらに高次のサービス (レイヤー 4 ～ 7 で動作するサービス、つまりアプリケーション サービス) を動作させるには、ネットワーク トポロジに関する知識が必要です。 まったく新しいパイプラインを展開する場合は、その一部をアクティブ化 (ライセンス付与) する必要がある場合があります。 インフラストラクチャ (ソフトウェアとサービス) が整備されていないと、アプリを構成または展開する対象がないため、展開に対するセルフサービス アプローチを有効にするには、Infrastructure as Code が必要です。
責任:インフラストラクチャのオンボーディング、ライセンス、プロビジョニング
コードとしての構成 (CaC)
これは構成とは別の問題であり、具体的には、問題のサービスに固有のポリシーと動作を構成する必要があることを意味します。 アプリケーションの主要な更新ごとに構成が繰り返される場合があります。 マイナーアップデートごとに再発する可能性もあります。 セキュリティ関連のサービスでは、特定のサービスにパッチを適用したり、更新したり、アップグレードしたりすることが緊急に発生することがあります。 コードとしての構成は、アプリごとのデプロイメント スケジュールとパイプラインをサポートするために、また、運用パイプライン全体の安定性を確保するために重要なアプリケーション データ パスの分離を強制するために重要です。
責任:サービス構成、アップグレード、パッチ
パイプライン・アズ・コード (PaC)
次に、アプリケーション全体とそのサービスを最初から最後まで定義する包括的なプロセスがあります。 これはパイプライン全体であり、デプロイメントを自動的に実行する実行可能なプロセスにコード化されています。 パイプライン・アズ・コードは、IaC と CaC を結び付けて、いわゆるデプロイメント・パイプラインを記述するリンクです。 パイプラインでは、プロセスで必要なステップ間の待機時間を排除できるため、速度と効率の最大の向上が見込まれます。
責任: 展開プロセスの自動化
コードとしてのオペレーション (OaC)
このレイヤーは、進行中の運用レイヤーです。 ここで監視とアラート、自動スケーリング、検出が行われます。 このレイヤーでは、運用プロセスを、それ自体で実行できるシステムにコード化することに重点が置かれています。 自動スケーリングは、最も頻繁にコード化される運用プロセスの 1 つであり、複数のシステムが関係します。 しかし、分析のためにテレメトリを収集することは、注意が必要な別の運用プロセスであり、そのテレメトリに基づいて実行できるアクション (データ パスまたはアプリケーション パフォーマンスを最適化するための (自動) 調整を可能にする) も同様です。 これらの運用プロセスには独自の構成があり、展開プロセスが完了した後に有効になります。
責任: 運用ワークフローの自動化
継続的運用スタックの観点から継続的デプロイメントを検討すると、運用パイプラインを自動化するための戦略的なアプローチが得られます。 レイヤーと責任を分離することで、多くの組織が希望し、ビジネスでますます需要が高まっているセルフサービス アプローチを可能にする方法で IT 業務を自動化するという非常に困難なタスクに取り組むことが容易になります。 また、コードとしての操作による継続的な運用への道も開かれます。これは、IT 内での自動化の使用に必要な進化です。
ただし、これは、デプロイメント パイプラインに関連する自動化の取り組みを見るための「唯一の正しい方法」ではない可能性があります。 しかし、それは一つの方法であり、市場が自分たちが何をするか、あるいは何をしないかを明確に発言する能力を提供します。
これは、特に F5 製品に関して、インフラストラクチャ アズ コードまたは構成アズ コードと言うときに、それが何を意味するのかを確実に理解できることを意味します。