NetOps 自動化にとって宣言型モデルが重要なのはなぜですか?

すべてを自動化する場合は、宣言型にする必要があります。 理由はこうです。

私たちは、自動化、特に NetOps とアプリケーション サービスについて語るときはいつも、宣言型の重要性をかなり長い間強調してきました。 しかし、それがなぜ重要なのか、そしてどのようなメリットがあるのかを私たちはまだ深く掘り下げていません。 今すぐにそれを修正することを目指しています。

思い出していただきたいのですが、現在、あらゆるものの構成と展開を自動化するために使用されているモデルは 2 つあります。

1 つ目は命令型で、ターゲット システムに実行したい操作を正確に指示します。 システムへの SSH トンネルを開き、CLI で特定のコマンド セットを入力したことがある場合は、命令型の構成モデルを採用したことになります。

2 番目 (推奨) は宣言型で、ターゲット システムに何を実行するかを伝えますが、その方法は伝えません。 これは、さまざまな理由からほとんどのネットワーク自動化ソリューションで採用されているモデルですが、最も顕著な理由は、特定の環境に存在する可能性のある何百ものデバイスとシステムを学習して統合するために必要な膨大なコストと時間です。

したがって、命令型モデルでは、システムを構成するために必要な各コマンド (または API 呼び出し) を指定する必要があります。 宣言型モデルでは、(通常は) 必要なものを表すキーと値のペアを指定するだけで、それを実現するためのコマンドについては他のシステムに任せます。

簡単ですよ。

さて、なぜこれが重要なのかという質問に答えましょう。 すべてを自動化しようとしているときに宣言型モデルを採用すると、主に 4 つの利点があります。

1. ヒューマンエラーの削減

生産中の停止インシデントの約 22% は人為的エラーによって発生していることがわかっています。 かなり注目を集めた事件の中には、ここでは詳しく述べないが、単純な人為的ミスが直接の原因であるものもある。 API 呼び出しに依存する命令型モデルでは、それぞれが潜在的なインシデントとして発生する可能性があります。 変数を検証しなかった場合、エラー コードを確認するのを忘れた場合、またはその他考えられるさまざまなシナリオの場合、再開生成イベントが発生する可能性があります。 それは悪いことだ。

宣言型モデルは、API 呼び出しを使用して実行される前に解析および検証される何らかのテンプレートまたは構成ファイルに基づいています。 確かに、構成ファイルやテンプレートを台無しにする可能性はありますが、必要なコードが減るため、そうする機会は限られます。 また、コードが少ないということは、一般的にミスを犯す機会も少ないことを意味します。

2. 技術的負債を減らす

技術的負債とは、開発から得た楽しい比喩であり、私たちの選択の長期的なコストを思い出させてくれます。 命令型モデルでは、技術的負債がさまざまな形で増大します。 まず、スクリプトをターゲット システムの API に結合します。 この API は他のものをサポートする可能性は低いため、システムごとにスクリプトを開発することになります。 構成手順もアプリごとに異なる可能性があります。すべてが HTTP であるわけではなく、すべての HTTP ベースのアプリケーションでまったく同じサービス構成が必要なわけではありません。 そのため、現在はアプリごと、システムごとにスクリプトを作成しています。 それは大量のスクリプトであり、その選択に基づいて大量の負債が積み重なることになります。

逆に、宣言型の方法では、同じデプロイメント プロセス スクリプトとシステムを使用できます。 テンプレート/構成はアプリケーションやシステムに固有である可能性はありますが、単一のファイルです。 スクリプトの複雑さと数が削減され、技術的負債が大幅に削減されます。 現実には、私たちの選択によって常にいくらかの負債が発生することになります。それを最小限に抑えることが目標です。 

3. バージョンの衝突を排除

構成と展開のプロセスを API に結び付けると、そのバージョンの API に結び付けられます。インターネットには、API の変更やアプリの変更に必要な作業について、敵対的で怒りに満ちた開発者が声高に批判するコミュニティが数多くあります。ネットワーク サービスやアプリケーション サービスでも同じことが起こる可能性があります (実際に起こるでしょう)。 したがって、API の 1 つのバージョンに縛られていて、何かが変更された場合、どうなると思いますか? スクリプトを牛が家に帰るまで更新（または書き直し）し続けることになります。

しかし、宣言型モデルを採用している場合は、API の変更を無視できる可能性が高くなります。結局のところ、API を使用してシステムにサービスを展開する方法を指示しているのではなく、展開する必要があるものを指示しているだけです。

4. ドメイン専門知識の要件を軽減

正直に言うと、ネットワークやアプリケーション サービスで API を使用する場合は、システムを理解する必要があります。 仮想 IP と仮想サーバーの違いがわからない場合は、すでに困った状況に陥っています。ノードとメンバーの違いについてはまだほとんど触れていません。 命令型の API ベースの方法では、ターゲット システムの構成を操作できるほど十分に理解している必要があります。

宣言型モデルを使用すると、ターゲット システムに関する専門知識が少なくて済むため、開発者や DevOps のどちらも、この方法を使用してアプリケーションをセルフサービス化できる可能性が高くなります。 もちろん、専門家は依然として必要ですが、サービスの消費者に対する要求は軽減され、プロビジョニングと展開の負担がより広範な構成員に分散されます。

NetOps 自動化の取り組みに宣言型モデルを採用する理由は他にもありますが、最も説得力があるのは次の 4 つです。 これは、NetOps、ビジネス、そしてアプリケーションをより高速かつ安全に実行するためのネットワークおよびアプリケーション サービスへのセルフサービス アクセスを必要とする幅広い関係者にメリットをもたらすためです。