宣言型インターフェースがインフラストラクチャを民主化する方法

API は新しい CLI です。ただし、どのような種類の API を構築するかに関しては、宣言型が主流となります。

API (アプリケーション プログラミング インターフェイス) は、今日では重要な機能です。 組織は、いわゆる「市民開発者」によるパートナー統合とイノベーションを促進するために、ビジネス レイヤーにそれらを配置します。 アプリケーションには、統合を容易にし、頻繁に変更される可能性のあるビジネス ロジックを、それほど頻繁に変更されるべきではないインターフェイスから分離するために、これらが用意されています。 そして、インフラにはそれらが備わっています。 スイッチからルーター、アプリケーション サービスからミドルウェアやデータベースまで、配信および展開パイプラインを構成するインフラストラクチャは API によって有効化されます。

それ自体が、立ち止まって、これからの NetOps コミュニティにとってそれが何を意味するのかを考える理由になるはずです。 組織は、いくつかの主要なアプリケーション インフラストラクチャ コンポーネントを標準化する傾向がありますが、いくつかの主要なネットワークおよびアプリケーション サービス インフラストラクチャ コンポーネントだけを標準化する可能性は低いためです。

組織がアプリケーションの高速化と安全性向上のために使用するアプリケーション サービスは平均 16 種類ありますが、これらは少数のインフラストラクチャ コンポーネントによって提供されることは間違いありません。 寛大に、コンポーネントあたり 3 つのアプリケーション サービスという比率を想定した場合でも、5 つの異なるデバイスと 5 つの異なる API が存在することになります。

これに関する問題は、インフラストラクチャ プロバイダーが「API は新しい CLI です」という発言を文字通りに受け止めすぎることが多いことです。 つまり、API は CLI を REST 対応にしたものにすぎません。

インフラストラクチャ コンポーネント全体で CLI を使用したことがある人なら誰でも、CLI ナビゲーションがインフラストラクチャのオブジェクト モデルに非常に密接にマッピングされることを理解しています。 API は、この設計を HTTP にリフト アンド シフトする以上のことは実行できないことがよくあります。 つまり、API を利用しようとする人は、必然的に、対象デバイスのオブジェクト モデルも学習する必要があります。

このレベルの抽象化は、自動化とオーケストレーションの前進を妨げています。なぜなら、自動化の才能だけでなく、5 つ以上の異なるネットワーク インフラストラクチャ モデルに関するある程度の専門知識を持つ自動化の才能を見つける必要があるからです。 必要とされる専門知識のレベルには、VLAN 構成とルーティングの基本的な理解から、仮想サーバー、仮想 IP アドレス、ノード、メンバー、プール間の関係に至るまで、ドメイン知識も必要になることがよくあります。

インフラストラクチャの根本的な複雑さを明らかにすることは、採用を促進し、自動化を可能にする上で有害です。 インターフェースの目的は、モデルとロジックを抽象化して、ユーザーとオペレーターをその複雑さから保護することです。 GUI は、単純なサービスを構成するためにオブジェクト階層を移動する必要性を排除することでこれを実現します。

そのため、API によってこのナビゲーションの悪夢が再び発生していることに気付くと、イライラすることがよくあります。

この問題は、ネットワークおよびアプリケーション インフラストラクチャに特有のものではありません。  つまり、MuleSoft の「 API の価値の高まり」調査では、API 統合に対する顧客とパートナーからの最も高い需要 (回答者の 47%) は「特定のビジネス ニーズに適合するカスタマイズされた API」であることがわかりました。 これに続いて、より優れたドキュメント (19%)、コード不要の統合テンプレート (19%)、必要な API および使用する API の SDK ラッパー (13%) が挙げられました。

これらすべては、簡素化を求める嘆願としてまとめることができます。 そしてテクノロジーにおいては、簡素化は抽象化を意味します。

そして、これがこの投稿の要点であり、宣言型インターフェースがその抽象化であるということです。 宣言型インターフェースは、今日のインフラストラクチャのプロビジョニング、構成、管理、統合に使用されるインターフェースを簡素化することで、インフラストラクチャを民主化し、機会を広げます。 

