MSのプラットフォーム戦略がどれだけ上手くいったか [プログラミング]
大掃除をしていたら、Visual Studio 6.0 Enterprize Editionの広告パンフレットが出てきた。む〜私がまだMS製品に入り浸っていた頃ですね。題名には上手くいったかって書いたけど、どんだけ失敗したかが焦点です。
掃除を久しぶりにしたけど、とりあえず空気清浄機を動かしているからいいかと思って、相当ほっぽらかしていた。たぶん5年弱…。それまで外側のフィルタしか掃除していなかったんだけど、それも一年に一回ぐらいしかやってなかった。中を開けてみたのだけれど、内部フィルタを開けると相当ホコリが貯まっていて、これでは浄化効率も相当下がっていたのだろうなと思われ。掃除機できれいにすると作動音がわりと大きくなった気がした。スループットが上がったからくぐもった音じゃなくなった感じ。
ええと、一昔前のMSの開発環境の事ね。今では.NETを経て、Azureでクラウドっていう事なんでしょうけども、正直他のサービスの後追い感は拭えない。更にビッグデータについてはほぼ完全に取り残されている感さえある。
ただ、僕が最近のMSの状態を知らないだけかもしれないけど、ビッグデータのようにたくさん仮想サーバのインスタンスを立てたりするには、MSのOSの値段は足枷でしかない。RHELの値段にしたって基本サポート料だけのようなもんだから、MSの独自開発された商業用OSの値段とは比べようも無い。とはいえ、企業のエンドユーザー的な使い勝手からすれば、GUIのサーバOSはそれなりに価値があると言えるし、今まで使ってきた手前、クライアントから刷新するならともかく、わざわざ変えていこうという手間はMS製品を買っておけば大体大丈夫という安心がある。でも、それは労力と金を交換しているわけであって、労力を惜しみすぎるとしっぺ返しを食らう可能性も高い。
さて、そのパンフレットには、Windows 2000をターゲットとする今後の開発環境、とある。2000年の頃のものなんだろうね（ざっくりてきとう）。従来のメインフレームやUNIXでのシステム構築では、1年単位の開発機関が必要だったけど、Webベースの分散アプリケーションで簡単に作ったり手直ししたり出来るのがいいんじゃないの、というコンセプトでやってたらしいです。Windows DNAと言ったらしいけど、あんまり聞き覚えが無い。
Windows Distributed interNet ApplicationでWindows DNA。クライアントサーバ＋Webアプリケーションサーバで、三階層モデルとしている。いまいち、切り分けが分からないのだが、クライアントがあって、データベースがあって、その間にビジネスロジックであるアプリケーションサーバあるといった感じ。
小さい規模ならデータベースとアプリケーションサーバは同じで良いけど、結局物理的にはストレージはFiberChannelやiSCSIで外出しにしているので、サーバのラックの中では別にはなっている。あえてストレージ側にサーバを立てなくても、物理的には別の場所にはなっているよね。とはいえ、同じラック内とかだろうけどさ。
今でもどうかは分からないけど、DBを別サーバって言うのはリソース的に恵まれているパターンじゃないかと思う。直結するよりかオーバーヘッドは出やすいだろうし、集約的にできるにしても、サーバ自体の死活管理とかいろいろやる事が増えちゃうだろうしね。そして、別マシンにする事で、全体の忙しさを一手に受ける事になるから、そこいらの処理の順序とかの管理も処理の重さによって分けないと面倒な事になりそうだし。まぁバッチ処理なら普通に並べていけばいいだけの話かもしれんけど、今は即時性を求められる処理も多いので、つぶしが利くかと言われれば微妙な所だろう。というか、そんなに厳しいタイミングを求められる処理は、その頃にはあんまりなかったか。
それに、元々ある資産を使ってWebベースに移行するって話になっていると思うから、新しくDBを構築するって話じゃないんだよね。そんでGUIでできるアジャイルってことを売りにしているみたい。もちろんその頃にAgileって言葉はなかったんだけどね。まぁ元々Visual Studio 6.0全体がGUI志向だったので、それは当然なんだろうな。Windows DNAで最終的に言いたい事は、クライアント、アプリケーション、DBの三層で作っていくからヨロシクね、という事だと思う。分散アプリケーションとか言ってるけど、アプリサーバとして切り離してるだけなんだよね。それ自身でDCOMを使わないとできないとかはほとんどないんだろう。実際DCOM使う仕事とかほとんどないに等しかったし。
VS6.0が出てからしばらく経っているので、Windows2000対応させるためにVisual Studio 6.0 Plus Packを入れるみたい。主な中身はWin2k Developer's Readiness Kit, Visual Studio Installer, COM+ Resource CD, MS Data Engine, MS SQL Server 7.0とか。やっぱり基本はDB関連ってことになりますよね、当然。
あ〜Visual J++ 6.0とかまだあるわ〜。MSがJavaを自社仕様にしようとしたので、当然の如くSUNが起こって訴訟に踏み切られたわけだけど、まだ性懲りもなく出したままですね。それで結局、.NETと一緒にC#をわざわざ作り出したわけだ。C#ってのはC++を元に作ったと嘯いていたけど、思いっきりJavaのマネやんと誰からもつっこまれていた。Javaの文法がC/C++に似ていたから同じになっちゃうのはともかくとして、実行環境が仮想マシンで、ネイティブなコンパイルとまでは行かないバイトコードを吐き出す点で全く同じ。Javaで出来ない事も出来るようになっていたが、それらはあえてJavaでは封印した部分だったりした。その仕様は一般的に使われたんだろうか。そういう自分の思いとは別に、わりとC#は普及したと思う。
おっと、Javaの話はまた別にしましょうか。COM+が使えるって書いてあるけど、DCOMとかとどういう違いがあるんだったっけ？ Visual InterDev 6.0ってあるけど、使った事ないから知らないや。あ、ASPの事？ なら知ってるｗ。スクリプトでビジネスロジックを書く事ができるよ、って書いてあるけど、結局それってコンパイルするかインタプリタで動かすかの違いだけじゃん。インターネットへ外向きに使って散々周りに迷惑をかけたIIS 4.0で動くのね。にしても、ASPはそれなりに量をやったけど、InterDevは使わなかった。普通にエディタで書いて、動くところに置いて動かしていただけだったと思う。教えられた時にInterDevのありかを教えてもらわなかっただけかもしれないけど、なくても何の問題もなかった。GUIなIDEってなんだかんだ言って重いからなぁ。
ASPといえば、IE6.0とセットになって動くから、その後の改修が大変だって話を結構聞いた。最近の、XPのサポート終了もそうだけど、仮想化で塩漬けNT4.0とかも影響して面倒らしい。新しい環境で動かすには、アプリケーションの仮想化とか、サーバの仮想化とか、いろいろあるらしいのだけれど、改めて同じ物を作るのにお金が出ないとかで悲惨らしい。そもそもXPからの移行を渋る経営者とか平気でいたらしいので、バックエンドの問題なんて考えてもらえないに違いない。
更に最悪な事に、ASPとかだとIE6対応なので、クライアントOSを変えるとIE6が使えないので、根本的にASPはダメだって話になる。知人の所ではIEの対応ができたって言ってたけど、どうやって対応したのかな。ブログに書かないから教えてって言ってみっかｗ。何にしても、一般の規格やプロトコルに従わない製品がどんなに危ないかが分かろうもの。
MSなんかにベンダーロックインされたらサポートも適当に済まされて終わるよね、そりゃ。だって現状のソフトウェアだって穴ぼこだらけなのが多いじゃん。さすがにOSはまともになってきてはいるものの、やっぱり全部お任せにできなくて、サードパーティーのソフトなどを使わなくてはならない事もしばしば。更に、そういうサードパーティーの仕事を潰すように（会社も潰すように）OSに機能を取り込むのはやめてほしい。最初から機能を付けてくれればいいのに、その機能頂き！ってのがOSアップデートの目玉になっているんだから手がつけられない。
しかし、この文章に書いてあるように、ASPでMS Transaction Serverを使ってトランザクションを使っていたシステムってあるんだろうか。トランザクション使うくらいのシステムってオンラインの勘定系とかじゃないの？ そしてMS SNA Serverを使ってメインフレームともつなげると書いてあるけど、やっぱ安定性がプアなWindowsとx86系のサーバの組み合わせとつなげるって、値段を見てもまともじゃない気がする。まさに木を竹を接ぐみたいな感じだよね。
COMをベースにしているからコンポーネントごとに別の言語を使っていても大丈夫、なんて言ってるけど、COMって積極的に使われなかった気がするね。結局、その延長の技術がActiveXだったりしたので、何となく危ない的な扱われ方をして、一般的に使われる事が少なかったのかもしれない。そういう状況があってこその.NETでどんな言語でも同じようなバイトコードを吐くようにしたんだろうけど、当時の言語の違いとかが関係なくするとか暴挙だよなと思った。
アプリケーションのライフサイクル、なんて事を言ってるんですが、できたら終りのASPの現状を見ていると破綻していますねｗ。MS Visual Modeler2.0なんていうのがあって、簡単なGUIでコンポーネントをつなぎあわせるだけで、設計ができると書いてあるけど、その操作だけじゃ物は作れなさそう。まぁそこまでの機能を持たせると、ろくなコードを吐かないわけの分からないものができるらしいので、あとで手で直せないようなヒドいものは使いたくない。
分散アプリケーションのパフォーマンス分析はVisual Studio Analyzerでやるらしいけど、ガントチャートで表示できるらしい。でも、貼ってあるスクリーンショットは、単なるスプレッドシートっぽいんだけど、ガントチャートぐらいでっち上げて作ればいいのにｗ。データベースを分析するには、Visual Database Toolsがあるらしい。書いてある感じからすると、OracleのEnterprize Managerみたいなもん？ ビジュアル化とか散々言ってるけど、まともに使えるものって少なくて、そこいらはVC++のウィザードとかと変わっていないなぁと思う。結局、使える範囲が狭すぎて、カスタマイズも効かないか、設定が面倒くさすぎて手でやった方が速いものが多かったりした。
Visual SourceSafeとか使った事もなかった。使い物になれば良かったんだけど、結局バージョンごとにフォルダにコピーして管理してたな。Subversionとかgit以降はきちんと使っていたけど、Visual SourceSafeは使えればGUIと統合されているだろうから面倒はないかな。Visual Component Managerというプログラマ用のグループウェアみたいなのもあるね。どんだけ大規模で作るつもりなんだよ、っていう気もせんでもないけど、MS Repository 2.0にストアしてみんなで使おう、みたいな感じらしい。Visual SourceSafeと機能がかぶってないか？という疑問はあるし、みんなに公開するのを分けていると考えれば問題ないかもしれないけど、果たしてそこまでのコラボ機能を使う前に、人同士のつながりをきちんと考えた方がいいと思うんだけど。そんなもん使ってたら、出来る人ならいいけど、出来ない人がヒドいプロダクトを垂れ流ししたりして問題になりそう。
デプロイがラクチンに出来るのはいいかもしれないね。Webアプリが普通になってきた頃からデプロイという話を良く聞くようになったけど、Web系のリリースにはみんな関わる事なんだろうね。多くは自動化によるメリットを挙げているんだと思うんだけど、それにきちんと合致するパターンてのはそんなになかったりするんだよね。システムを作るシステムに合わせるというのはあまり感心できないけど、Railsみたいな決め打ちが開発を楽にする事も多いので、そこいらへんはトレードオフなんだろう。
ずーっと前のVisual Studio 6.0の宣伝文句を見てきましたが、いろいろ上手くいってないし、いろいろ迷惑をかけられているなぁという気もしました。ASPではベンダーロックインの恐怖がどういうものかを身を以て知った気がするし、ソースで残っていても金がなかったら改変の話すら進まないってのもヒドい状況を見た気がしました。
そういえば2000年問題の時にもおんなじような事を言っていた気がする。2000年まで使わないだろうと思って開発していて、20年以上も同じシステムを使い続けてしまっていた、とか先読みが甘かったケースが多いですね。上手くいっているシステムには手を入れるな、という経験値が逆効果になっていたって事なんだろうけど、ソフトが古くなるってのはいろいろインパクトを与えるものなんだなと改めて思ったのでした。ドッグイヤーとかラットイヤーとかいわれる世界では何が生き残るんだか全然分からん。
掃除を久しぶりにしたけど、とりあえず空気清浄機を動かしているからいいかと思って、相当ほっぽらかしていた。たぶん5年弱…。それまで外側のフィルタしか掃除していなかったんだけど、それも一年に一回ぐらいしかやってなかった。中を開けてみたのだけれど、内部フィルタを開けると相当ホコリが貯まっていて、これでは浄化効率も相当下がっていたのだろうなと思われ。掃除機できれいにすると作動音がわりと大きくなった気がした。スループットが上がったからくぐもった音じゃなくなった感じ。
ええと、一昔前のMSの開発環境の事ね。今では.NETを経て、Azureでクラウドっていう事なんでしょうけども、正直他のサービスの後追い感は拭えない。更にビッグデータについてはほぼ完全に取り残されている感さえある。
ただ、僕が最近のMSの状態を知らないだけかもしれないけど、ビッグデータのようにたくさん仮想サーバのインスタンスを立てたりするには、MSのOSの値段は足枷でしかない。RHELの値段にしたって基本サポート料だけのようなもんだから、MSの独自開発された商業用OSの値段とは比べようも無い。とはいえ、企業のエンドユーザー的な使い勝手からすれば、GUIのサーバOSはそれなりに価値があると言えるし、今まで使ってきた手前、クライアントから刷新するならともかく、わざわざ変えていこうという手間はMS製品を買っておけば大体大丈夫という安心がある。でも、それは労力と金を交換しているわけであって、労力を惜しみすぎるとしっぺ返しを食らう可能性も高い。
さて、そのパンフレットには、Windows 2000をターゲットとする今後の開発環境、とある。2000年の頃のものなんだろうね（ざっくりてきとう）。従来のメインフレームやUNIXでのシステム構築では、1年単位の開発機関が必要だったけど、Webベースの分散アプリケーションで簡単に作ったり手直ししたり出来るのがいいんじゃないの、というコンセプトでやってたらしいです。Windows DNAと言ったらしいけど、あんまり聞き覚えが無い。
Windows Distributed interNet ApplicationでWindows DNA。クライアントサーバ＋Webアプリケーションサーバで、三階層モデルとしている。いまいち、切り分けが分からないのだが、クライアントがあって、データベースがあって、その間にビジネスロジックであるアプリケーションサーバあるといった感じ。
小さい規模ならデータベースとアプリケーションサーバは同じで良いけど、結局物理的にはストレージはFiberChannelやiSCSIで外出しにしているので、サーバのラックの中では別にはなっている。あえてストレージ側にサーバを立てなくても、物理的には別の場所にはなっているよね。とはいえ、同じラック内とかだろうけどさ。
今でもどうかは分からないけど、DBを別サーバって言うのはリソース的に恵まれているパターンじゃないかと思う。直結するよりかオーバーヘッドは出やすいだろうし、集約的にできるにしても、サーバ自体の死活管理とかいろいろやる事が増えちゃうだろうしね。そして、別マシンにする事で、全体の忙しさを一手に受ける事になるから、そこいらの処理の順序とかの管理も処理の重さによって分けないと面倒な事になりそうだし。まぁバッチ処理なら普通に並べていけばいいだけの話かもしれんけど、今は即時性を求められる処理も多いので、つぶしが利くかと言われれば微妙な所だろう。というか、そんなに厳しいタイミングを求められる処理は、その頃にはあんまりなかったか。
それに、元々ある資産を使ってWebベースに移行するって話になっていると思うから、新しくDBを構築するって話じゃないんだよね。そんでGUIでできるアジャイルってことを売りにしているみたい。もちろんその頃にAgileって言葉はなかったんだけどね。まぁ元々Visual Studio 6.0全体がGUI志向だったので、それは当然なんだろうな。Windows DNAで最終的に言いたい事は、クライアント、アプリケーション、DBの三層で作っていくからヨロシクね、という事だと思う。分散アプリケーションとか言ってるけど、アプリサーバとして切り離してるだけなんだよね。それ自身でDCOMを使わないとできないとかはほとんどないんだろう。実際DCOM使う仕事とかほとんどないに等しかったし。
VS6.0が出てからしばらく経っているので、Windows2000対応させるためにVisual Studio 6.0 Plus Packを入れるみたい。主な中身はWin2k Developer's Readiness Kit, Visual Studio Installer, COM+ Resource CD, MS Data Engine, MS SQL Server 7.0とか。やっぱり基本はDB関連ってことになりますよね、当然。
あ〜Visual J++ 6.0とかまだあるわ〜。MSがJavaを自社仕様にしようとしたので、当然の如くSUNが起こって訴訟に踏み切られたわけだけど、まだ性懲りもなく出したままですね。それで結局、.NETと一緒にC#をわざわざ作り出したわけだ。C#ってのはC++を元に作ったと嘯いていたけど、思いっきりJavaのマネやんと誰からもつっこまれていた。Javaの文法がC/C++に似ていたから同じになっちゃうのはともかくとして、実行環境が仮想マシンで、ネイティブなコンパイルとまでは行かないバイトコードを吐き出す点で全く同じ。Javaで出来ない事も出来るようになっていたが、それらはあえてJavaでは封印した部分だったりした。その仕様は一般的に使われたんだろうか。そういう自分の思いとは別に、わりとC#は普及したと思う。
おっと、Javaの話はまた別にしましょうか。COM+が使えるって書いてあるけど、DCOMとかとどういう違いがあるんだったっけ？ Visual InterDev 6.0ってあるけど、使った事ないから知らないや。あ、ASPの事？ なら知ってるｗ。スクリプトでビジネスロジックを書く事ができるよ、って書いてあるけど、結局それってコンパイルするかインタプリタで動かすかの違いだけじゃん。インターネットへ外向きに使って散々周りに迷惑をかけたIIS 4.0で動くのね。にしても、ASPはそれなりに量をやったけど、InterDevは使わなかった。普通にエディタで書いて、動くところに置いて動かしていただけだったと思う。教えられた時にInterDevのありかを教えてもらわなかっただけかもしれないけど、なくても何の問題もなかった。GUIなIDEってなんだかんだ言って重いからなぁ。
ASPといえば、IE6.0とセットになって動くから、その後の改修が大変だって話を結構聞いた。最近の、XPのサポート終了もそうだけど、仮想化で塩漬けNT4.0とかも影響して面倒らしい。新しい環境で動かすには、アプリケーションの仮想化とか、サーバの仮想化とか、いろいろあるらしいのだけれど、改めて同じ物を作るのにお金が出ないとかで悲惨らしい。そもそもXPからの移行を渋る経営者とか平気でいたらしいので、バックエンドの問題なんて考えてもらえないに違いない。
更に最悪な事に、ASPとかだとIE6対応なので、クライアントOSを変えるとIE6が使えないので、根本的にASPはダメだって話になる。知人の所ではIEの対応ができたって言ってたけど、どうやって対応したのかな。ブログに書かないから教えてって言ってみっかｗ。何にしても、一般の規格やプロトコルに従わない製品がどんなに危ないかが分かろうもの。
MSなんかにベンダーロックインされたらサポートも適当に済まされて終わるよね、そりゃ。だって現状のソフトウェアだって穴ぼこだらけなのが多いじゃん。さすがにOSはまともになってきてはいるものの、やっぱり全部お任せにできなくて、サードパーティーのソフトなどを使わなくてはならない事もしばしば。更に、そういうサードパーティーの仕事を潰すように（会社も潰すように）OSに機能を取り込むのはやめてほしい。最初から機能を付けてくれればいいのに、その機能頂き！ってのがOSアップデートの目玉になっているんだから手がつけられない。
しかし、この文章に書いてあるように、ASPでMS Transaction Serverを使ってトランザクションを使っていたシステムってあるんだろうか。トランザクション使うくらいのシステムってオンラインの勘定系とかじゃないの？ そしてMS SNA Serverを使ってメインフレームともつなげると書いてあるけど、やっぱ安定性がプアなWindowsとx86系のサーバの組み合わせとつなげるって、値段を見てもまともじゃない気がする。まさに木を竹を接ぐみたいな感じだよね。
COMをベースにしているからコンポーネントごとに別の言語を使っていても大丈夫、なんて言ってるけど、COMって積極的に使われなかった気がするね。結局、その延長の技術がActiveXだったりしたので、何となく危ない的な扱われ方をして、一般的に使われる事が少なかったのかもしれない。そういう状況があってこその.NETでどんな言語でも同じようなバイトコードを吐くようにしたんだろうけど、当時の言語の違いとかが関係なくするとか暴挙だよなと思った。
アプリケーションのライフサイクル、なんて事を言ってるんですが、できたら終りのASPの現状を見ていると破綻していますねｗ。MS Visual Modeler2.0なんていうのがあって、簡単なGUIでコンポーネントをつなぎあわせるだけで、設計ができると書いてあるけど、その操作だけじゃ物は作れなさそう。まぁそこまでの機能を持たせると、ろくなコードを吐かないわけの分からないものができるらしいので、あとで手で直せないようなヒドいものは使いたくない。
分散アプリケーションのパフォーマンス分析はVisual Studio Analyzerでやるらしいけど、ガントチャートで表示できるらしい。でも、貼ってあるスクリーンショットは、単なるスプレッドシートっぽいんだけど、ガントチャートぐらいでっち上げて作ればいいのにｗ。データベースを分析するには、Visual Database Toolsがあるらしい。書いてある感じからすると、OracleのEnterprize Managerみたいなもん？ ビジュアル化とか散々言ってるけど、まともに使えるものって少なくて、そこいらはVC++のウィザードとかと変わっていないなぁと思う。結局、使える範囲が狭すぎて、カスタマイズも効かないか、設定が面倒くさすぎて手でやった方が速いものが多かったりした。
Visual SourceSafeとか使った事もなかった。使い物になれば良かったんだけど、結局バージョンごとにフォルダにコピーして管理してたな。Subversionとかgit以降はきちんと使っていたけど、Visual SourceSafeは使えればGUIと統合されているだろうから面倒はないかな。Visual Component Managerというプログラマ用のグループウェアみたいなのもあるね。どんだけ大規模で作るつもりなんだよ、っていう気もせんでもないけど、MS Repository 2.0にストアしてみんなで使おう、みたいな感じらしい。Visual SourceSafeと機能がかぶってないか？という疑問はあるし、みんなに公開するのを分けていると考えれば問題ないかもしれないけど、果たしてそこまでのコラボ機能を使う前に、人同士のつながりをきちんと考えた方がいいと思うんだけど。そんなもん使ってたら、出来る人ならいいけど、出来ない人がヒドいプロダクトを垂れ流ししたりして問題になりそう。
デプロイがラクチンに出来るのはいいかもしれないね。Webアプリが普通になってきた頃からデプロイという話を良く聞くようになったけど、Web系のリリースにはみんな関わる事なんだろうね。多くは自動化によるメリットを挙げているんだと思うんだけど、それにきちんと合致するパターンてのはそんなになかったりするんだよね。システムを作るシステムに合わせるというのはあまり感心できないけど、Railsみたいな決め打ちが開発を楽にする事も多いので、そこいらへんはトレードオフなんだろう。
ずーっと前のVisual Studio 6.0の宣伝文句を見てきましたが、いろいろ上手くいってないし、いろいろ迷惑をかけられているなぁという気もしました。ASPではベンダーロックインの恐怖がどういうものかを身を以て知った気がするし、ソースで残っていても金がなかったら改変の話すら進まないってのもヒドい状況を見た気がしました。
そういえば2000年問題の時にもおんなじような事を言っていた気がする。2000年まで使わないだろうと思って開発していて、20年以上も同じシステムを使い続けてしまっていた、とか先読みが甘かったケースが多いですね。上手くいっているシステムには手を入れるな、という経験値が逆効果になっていたって事なんだろうけど、ソフトが古くなるってのはいろいろインパクトを与えるものなんだなと改めて思ったのでした。ドッグイヤーとかラットイヤーとかいわれる世界では何が生き残るんだか全然分からん。
コメント 0