NetOps でデータセンターの世代間ギャップを埋める
ハードウェアは重要ではないと誰かに言われても信じないでください。 ハードウェアはどこにでもあります。 すべての携帯電話に。 私たちが所有するすべての Fitbit とテクノロジー ガジェット。 私たちの車の中で。 ノートパソコンやタブレットでも。 ますます、私たちの家電製品にそれが搭載されるようになっています。 私たちの時計の中に。 そしてどうやら、場合によっては、私たちにも。 より小型で、より高速で、より多産です。
アプリは、規模の大小に関係なく、ハードウェア リソースを必要とします。 CPU。 メモリ。 ストレージ。 ネットワーク。 これらがなければ、どれも機能しません。 なし。 データ センターでもクラウド (データ センター) でも、ハードウェアはどこにでもあります。 これは、私たちの生活のつながり、協力、利便性を高めるためにアプリに必要な処理能力を提供します。
しかし、これはデータセンターのハードウェアが変化していないことを意味するものではありません。 そうです。 ハードウェアは今でもあらゆるテクノロジーを構築する基盤ですが、その上に構築するフレームワークとテクニカル ハウス (アプリ) は変化しています。 場合によっては、かなり劇的なこともあります。 大規模に分散されたシステム自体のように、コンピューティングとメモリの基盤となるメッシュを使用して、リソースをプールし、アプリケーションを複数のサービスに分解できる場合、ムーアの法則はもはや制約ではなくなります。
これらのデータ センターの変化は、リソースのプロビジョニング、管理、消費方法のモデルに基づいて、世代の観点から見ることができます。
アプリ インフラストラクチャの 4 世代
アプリケーション インフラストラクチャの最も長寿命な世代である第 0 世代では、マシンを起動してアプリケーションを開始し、連続した数年間の稼働時間を誇らしげに自慢していました。 その後、仮想化が導入され、マシンを起動し、仮想マシンを実行するアプリを再開できるようになりました。 単一システムの稼働時間は時代遅れとなり、アプリの可用性が今日の指標となりました。 クラウドでは、ボタンをクリックするだけでサービスを起動でき、指を動かすことなくスケールアップやスケールダウンができます。 そして、ポストクラウド世代では、コンテナはデイトナのピットクルーが羨むほどのスピードで自動的に自己複製します*。
アプリ インフラストラクチャの世代間の時間が短縮されています。 世代 0 と世代 1 の間には数十年にわたります。 仮想化は長い間存在していましたが、2010 年近くまで「成熟」していませんでした。 雲？ 2015年。 コンテナ？ まだ2018年でもないのに、彼らは急速に動いています。 各世代は、前の世代から学んだ教訓に基づいて前進し、失敗や欠点に注目しながら、それらを改善しようと努めます。 これらの改善の中心となるのは、スピードと規模です。 市場投入と納品のスピード。 ビジネスの規模と、現在ビジネスが依存しているアプリの規模。 どちらも、データセンターのあらゆる側面に影響を与える進化的な変化に貢献してきました。
これらすべてのアプリとサービスには、依然としてハードウェアが必要です。 リソースは、たとえ魔法のように見えても、実際には現れません。 これが、仮想化とクラウドがこれほどのペースで成長した理由の 1 つです。 魔法のようだったから。 しかし、魔法は結局のところ単なる幻想です。 コンピューティングの場合、これはハードウェア (およびそれが提供するリソース) がまだ存在することを意味します。 変わったのは、それをプロビジョニング、管理、消費する方法です。 そして、これらの変化はデータセンター内のすべてのラックに大きな影響を与えています。
そして、世代間のギャップが生じており、NetOps でそのギャップを埋める必要があります。
自動化と応答性が求められる
組織が現在、新しいアプリケーションや API を提供するよう求められている規模とスピードにより、クラウドやコンテナ、オンプレミスやオフプレミスを問わず、自動化の必要性が生じています。 アプリやアプリ サービスによるハードウェア リソースの使用寿命が短くなると、驚異的な速度でリサイクルが必要になります。 手動のプロセスと長い起動時間では、このようなシステムが設定する激しいペースに追いつくことができません。 つまり、高速に拡張するために必要な、高速かつ頻繁なサービスの作成と破棄を可能にする、コンテナ化されたクラウド（または少なくともクラウドのような）フレームワークを意味します。
自動化、リソースの消費、サービス作成速度によって、データ センターの世代区分が決まります。 第 2 世代 (クラウド) から第 3 世代 (コンテナー) に移行するだけでも、これらの特性は大幅に変化します。 各世代では、数か月や数年ではなく数分間のリソース消費プロファイルのおかげで、完全に自動化された 1 秒未満の応答性に向けてさらに前進しています。
そのため、NetOps は現在非常に重要な焦点となっています (または、そうあるべきです)。 なぜなら、第 2 世代および第 3 世代のアプリケーション インフラストラクチャから生じる期待に最も影響を受けるのは、ネットワーク (従来のハードウェア ネットワーク) だからです。 IT 部門は、4 世代すべてにわたるアプリケーション インフラストラクチャのサポートを任されることが多く、ネットワーク内のコストとインフラストラクチャを共有する必要があることがよくあります。 それは多くの場合、専用に作られた機器を意味します。 しかし、アプリ サービスが従来のアプライアンスでホストされている場合でも、第 2 世代または第 3 世代のアプリ インフラストラクチャ モデルで使用できる手段を提供する必要があります。
第 1 世代をサポートするために必要な信頼性を維持しながら、最新世代の要求を満たすには、セルフサービスと自動化を使用する必要があります。 つまり、チケットシステムとの統合と、API およびダッシュボードを介した分析の公開を意味します。 つまり、基盤となるハードウェアが専用に構築されたものか COTS かに関係なく、ネットワークは、第 2 世代または第 3 世代のアプリケーション インフラストラクチャと同じ速さで応答する、消費可能で自動化可能なリソースとして機能しなければなりません。
場合によっては、ネットワーク サービスとアプリ サービスが、配信するアプリケーションと同じスタイルのインフラストラクチャを採用する必要があることを意味します。 負荷分散や Web アプリケーション セキュリティなどのアプリ サービスは、開発者にますます受け入れられ、アプリのアーキテクチャやインフラストラクチャに組み込まれるようになっています。 その他のもの、特にセキュリティの分野では、第 2 世代 (クラウド) 環境ではうまく機能しない (またはまったく機能しない) ものもあります。 つまり、これらのサービスはクラウドで利用でき、コンテナ化され、簡単にアクセスできるものでなければなりません。
データセンター内に存在する世代間のギャップは、組織にとって問題となる可能性があります。 これらは、デジタル変革の取り組みを阻害したり、完全に停止させたりする可能性があります。 これらは、開発と IT の間、IT とビジネスの間、ビジネスと顧客の間の摩擦を間違いなく増大させます。 この摩擦は、API、セルフサービス、自動化を備えた第 2 世代および第 3 世代のインフラストラクチャ モデルをサポートするために必要な消費モデルを満たす NetOps の取り組みによって軽減できます。
成熟したデータ センターでは、異なる世代のアプリケーション間で複雑さと競合する要件が発生する場合があり、その課題に対処するのは NetOps次第です。 
4 世代のアプリケーション インフラストラクチャを同時にサポートするには、ネットワーク (およびそれに伴うすべてのもの) を変革する必要があります。
*NASCAR のピットクルーは、ピットストップ (4 つのタイヤすべてを交換) を 12 秒以内に完了することを目指しています。 記録された最速のピットストップはわずか8秒でした。 乗務員の作業スピードがドライバーの成功の鍵となります。