1980年代後半から1990年代初頭はネットワーク管理の黎明期であり、何が主要なネットワーク技術として生き延びるのかはよくわかっていませんでした。基本的には Ethernet とIBMが強くサポートしていた Token Ring との間の闘いでした。 ARCnet (Attached Resource Computer NETwork) も参戦しましたが、同列の闘いにはなり得ませんでした。
90年代半ばまでに、情報の流れをコントロールするプロトコルを持つ多数のシステムを接続するのに最適だった Ethernet が、Token Ring を凌駕しました。スピードとパフォーマンスの点でも優れており、ベンダーは Ethernet 規格に準拠するようになりました。
Novell の台頭と陥落
1990年代には、1983年に市場に登場した Novell のネットワーク・オペレーティング・システム、NetWare が好評を博し、ほとんどのネットワークで NetWare が使われているような状況でした。筆者は当時 Certified NetWare Engineer（CNE）でした。1990年代の初めには、NetWare は主要な競合製品だったマイクロソフトの Windows NTよりもずっと速く動作しました。
しかし、マイクロソフトは勝利を勝ち取る決断をしました。一方、少し傲慢になりつつあった Novell の勢いは衰え始めました。製品がどれほど優れていたとしても、市場でマイクロソフトに対抗するのは非常に困難です。戦術に長けたマイクロソフトは、2000年までにはNovell を打ち負かしていました。マイクロソフトに闘いを挑まれたら、勝ち抜くのは至難の技です。
ネットワーク問題の検出とポイント製品の統合
Thomas Conrad や Frye Computer Systems (後に Seagate が買収) などが、NIC (ネットワーク・インタフェース・コントローラ) から統計情報を取得してネットワークを管理するソフトウェア製品を開発しました。1990年代後半にはポイント製品を統合しようとする試みが行われました。CA Technology はいくつかの製品を買い上げましたが、実際に統合するには至りませんでした。
ネットワーク・トポロジの構成はわかっており、より詳細な監視機能が探求され始めました。しかし、ネットワークのさまざまな領域をすべて監視する単一の方法はありませんでした。 SNMPやCMI（共通の管理インフラストラクチャ）を使ってアプリケーションを計測し、データを取得するのがせいぜいでした。
当時、筆者は Tivoli の Global Enterprise Manager の製品エバンジェリストでしたが、その Tivoli 製品は基本的には PERL スクリプトの集まりでした。すべての警告が単一ダッシュボードに入ってきて、一ヶ所から見えるはずでしたが、すべての警告が押し込まれるだけの製品は顧客が欲したものではありませんでした。顧客は、本当の単一統合管理製品、すべてが視覚化でき、意味のある情報を引き出せる製品を欲していました。
これらのプラットフォームを使おうとすると、多額の費用がかかります。また、インストールのためには専門的なサービス契約も必要でした。さらに、Tivoli などの製品を複雑な環境で稼動させようとすると、驚くほど大量の手作業と顧客側のプログラミングも必要になります。
根本原因の究明
2000年代の初めまでに、人々はネットワークのさまざまな面をそれぞれ監視するいくつかの異なるユーティリティではなく、単一の統合されたシステムを切望するようになりましたが、それはまだ簡単に手に入るようなものではありませんでした。CAは複数の製品を自社の製品用に提供されていましたが、単一の集中管理プラットフォームにそれらを本格的に統合できてはいませんでした。単にそれらの異なるポイント製品をすべて背後で立ち上げる単一の画面を持っていたに過ぎません。
ネットワーク管理テクノロジーは、その根本から連携して機能するように設計されることが重要になってきました。このころ、SMARTS（後にEMCが買収）が創立され、問題の根本原因の究明に関心が向かうようになりました。根本原因を究明するには、問題があることを検知するだけではなく、警告が出された意味を理解する必要があります。
根本原因の究明という問題は、まだ完全に解決されたとは言えません。極めて複雑で困難な問題です。ネットワーク上のコンポーネント間の関係、アプリケーション内のコンポーネント間の関係、IT インフラストラクチャ内のほとんどすべてのコンポーネント間の関係を把握する必要があります。これらの関係を自動的に検出するのは極めて困難ですが、それが必要とされています。ネットワーク管理者は、どこに問題があるかだけでなく、どうして問題が生じたかを理解しなければなりません。根本原因が究明できれば、解決方法を考え出すことができます。
クラウドは複雑さを多層化し、SDN は自動化を促進
過去15年ほどの間に大幅な進歩がありました。クラウド・コンピューティングの進展には目覚しいものがあります。パブリック・クラウドは、場合によっては IT がそのシステムを所有しないといった新しい状況を作り出しました。クラウドを含めて全体をチェックできる可視性がなかったら、所有していないかもしれないリソースも監視しなければならず、クラウドは複雑性をより深めます。
ソフトウェア定義のデータセンター、ソフトウェア定義のストレージ、ソフトウェア定義のネットワーク（SDN）が、これからの方向性を示しています。SDN は自動化を促進し、自動修復も可能になります。幸いにも、SDN は、ずっと以前に使われていた技術とは違って、堅牢なネットワーク管理機能を組み込んで構築されています。ただ、SDN は大企業向けであり、中小企業にとってはまだ道のりが遠いかもしれません。
思い起こせば、ネットワークの定義からソフトウェア定義のネットワークまで、長年にわたって歩んできたものです。