コンテナの世界では、宣言的な構成が重要です

内部のデジタル変革は、外部のデジタル変革を実現するために不可欠です。 社内のデジタル変革の基本的な要素の 1 つは自動化であり、これはコントロール プレーンに大きく依存しています。 コントロール プレーンは自動化が行われる場所です。 昔のコンピューターでは、これを「管理ネットワーク」と呼び、監視、構成、制御を行うために SNMP などのプロトコルを使用していました。

現在でも、管理ネットワークは、少なくとも理論的には、コントロール プレーンを介して同じタスクを実行する媒体として存在しています。 コントロール プレーンは、複雑な分散システム内の個々のコンポーネントが (ほぼ) 自動的に自分自身を管理できるようにする API、マスター ノード、さらにはメッセージ キューが入り組んだ領域です。 ますますイベント駆動型になりつつあり、主に命令型の管理モデルに依存していた過去の集中型のコマンド アンド コントロール モデルからの考え方の変更が求められています。 つまり、中央システムは、変更を発生させる特定の API 呼び出しを使用して、コンポーネントに暗黙的に指示します。 一方、今日の環境では、環境自体を変更する責任を分散する宣言型モデルに依存しています。

コンテナ化された環境ほど、このことが顕著に表れるシステムはありません。 外から見ると、このようなシステムは本質的にほとんど無法地帯のように見えます。メッセージやイベントは、誰が、または何が反応すべきかを指示する支配者がいないまま、無差別に公開され、実行されます。 コントロール プレーンはもはや制御に関するものではなく、旧式の管理システムのハブ アンド スポーク アーキテクチャよりもメッシュに近いプレーン全体にわたる分散に関するものです。 従来の世界では、API とプロトコルを使用してコンポーネントに変更をプッシュしていました。 デジタル化されたコンテナ化された世界では、コンポーネント自体を変更するために必要な情報を取得するために API を使用します。

この新しい世界はリアクティブであり、従来のコントロール プレーンの命令型 (API 駆動型) モデルを避け、代わりに、よりオープンで宣言型のモデルに依存して、望ましい自動化された最終状態を実現します。

これは驚くべきことではありません。 私たちは、DevOps、クラウド、NFV の理念の下、あらゆるものにソフトウェア主導のアプローチを採用するようになり、同時に大規模な運用規模にも対応する必要に迫られました。 ハブ アンド スポーク型の命令型管理モデルでは、あらゆる変更の負担が、ほぼ無制限のコンポーネント グループと複雑な API 配列を介して通信できる中央コントローラにかかるため、効率的に拡張できません。 これは「プッシュ」モデルであり、マネージャー (コントローラー) が影響を受ける各コンポーネントに変更をプッシュします。 それは、システム全体の成否を左右するボトルネックになります。

コンポーネントによるプルに依存するイベント駆動型モデルは、コントローラの負荷を拡張して軽減するために必要であり、そのためには、このコントロール プレーンに参加したいコンポーネントが宣言型構成モデルに慣れている必要があります。 コンテナは、API (命令型) 経由で変更をプッシュするのではなく、宣言型の構成経由で変更をプルするようにプッシュするからです。 変更を正しくサブスクライブし、その変更を直ちに実装するために必要な適切な情報を取得する責任は、コンポーネント プロバイダー (オープン ソースか商用かに関係なく) にあります。

それがコードとしてのインフラストラクチャのように聞こえるなら、その通りです。 宣言型構成は基本的にコード、または少なくともコード成果物です。 自動化は、構成をサービスから切り離すという前提にますます依存するようになっています。 理想的なユートピアモデルでは、これらの宣言的構成は完全に不可知論的です。 つまり、そのサービスをサポートするあらゆるベンダー (商用またはオープンソース) のあらゆる製品で読み取ることができます。 たとえば、適切なサービス (仮想サーバー) とそのリソース プールを危険にさらすアプリを記述する宣言型構成は、サービス X またはサービス Y によって取り込まれ、実装できるようになります。

Kubernetes リソース ファイルは、何が望ましいかは記述されているものの、その方法が規定されていない宣言型構成モデルの良い例です。 これは、望ましい結果を達成する方法を実装者が熟知している（場合によっては詳細に）ことを要求するインフラストラクチャ API に依存するシステムとは大きく異なります。

宣言型モデルにより、インフラストラクチャを牛のように扱うことも可能になります。 1 つのインスタンスが失敗した場合は、それを強制終了して新しいインスタンスを起動するのは簡単です。 必要な設定はすべてリソース ファイルにあります。失われる作業がないため、「作業を保存しないと失われます」というボタンはありません。 これはほぼ不変であり、間違いなく使い捨てのインフラストラクチャであり、障害の影響を最小限に抑えるために、秒単位ではないにしても分単位で変化するシステムでは必須です。

大規模で、そして（あえて言えば）セキュリティの高い自動化システムへの移行が進むにつれ、アプリケーション データ パスを構成する無数のデバイスとサービスの管理に宣言型モデルを採用する必要が出てきます。そうしないと、統合と自動化の手動方法によって発生した運用上の負債の山に埋もれてしまうリスクがあります。