http://gblogs.cisco.com/jp/2014/02/network-architecture9-orchestration/
河野さんのコラム。
オーケストレーションとは「自律的で多数の要素を有機的にまとめあげるための
レシピまたはプログラムをつくること」と定義できると思います。
インターネットを構成するノードは自律性を備えてる、
って言いきっちゃうのもアリかもなあ。
Cisco は伝統的に（?!）、管理システム系に弱いと言われていました。
実際そのとおりで（!!）、イノベーションは専らルータやスイッチに起こり、
管理システムはどうしても後手後手になります。
イノベーションはたしかにハードウェアの革新からおこるよなあ。
まずビジネス課題ありきで、そこから専らトップダウン的に技術に
落として行く、という方法に無理があるのではないか
ビジネス課題ありき、というアプローチは正しいんだけど、
時代遅れっぽくて、つまらんなあ、って思うのは、そういうことか!!
なんか腑に落ちたぞ。
では、オーケストレーションシステムに求められる特性は何でしょう。
私が最も重要視したいのはオープン性（Openness）、
そしてモジュラー性（Modularity）と拡張性（Extensibility）です。
たしかにそのへんは技術を評価するときに気にしてるかも。
個人的にはソフトウェア等を選定する際には、もうちょっとシンプルに
- モジュールが疎結合
- インターフェイス仕様がオープン
- シンプルシンプルシンプル!!
あたりを選定基準にしてるかなあ。
OpenStackなんかは、前の2つは満たしてるので悪くないとは思うんだけど、
なんかいまいちな臭いを感じるのは、パッケージングが下手だからだろうなあ。
パッケージングをどうするか、ってのも実は大事な気もする。
Ubuntuを好きなのもパッケージングがイケてるからだしね。
オーケストレーションについて議論するときに気をつけないといけないのは、
「オーケストレーションシステムは遍在し、かつ再帰する」ということです。
これは音楽をやってるとわりと実感することでもあるな。
アンサンブルの基本はデュエットで、そのユニットが大きくなって、
パートになって、それが組み合わさって、オーケストラ全体になる。
その都度どこに注目して議論をしているかを明確にしないと、
話が噛み合なくなります。
context重要ってことですな。
ETSI NFV 参照アーキテクチャの図および参照点は、
共通の想定を持って議論できる、という点で非常に有用です。
ある種のパターンランゲージとして機能するので、定義があるのは嬉しいかも。
でもパターンランゲージとして大事なcontextが記述されてないのは、
イケてないなあ、という気はしてる。