アプリの引力によりネットワークが分岐する
ネットワークが分岐しています。 分岐します。 解散します。 ネットワーク サービスが、企業ネットワークという静かな郊外から、データ センター ネットワークのアプリケーション側にある忙しく騒がしい都市部へと移転するという現象を説明するために、どのような用語を使用してもかまいません。 今日の議論のポイントは用語ではなく、むしろなぜそれが起こっているのか理由について考えていきたいと思います。
「そうですね、ロリさん、企業ネットワークは明らかにハードウェアをベースとしていますが、ハードウェアには、開発と運用で行われているより流行に敏感で機敏な環境に適合するために必要な柔軟性と俊敏性がありません」と言う人もいるかもしれません。
いいえ、そうではありません。ハードウェアかソフトウェアかという問題ではありません。実際、何をするにしてもハードウェアは必要です (RAM やコンピューティング、ネットワーク アクセスなどのリソースは、どこからともなく現れるわけではありません)。 それは、一方から他方へ一部のサービスを推進している 2 つのネットワークそれぞれを管理する運用文化と現実に関するものです。
実際、実際に起こっていることは、アプリケーションが今や重心となり、月が地球に引き寄せられるのと同じように、アプリケーションに関連するすべてのサービスがアプリケーションに引き寄せられているということだと思います。
問題は、負荷分散、キャッシュ、アクセラレーション、Web アプリのセキュリティなどのアプリケーション関連のサービスはすべて、特定のアプリケーションに非常に特有であるということです。 これらは「すべての人に当てはまる」ようなサービスではありません。 それどころか、これらは高度に焦点を絞ったアプリケーション中心のサービスであり、そのポリシーは 1 つのアプリケーションを提供、保護、および最適化することを目的としています。
全部ではないです。 全部同じ種類というわけでもありません。 一つだけ。 あれ、あそこ。
これは、動作が実際にはアプリケーションにそれほど特化していないネットワーク ファイアウォールや IPS/IDS などとは大きく異なります。 Web アプリはポート 80 経由で実行されるため、ポートを開いてファイアウォール経由のアクセスを許可します。 同じプロトコル (HTTP) を使用し、同じポートで実行されるという点を除けば、これに「アプリケーション」の特異性はほとんどありません。
逆に、どのような種類のデータ (文字列? 整数? 英数字?) とどのくらいのデータ量 (15 文字?) を規定するセキュリティ ポリシーを設定することもできます。 12? 1 つの URI (/login.x) に関連付けられた単一の入力フィールド (ユーザー名、メール、コメントなど) に、100 個程度のユーザー名やメール アドレスを関連付けることができるというのは、かなりアプリケーション固有のものです。 縮小、スタイルシートの連結、および負荷分散サービス内のアプリケーションに関連付けられたヘルス監視を管理するポリシーも同様です。
親和性が重要な理由
現在、平均的な企業は約 508 個のアプリケーションを管理していると言われています。 私たちの調査によると、実際に 500 人以上の従業員を抱える組織は 31% に上りますが、これも重要な点ではなく、あくまでも基準値です。 そして、これはベースラインです。なぜなら、多くの組織がさらに多くのアプリケーションを構築することを計画しているからです。 また、マイクロサービス アーキテクチャを採用している組織では、アプリケーションの数は必ずしも変更されませんが、前述のアプリケーション関連のサービスを必要とする「システム」の数は変更されます。
それで。 組織が管理するアプリケーションの数を 2 倍にすることを検討していると想像してください。 最初は 500 だったのが、突然 1000 になったとします。 あらゆるポリシーをプロビジョニング、構成、管理する必要があります。 計算を簡単にするために、すべてのアプリに必要なのは 2 つだけ (スケール用とセキュリティ用に 1 つ) だとしましょう。 つまり、対処する必要があるポリシーは 2000 個になります。 準備ができて？ 行く。
うん。 問題は、企業ネットワークの「ハードウェア」がそれを処理できないということではありません。 それどころか、専用に構築されたハードウェアであり、汎用サーバーをはるかに超える容量を備えているからこそ、それが可能になるのです。 問題は、それをすべて実行するために必要なプロセスと人材です。 必要なのはデバイスの数だけではなく、展開する必要がある固有の (アプリケーションに関連のある) ポリシーの数も重要です。
展開されるだけでなく、更新されます。 アプリケーション関連ポリシーはアプリケーション専用に構成されているため、アプリがアップグレードされたり修正が導入されたりすると、関連付けられているアプリ サービス ポリシーも更新する必要がある可能性が高くなります。 そして、組織がより頻繁に展開することを望んでいる場合、企業のネットワーク担当者が完全に圧倒されることは想像に難くありません。
一方、アプリ ネットワークでは、開発者と運用担当者が飢えています。 アプリを配信して展開することに熱心です。 彼らは、自動化とオーケストレーションに関する新しいスキルを活用して、そのプロセスをスピードアップする準備ができています。
そして、彼らは、より多くのアプリケーション関連サービスに対する責任を引き受け、それらを展開アーキテクチャとプロセスに組み込むことで、その通りになっています。 DevOps の認知度が高まり、SDN からの業界の奨励もあって、ネットワーク サービスはほぼすべて API で有効化されています。 その他多くのアプリケーションでは、アプリケーションのサポートに必要なインフラストラクチャの管理と展開に「インフラストラクチャ アズ コード」アプローチを採用しているオペレーターの手にピッタリとフィットするテンプレートが使用可能になっています。
そのため、アプリケーション ネットワークではますます多くの「アプリケーション サービス」が登場し、エンタープライズ IT の重心がアプリケーションへと移行しています。
これはビジネスと運用の拡大戦略です。 これは、ネットワークやアプリケーションの人員を増やさずに、ブルックスの法則に反することなく、アプリケーション ポートフォリオの急速な増加に対処する方法です。 これは、ネットワーク オペレータが現在管理しているポリシーの数の 2 倍、3 倍、あるいはそれ以上の数を突然管理する必要が生じることによる混乱を招くことなく、IT 部門がより迅速かつ頻繁にアプリケーションを市場に提供できるようにする方法です。