スケールアウトを阻むライセンス

スケールアウトに適すのは、ソフトウェアを使うときにライセンス課金という壁を立ちはだからせず、顧客の要求にとにかく答える製品です。結論をまず書きました。

世の中スケールアウトバンザイという事ばかりではない。

なにしろそもそもスケールアウトできない実装なんていくらでもある。ひどい例だとお思いでしょうが、スケールアウトに向いた製品といわれるKVSをCookie保持に使っているのに中間状態を半端に保持してしまうアプリ実装になっていて、入り口のロードバランサでStickness保持なんてこともある。

とはいえ、技術的に解決できることはいい。根が深いのはライセンスによるもの。

スケールアウトに向かないライセンスはこんなところだろう。

• 起動するサーバのMACアドレスを予め決めておくもの。
• サーバが起動する毎に一時鍵が発行され、それをライセンス元に送って認証するもの。認証に数時間から数日かかるもの。
• サーバの起動時に様々な関係のない情報をスキャンし、ちょっとでも変わっていると新規ライセンスを必要とするもの。
• 動作するサーバをそもそも決めてしまう（サーバにメーカーでインストールして出荷するアプライアンスになっているが、その中身はx86どころがESXiだったりHyperVだったりするもの）

「スケールアウトで何とかしよう」という考えは時間の余裕がないときにいかんなく発揮される。目の前の問題を「スケールアウトで何とかしよう」と思って、なんとかできそうなのに、ライセンス理由でスケールアウトできない、あるいは時間がかかるものは全てダメだろう。

まあ、どんなライセンスにしようと、その権利を持っている人が自由に決めればいいといえばいい。

一方で、次の通りスケールアウトと馴染みのいいライセンスと比べると、使われなくなっても仕方がないだろう。

• 自由に使っていいライセンス。例えばDebian．
• AWSの課金に上乗せされて時間単位でライセンス料金を徴収するもの。たとえばRHELやMS Windows.
• 必要なライセンス数の数え方がどんぶり勘定なもの。

いろいろあるのだがまとめると、こんな事だと思う。

• スケールアウトに適さないのは、ソフトウェアを使う前に課金し、課金が完了しないと動作しない（あるいは使ってはいけないとされている）製品。
• スケールアウトに適すのは、ソフトウェアを使うときにライセンス課金という壁を立ちはだからせず、顧客の要求にとにかく答える製品。

ともかくまず全力でお客様と一緒に問題を解決しておいて、あとから金いただくというのは信頼関係や保証してくれるクレジットカードというセーフネットがあってこそのものとも言えますが。