本稿は「OpenStack (２枚目） Advent Calendar 2014」12/5 分です
渋谷の寒空の中、ハチ公前で書いています。
今回は、\”OpenStack 4th birthday party, JP.\” でLT(のはずだったんだけど長かった)の内容について、ちょっと補足して説明したいと思います。
というのも、yosshy (@boot_vmlinuz) さんの 「OpenStack (２枚目） Advent Calendar 2014」12/1 の記事「ありのままで」は、非常に共感する部分があり、耳が痛い話でもあるからです。
OpenStackの仕様のままであることを守るということは、一般的に流通しているOpenStack client SDK (library)から自由に使えることであり、OpenStack準拠のClient Softwareとの互換性を保証するということになります。
では、OpenStackでIaaSサービス作っているのに、なぜ「互換API」になってしまうのでしょうか。
ポイントとしては、いくつかありますが、次のことが考えられます。
- IaaSビジネスとして、差別化したいという要求が、完全互換性対応に対して勝ってしまう場合
- a) カスタマイズした部分の仕様とOpenStack APIとの差異
- b) API以外の固定された商品仕様による
- 商品ラインナップとして、単にOpenStack API素のままだと自由すぎて、商品構成を崩してしまう場合
- 商品仕様、設計が先にあり、そこにOpenStackを当てはめている
- その仕様とお客の構成に合わないものはValidationでエラーにしないとだめ
- もともと、OpenStackの機能を提供するのが第一目的ではなく、IaaSを提供するのが目的
- OpenStackを提供することそのもののメリットを理解していない
- OpenStackのコンポーネントで使っていないものがある
- cinder, glance, swift, neutronなど
GMO Apps Cloudでは、なるべくOpenStackそのものに近づけようと努力してAPI Validationとか作りましたが、自由度をOpenStackそのものの自由度に比べると現敵的であることは否めません。
一番は、2に書いたように、「OpenStackそのものを提供することをメリットとして理解していない場合がほとんどであることは自明です。これは、日本の企業文化的にこの色が強い気がします。たとえば、ERPとか、カスタマイズせずにはいられないなど、そういう気質がつよいようなところですね。ほんらいなら、SaaSはもっと流行るべきなのに、日本はそこまでではないといったところはあるのではないでしょうか。
OpenStackそのものをIaaSとして提供することをメリットとして活かすには、IaaS企業はどういうことをすればよいのでしょうか。rackspaceやHP Helionなどのを参考にすると、わかりやすいのかもしれませんが
- OpenStackそのものの利用促進
- OpenStackでのPrivate Cloudの利用促進
- OpenStackのユーザーそのものの促進拡大
rackspaceはpublicだけではなく、専用サーバへのOpenStackをインストールしたPrivateの利用促進などをやっていますし、HP HelionはOpenStackを含めたインテグレーションをやっていたりします。
そのように、OpenStackそのものであることが、メリットとして言える発想で物を作れるようになれればなぁと思っています。
以下は、OpenStack 4th birthday party, JP. LT発表資料 \”the Way of the OpenStack API Dragon\” ~ GMO アプリクラウドAPI公開への道 ~ です。
