私はCiscoの「EnergyWise」（Cisco IOS ベースのインテリジェントなエネルギー管理ソリューション）と、サードパーティー技術の初の統合デモの作成を手伝った。また、われわれは「Network Performance Monitor」（私が勤務する米SolarWindsが手掛けるネットワーク管理ソフトウェア）のGUIにより、導入してすぐにネットワーク電力管理を行えるようにした。オープンなAPIは、われわれ全員が良い週末を過ごせるようにしてくれる。そしてCiscoは、人々がたたえきれないほど多くのオープンAPIを開発してきた。

　しかし、基本的にわれわれが「Cisco UCS（Unified Computing System）」から学んだことは、古き良きSNMPに見切りをつけて、APIベースの管理プラットフォームに置き換えようとしても、うまくいかないということだ。

　実のところ、UCSの最もエキサイティングな側面の1つは、柔軟なファブリックインターコネクトのようなプラットフォーム技術ではなく、APIベースの機能豊富な統合モデルを持つ「UCS Manager」により、誰でも簡単に管理できると考えられることだった。SNMPは、好ましくないプロトコルと正式に位置付けられてしまった。最新の優れた技術が使えるのだから、古い面倒な技術の出番はないというわけだ。

　しかし、そうしたやり方は長続きしなかった。CiscoはUCS Managerの最新リリースで、SNMP機能を拡充し、UCSプラットフォームの大部分を管理できるようにした。UCSが、もともと想定されていなかった企業にも導入されるようになってきたことが背景にある。

　そうした企業としては、例えば、IT部門が米VCEのハード／ソフト統合システム「Vblock」をデータセンターに導入することは決してないような小規模企業などが挙げられる（VCEは、米VMwareと米Intelの投資を受け、Ciscoと米EMCによって設立された企業）。こうした顧客は、多様なサードパーティー管理ツールを利用しており、それらはいずれも、業界標準のネットワーク管理プロトコルであるSNMP に対応している。

　すなわち、支配的なベンダーが、強力なプラットフォームを掲げて新方式を推進しても、レガシー技術の侵食をはね返すことはできないということだ。もしSDNの新たなオープンソースプロジェクト「OpenDaylight Project」のような取り組みが、SDNの普及による変革を後押しし、逆戻りを防ぐことができるのなら、それは奇跡以外の何物でもないだろう。

ネットワーク管理者によるコントロールを脅かすネットワークプログラマビリティ

　また、SDNが機能する前提とされているスコープ設定と自律的な変更権限について、ネットワーク管理者が受け入れることは困難だろう。クラウド基盤ソフトウェアの「OpenStack」や、SDNを実現する技術の1つである「OpenFlow」のような技術は、UCSの設定を変えるどころではなく、エンタープライズサービスの基幹コンポーネントに対する権限を持ち、そうしたコンポーネントを自動化する。管理者は、自分が把握している詳細なレベルまで管理できるツールがなければ、SDNを使うことに懸念を抱くはずだ。

　いずれにしても、ネットワークエンジニアは、自分の承認を経ずに構成変更が行われるのを好まない。SDNプラットフォームが、いつの間にかQoS（サービス品質）ポリシーを変更してアプリケーション配信を高速化し、その一方で、CEO が使っているテレプレゼンスシステムで映像や音声が乱れてしまったら、厄介なことになるだろう。しかも、これでは管理者は、まさに管理を簡素化するために導入したプラットフォームのトラブルシューティングをする羽目になりかねない。

　われわれネットワーク管理者はエンジニアである。物理学者ではない。機器やケーブルから離れた場所で画面操作によって管理作業ができても、素直に喜べないのである。サービスがわずかでも混乱すれば、管理者はビクビクせざるを得ない。

　さらに、Ciscoが2012年に明らかにしたSDNに関する見解は、多くの管理者を不安にさせた。同社がSDNを包含するビジョンとして打ち出した「Cisco ONE（Open Network Environment）」では、ネットワークプログラマビリティがうたわれていたのである。しかし実のところ、ネットワーク管理者はプログラミングについてどう考えているのだろうか。

　プログラミングは、アプリケーションに関連するマシンの内部に適用されるが、これらのマシンでは往々にしてトラブルが起こる。そこでネットワーク管理者は問題を見越し、その具体的な答えを出す必要がある。例えば、「アプリケーションパフォーマンス管理に重点が置かれているあるベンダーのSDNコントローラーと、WANコストやQoSの管理を目的とした別のベンダーのコントローラーが衝突したら、どうなるか」「この問題を防ぐためのプログラミングやQA （品質保証）を誰が行うべきか」といった具合だ。

　SDNは世界を、あるいは少なくとも、パケット通信の世界を変える可能性を秘めている。しかし、その実現のためには、われわれは過去の重要な教訓に学ばなければならない。すなわち、RFP（提案依頼書）を出すだけでは十分ではない。スイッチでOpenFlowを有効にするだけでは十分ではない。プロプライエタリな拡張を調和させるロジックを大量に組み込んだ素晴らしい制御アプリケーションを作成するだけでは十分ではない。大手ベンダー1 社が推進するだけでは十分ではない。

　SDNの取り組みが大きな前進を果たすには、こうしたさまざまな要素がクリアされるとともに、実務家がSDNの導入に意欲的に取り組むことが必要になる。