CALENDAR
S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< January 2019 >>
SPONSORED LINKS
ARCHIVES
CATEGORIES
MOBILE
qrcode
<< テンプレートカスタマイズとコンテスト結果 | main | 分散型IX?地域IX? >>
スポンサーサイト

一定期間更新がないため広告を表示しています

| - | | - | - |
routing or switching? ... software or hardware.
A.なんでルータとスイッチって分かれてるんですか?
B.全然違うじゃないですか
A.だってL3スイッチとミドルレンジ以上のルータってどっちもハードウェア転送しているじゃないですか
B.ああ、L3スイッチでしたか。でも違うじゃないですかルーティングプロトコルとかポート数とか
A.でもASICは共通だったりするでしょう?何が違うんですか?
B.何が違うんだろう…強いていえば収容できる回線に違いがあるかな?
A.それぐらいしか違わないと。
B.まあCat6500見た後7600みたり、NetIronとBigIronとか見たりすればねぇ。ベース一緒だし。

でもルーティング経路テーブルとかはソフトウェアベースだったりするのです。当たり前か。パケットスイッチング・ルーティングがハードウェアベースな訳で。

で、いつもCNET Japanで書いている梅田さんのBlogは、3日間なんとIP Infusionの、つまりGNU Zebra、ZebOSの石黒さんが書かれています。石黒さんがまとめて書かれた文章を読むのはこれがはじめてな気がするので興味深く読ませていただきました。
100万行のソフトの作り方(1)
100万行のソフトの作り方(2)
フリーソフトウェア/オープンソースをメインテナンスするコスト
の3エントリー。

100万行のソフトの作り方(1)
まさに、シリコンバレーの特徴は、「スピードとスケーラビリティ」に尽きると言っていいでしょう。これは開発スタイルだけではなく、シリコンバレーのスタートアップ企業そのものの特徴とも言えると思います。

なにしろ、どんどん新しい会社ができますし、プランが固まればすぐに開発がスタートします。「さぁ、作れ」「できたら売るぞ!」というノリです。会社も製品も、まったく何もないところから作るわけですから、全てがスクラッチ・ビルディング(scratch-building)に特化したものになっています。
そういうものなのですね…完全にスクラッチからに特化するという事はポーティングマネジメントとかは手薄なのだろうかとか妄想してしまいましたが。


100万行のソフトの作り方(2)
失敗と結果がでれば、早急に解散し、成功であれば、即時に人的リソースを集中させ、スケーラビリティをもとに、ゴールへともっていくのです。

市場に受け入れられなかった実験の人的リソースは、即座に別の実験プロジェクトへ編入されます。こうした人的可塑性は、限られた時間に数多くの実験を可能にし、他のどの場所よりも成功への確率を高めているのです。

なるほど。マネジメントあたりが死にそうになるなと思いますが、可塑性というかダイナミクスの桁外れな大きさが街の文脈に組み込まれている強さはオフショア型の開発スタイルも簡単に飲み込むほどのものなんですね。うーむ。そういうところでいろいろ出来ては潰れていくわけですか。恐ろしいなぁ(小心者


フリーソフトウェア/オープンソースをメインテナンスするコスト
そして、実は一番コストがかかるのは、開発者のコストを別にすると(たいていこれは無料で提供される)、おそらく知的所有権のチェックにまつわる弁護士費用を含めた人件費だと思う。
そうか!確かにそうだ。全然気づかなかった。なるほど。目から鱗が落ちるとはこういう事を指すわけですね。コードのIPについて完全に把握できていない産物はまず商業化できない。そういえばMySQLもそうだったな。取り入れる際に必ず契約結んで…とやるという。コードのチェックインと同時にチェックを行う仕組みを構築するのが一番楽なんでしょうか。


ということで読ませていただきました。面白かったです。個人的には水平分散型の開発モデルは、必ず人件費の壁にぶつかって外部へとばされる原因になると思っていますが。しかしそれでないと追いつかないものがつくられているわけで。

ところでZebOS SRSも今の環境だと使いにくいですよねそのまま純粋なソフトウェアルータとしては。
だって遅延が大きいですから。
たとえば、L3スイッチからひいてくるとExtreme Networksの新しいBD、BlackDiamond 10808なんかはスイッチング遅延が9μsですが、ソフトウェアベースではここまで縮められないわけで、特に遅延が気になる日本のFTTHを考慮に入れたりするとそのままでは使えないです。
が、実際にはルーティング処理自体ではなくルーティングデーモンとしてとかでは多くの採用実績があるわけで(パケットフォワーディングはハードウェアでも)。凄いですねぇ…
ということでIP Infusionが採用した伝統的なライセンス方式のビジネスモデルは合っていたんじゃないかなと思います。

そういえばルータ業界のLinuxを目指すXORP - CNET Japanて記事もありましたが、eXtensible Open Router Platformのサイト見るとBGP周りや管理周りを主に開発してるみたいな感じで、ローエンドというか企業向けとかエッジとかに向きそうな感じですね。Linksysや…って感じよりはもう少し上の市場。

あ、L3スイッチで躍進した「開発費の70%をIPv6につぎ込む」--アライドテレシスの差別化戦略で、10GbE対応モデルも今年中に出るそうですが、シャーシ型ですかね?

そういえばForce10のEシリーズがIPv6非対応なんだよなぁ…確か。ハードウェアルーティングで対応してくれませんかね。
逆にHitachiGR4000はMPLSがなぁ。
帯に短したすきに長し。おとなしくJuniperを使えという事か。なんだかなぁ。

明日こそはIXの話を…!
| Code+Net+PC | 23:36 | comments(0) | trackbacks(0) |
スポンサーサイト
| - | 23:36 | - | - |
コメント
コメントする









この記事のトラックバックURL
http://gpk.jugem.cc/trackback/71
トラックバック