将来、API の A は自動化を意味します

API はapplicationプログラミング インターフェイスの略です。 長年にわたり、密結合の命令型仕様から疎結合の宣言型モデルへと進化してきました。 現在最も一般的な API は RESTful であり、統合を可能にするために使用されます。 実装や呼び出しモードに関係なく、API はアプリ開発に関連付けられる傾向があります。 

しかし、別の API エコノミーは着実に拡大しています。 それはオペレーションの中にあります。 そして、その分野では、API の「A」は自動化を意味します。

運用領域における API が表すのは、インフラストラクチャとapplicationサービスのオンボーディング、構成、および操作を自動化する機能です。 したがって、運用をサポートするために必要なインターフェース (API) は、自動化の簡素化に重点を置く必要があります。

組織がデジタル トランスフォーメーションの第 2 フェーズに完全に移行し、配信および展開パイプライン全体にわたって自動化を拡大し始めるにつれて、この重点は重要になります。 自動化を拡張するには、アプリの展開パイプラインを具体化する、一貫性があり、反復可能で、予測可能なプロセスを開発する能力が必要です。 

Kentik の 2019 年の自動化の現状に関するレポートによると、組織の半数以上 (53%) がすでにネットワーク構成の自動化を使用しており、さらに 40% がポリシー管理を自動化しています。 当社独自の調査では、その割合ははるかに高く、ネットワークの自動化が 86% という圧倒的多数を占めていることがわかっています。 同じ調査「State of Application Services 2020」では、展開パイプライン全体にわたって自動化の状態の一貫性が高まっていることも明らかになりました。

組織が使用するツールも変化しています。 Python は依然として最も人気のある選択肢の 1 つですが、DevOps とクラウドネイティブ アプリが IT に影響を与えていることがわかります。 デプロイメント パイプラインは、Jenkins や Ansible などのツールによって駆動され、GitHub や GitLab Enterprise などのリポジトリによってトリガーされることが多くなっています。 将来的には、インフラストラクチャとアプリ サービスは、高度な分析によって生成される実用的な洞察によって推進されるようになります。

デプロイメント パイプライン全体で API を呼び出すのは人ではなくシステムです。 したがって、自動化を念頭に置いて運用 API を設計することが不可欠です。 それはいくつかの考慮事項を意味します。

まず、運用 API が呼び出される可能性のあるシステムを考慮する必要がある場合があります。 Jenkins またはリポジトリから入手できるデータは、従来のネットワーク自動化ツールやサービスから入手できるデータとは明らかに異なります。 つまり、他の場所からデータを取得するか、可能な場合は標準化された値をデフォルトに設定することを意味します。 

第二に、「認証済みユーザー」の呼び出しとは別に、「認証済みマシン」による API の呼び出しの必要性に対処することが重要です。 今日の認証システムのほとんどは、「ユーザー」が人間であることを前提としています。 API キーは良い選択肢かもしれませんが、マシンのみの資格情報を維持するように設計されたシステムを展開、操作、管理するには、IT の運用面に関するある程度の学習が必要になります。 それでも、デジタル トランスフォーメーションの第 3 段階および最終段階に進むにつれて、これは重要になります。この段階では、AI 支援applicationサービスと運用が運用上の負担のより大きな部分を担うことになります。

ツールを使用してスクリプトを作成し、そこから操作を自動化できるのは素晴らしいことです。 しかし、将来的には、API の A は、少なくとも運用の文脈では、人間ではなくマシン間のやり取りや呼び出しにどのような影響を与えるかという点で、ほぼ独占的に自動化を指すようになることを認識することが重要です。