ワークフローと API の比較

今日はあなたにお願いしたい仕事があります。 あなたに、そう、そこにいるあなたに、小切手を銀行に預けてほしいのです。 車に乗って銀行まで行き、中に入って窓口係員と手続きをしてから、家に戻らなければなりません。

イライラしてる？ 特に、余分な手順を踏まずにモバイル バンキング アプリを使用して実行できる場合は、そうすべきです。

これが、ワークフロー (プロセス) と API の違いです。

API 税と呼ばれるものが実際に存在します (名前は私が作りましたが、存在は知りません)。 それは、個々の API 呼び出しを使用して複雑なプロセスを実行することによって発生する時間と技術的負債です。 モバイルアプリを使って入金するのではなく、実際に銀行に行くようなものです。

この税金はプロセスが拡大するにつれて増加します。 10 または 20 の異なる API 呼び出しを必要とする長いプロセスがある場合、コード (スクリプトもコードです) はますます複雑になり、トラブルシューティングに影響し、将来の変更が困難になります。 個々の API 呼び出しを通じてプロセスを硬直化させることは、俊敏性の反対です。 最適化を通じて効率を向上させる機会を凍結するのは脆弱性です。

ワークフローは基本的に、よく実行されるタスク用に事前定義されたプロセスです。 ほとんどのビジネス プロセス (および運用プロセス) はこのカテゴリに分類されます。 これらは、ログインしてシステムの適切な部分に移動し、ポートのアクセス制御を変更して、変更をコミットするために使用するコマンドです。 このタスクを実行するたびに、結果は同じになります。 これは一般的に実行されるプロセスであり、簡単にコード化できます。 運用にはこのようなプロセスが多数あり、それらをワークフローとしてまとめることで、API 税を排除できるだけでなく、それらを呼び出すスクリプトの品質と持続可能性を向上させることができます。

これは、API の代わりにワークフローを使用すると、コードが複雑でなくなり、管理や変更が容易になるためです。 より機敏で、より壊れにくいです。

完全に作り話の例を考えてみましょう。 1 つ目は、API ベースのアプローチです。 そのプロセスの各ステップは API 呼び出しを表します。 つまり、約 20 種類の異なる呼び出しを含むスクリプトを、時間をかけて開発、テスト、保守する必要があります。 それは技術的負債です。 これは、作成時点で動作しているシステムの API バージョンに関連付けられています。 それらの呼び出しの 1 つが変更されると、スクリプトも変更する必要があります。

右側はワークフローベースのアプローチです。 API 呼び出しを介してプロセスを開始することもできます (多くの組織ではこれが望ましいでしょう) が、プロセスの実際の手順は、最初の呼び出しで送信されたパラメーター (変数) に基づいて実行されます。 クリーンアップしてコミットする必要があるかもしれませんが、それでも必要なコードは 2 回以下のやり取りに削減されます。

API やテンプレートを使用することは悪いことだと言っているわけではありません。 そうではありません。 しかし、特にネットワークの世界では、API を使用するには、システムやネットワーク全般に固有の知識が必要になることがよくあります。 これにより、DevOps や開発者が API を操作することが難しくなります。 ワークフロー アプローチでは、知識や専門知識の前提がなくなるため、DevOps はそれらを快適に使用でき、NetOps は仕事の安定性を維持できます。  

自動化が定着しつつある（場合によっては自動化が主流になりつつある）環境では、ワークフロー ベースのアプローチにより、大量のドメイン固有の知識を必要とせずにタスクを呼び出す機能を DevOps に提供することで、NetOps に実質的な負担軽減を提供できます。

さらに、厄介な API 税も回避できます。 税金逃れを好まない人がいるでしょうか?