宣言文と命令文

一般的に言えば、宣言型と命令型はどちらも API の一種と考えることができます。 命令型 API は、API と言われたときに思い浮かぶものです。これは、ターゲット システムに何かを実行する方法を正確に指示します。 仮想サーバーを追加する場合は、5 回、10 回、あるいはそれ以上の個別の API 呼び出しが必要な場合でも、その実行方法を正確に指示する必要があります。

つまり、適切な属性を持つ特定のオブジェクト (たとえば、IP アドレスを持つノード) を作成するように指示することになります。 次に、割り当て先のプールを名前を付けて作成するようにシステムに別途指示する必要があります。 それから、あなたは…まあ、もう要点はお分かりでしょう。 命令型 API では、システムとそのオブジェクト モデルを理解するだけでなく、意図した結果を達成するために必要な手順を理解するという負担がユーザーに課せられます。

それはあなたが必ず支払う API 税です。

さて、命令型 API は全体としては悪いものではありません。 これらは、GUI を構築したり、命令型 API で得られるような粒度を必要とする他のシステムと統合したりする場合に非常に重要です。命令型 API も必要ですが、自動化と統合に直面する NetOps や DevOps には不要です。

しかし、私たちの残りの人々にとっては、そのレベルの詳細を知る必要はありません。 実際、そのような深い知識を要求すると、自動化やオーケストレーションの取り組みが妨げられ、遅れてしまう可能性があります。 これは、特定のインフラストラクチャ ドメイン外の NetOps は言うまでもなく、インフラストラクチャを民主化し、DevOps と開発者向けのセルフサービス モデルを有効にすることにはまったく役立ちません。

ここで宣言型 API が役立ちます。

宣言型インターフェースは、実行したいことを具体的に指定し、ロジックとワークフローをシステムに任せます。 したがって、システムにノードとプールを作成するように具体的に指示し、必要なオブジェクトに対して適切なロジックをすべて実行するのではなく、代わりにそれらとそれらの関係を記述します。

宣言型インターフェースの中には JSON を使用するものもあれば、XML を使用するものもあり、さらに単純なフォーム データにフォールバックするものもあります。 これらすべてに共通するのは、データがオブジェクトを単純かつわかりやすい方法で記述し、オブジェクト モデルやシステム階層をほとんど理解する必要がないことを前提としていることです。

たとえば、この宣言は人間にとってかなり読みやすいものです。 これは、オブジェクト モデルの基本レベルの理解を前提としていますが、宣言を記述するために特定の製品の認定を必要とするほどではありません。 

"web_pool": {
"クラス": "プール",
"モニター": [
"http"
],
"メンバー": [
{
"サービスポート": 80,
"serverAddresses": [
"192.0.1.10",
"192.0.1.11"
]
}
]
}

ここで、宣言型インターフェースの価値が明らかになります。ドメイン知識の削減と、インフラストラクチャのプロビジョニングと構成の複雑さの軽減です。 必要な専門知識のレベルを下げることで、NetOps はより迅速かつ効率的に作業できるだけでなく、DevOps と開発者がその機能を活用するよう促すこともできるようになります。

インフラストラクチャを管理する標準的な方法として宣言型インターフェースを採用すると、セルフサービス機能や高度な自動化機能を提供するために利用できる人材のプールがすぐに広がります。 上記の宣言型インターフェースは、DevOps と開発者が理解して使用できるようにするために、ほとんど説明を必要としません。 一方、命令型インターフェースでは、結果を期待する前に、インフラストラクチャ固有のモデルとワークフローを学習することに多大な注意を払う必要があります。

宣言型インターフェースは、デプロイメント パイプラインを自動化し、システムを他のインフラストラクチャ サービスと統合するために必要なプロビジョニング、構成、管理を簡素化することで、インフラストラクチャを民主化します。 インフラストラクチャの民主化は、より高速でスマートな自動化と、NetOps および DevOps の動きからメリットを実現するために必要な運用ドメイン間のコラボレーションと協力を促進する能力を意味します。