とある人から「BlueMix で開発すると何かいいことあるの？」と聞かれたので、その答をこのブログエントリに書いておきます。 まあ答は BlueMix というよりも、CloudFoundry 全般に言える内容なんでしょうけど。
この質問者の意図は「オンプレミス環境や IaaS 環境でアプリ開発した場合と比較して、BlueMix だとどれだけ楽に作れるの？」ということだったようです。Java アプリ開発に特化した内容はないのですが、BlueMix に興味を持っている層の人は Java が比較的多いのかな、と思ったので、一応 Java 開発者向けの前提で書いてみます。
で、僕の答はシンプルで「特別変わらない。そしてそれが素晴らしい」です。
「変わらないことが素晴らしい」とは、少し分かりにくいかもしれません。多少くどい話になってしまいますが、これは BlueMix ではない他の PaaS と IaaS 間の移植を考えたケースと比較すると分かりやすいかもしれません。
例えば Google App Engine というグーグルの PaaS 環境があります。言語としては Java / Python / Go が使えて、データストアも KVS 型と SQL 型が選べて、メッセージング機能が含まれていたりする上に、負荷に合わせて勝手にスケールアウトしてくれます。しかもある制約の範囲内で利用する限りは無料！ というなかなか魅力的な環境です（個人的にも使ってます）。
ただ大きな悩みが１つ。他の環境とのポータビリティがほとんどないのでした。App Engine というパブリックな PaaS 環境内で使う前提であればこれは問題にならないのですが、（一部でも）自社サーバー環境で構築し直したいとか、サーバーはどこぞのクラウドのを使いたいとか、そういった要件にそのまま対応ができないのでした。言語として Java が使えると書きましたが、一般的な意味での Java アプリケーションとは少々違うもの（というか、App Engine 専用の Java アプリケーション）なのです。
で、「とはいえ同じ Java で作ったウェブアプリケーションなんだから、移植すればいいのでは？」という発想にたどり着きますが、これがまたややこしい話というか・・・ 確かに同じ言語を使ってはいますが、アプリケーションとして全然違うもの（Eclipse レベルの話をすると、最初に新規作成するプロジェクトからして別モノ）です。AppEngine 環境では専用の Base64 エンコーダー／デコーダーなど色々便利なライブラリが付属してはいるのは事実なんですが、それらを使ってしまうと移植時には全く別の手段を探すことになってしまうのでした。なお同じことが一般的な Java アプリケーションを App Engine 向けに（逆向きに）移植する場合でも同じことが言えます。
僕自身は過去に２度、App Engine プロジェクトを一般的な Java アプリケーションプロジェクトに移植した経験があります。（制約面では厳しい環境から緩い環境になるので）たしかに出来ないことではないし、同じ言語なので一部コピペが使えるのも事実ではあるのですが、やはりどうしても移植しきれなくて、一部機能だけは App Engine に残して併用する、という運用を今も続けていたりします。
これは App Engine が悪いというわけではなく、それだけ便利な環境を提供してくれていることの裏返しでもあるのですが、その便利さに頼ってしまうと後戻りができなくなってしまう、ということだと思っています。いわゆる「ベンダーロックイン」です。ないとは思っていますが、もしも Google が App Engine というサービスを止めてしまった場合、もうこのサービスは諦めるか、腹をくくって同じ機能をゼロから作り直す必要があると思っています。
同じことはセールスフォースの force.com プラットフォームにも言えます。一応 Java ライクな言語でアプリ開発ができる、ということになっていますが、これはセールスフォース独自の APEX という、ちょっと違う言語を使うことになります。実際に移植経験があるわけではないのですが、移植性とかの話になるとかなり厳しいのではないかな、と思っています。
そしてこれは App Engine や force.com に限ったことではなく、PaaS という OS やミドルウェアの概念を意識させないような便利なプラットフォームサービスを利用する以上は避けて通るのが難しいものだと思っていました。現に IaaS や SaaS などと比べて、その中間に位置する PaaS についてはどのベンダーも苦戦気味ですが、それはこういった「資産を移植しにくい」という背景も関係しているのだと思っています。
・・・なんか長くなってしまいました。話を冒頭に戻します。
私自身が BlueMix を使って感じた特徴の１つ、それは「オンプレミス環境や IaaS 環境とのポータビリティ」だと感じてます。オンプレミス用に作成したり、現にいま Amazon EC2 環境で動いている Java アプリケーションが、ほぼ変更なしにそのまま BlueMix で動かすことができる、ということです。もちろん例外的なケースもあるとは思いますが、一般的なウェブアプリケーションであれば、バイナリの WAR ファイルをほぼそのまま（ケース次第では１バイトも変更せずに） BlueMix / 各種 IaaS / オンプレミス環境全てにデプロイ出来る、ということも可能になります。
特に Java アプリケーションの（オンプレミスや IaaS 用の）資産が手元にある場合、BlueMix では WebSphere Application Server をベースとした（と思われる）"Liberty for JAVA" という Java アプリケーションサーバー環境を標準提供しています。この辺りは IBM の得意分野でもあるのでしょうが、我々開発者や開発ベンダーが持っている Java アプリケーション資産を動かすための準備は既に提供されていることになります。
冒頭で「（BlueMix は他の環境と比べて）特別変わらない、それが素晴らしい」と書いたのはまさにこのことです。オンプレミス／IaaS を選ぶお客様もいれば PaaS 環境を選択するお客様もいます。開発者はその２つの環境用に異なるアプリケーションモジュールを準備しておく必要があります。でもその PaaS が BlueMix や CloudFoundry であれば、その適応のための変更という作業はほぼ不要になります。もしかしたらそのまま動いてしまうかもしれません。これがメリットでなくて何？ということを言いたかったのでした。
そしてもう１つの特徴、それは「オープン」であることです。BlueMix はオープンソースの CloudFoundry V2 をベースに作られています。そのため万が一 IBM が BlueMix サービスを打ち切ることがあっても、PaaS 環境としての CloudFoundry に移して運用を続けることもできますし、自社に CloudFoundry 環境を構築してオンプレミスな PaaS 環境（？）の上で運用を続けるという選択肢もあります。更に CloudFoundry の活発なコミュニティの中で開発・提供されている便利なツールや資料など、コミュニティのパワーを借りることができることもオープン環境の強みだと思っています。
アプリケーションを開発する立場では複数環境用の移植メンテナンスがほぼ不要で、シングルソースのまま各種環境向けの提供できるようになります。 また運用する側も CloudFoundry コミュニティから提供される各種情報を便りに、場合によってはコスト比較をしながら運用環境や体制を変えていくこともできるようになります。少し前の PaaS では考えにくかったこんなことが今はできるようになっているのでした。
もちろんこれだけではないのですが、こういったオープン性を背景にしたことによる BlueMix のアドバンテージは計り知れないと感じています。繰り返しになりますが、オンプレ／IaaS 用に開発された Java アプリケーションの WAR ファイルがもしかしたらそのまま、そうでなくても最小限の変更で PaaS 上で動くかもしれない、というのはやはり魅力的です。今は本家 CloudFoundry も有償版しかないので、無料で CloudFoundry が試せる環境という意味でも BlueMix はなかなかおいしくて気にいってます。CloudFoundry や PaaS に興味を持っているアプリ開発者の方は、BlueMix という名の CloudFoundry を試してみて、手元のアプリがどれだけ動くのか、動作確認だけでも早めにやっておくといいかもしれません。今なら無料なので（笑）。
この質問者の意図は「オンプレミス環境や IaaS 環境でアプリ開発した場合と比較して、BlueMix だとどれだけ楽に作れるの？」ということだったようです。Java アプリ開発に特化した内容はないのですが、BlueMix に興味を持っている層の人は Java が比較的多いのかな、と思ったので、一応 Java 開発者向けの前提で書いてみます。
で、僕の答はシンプルで「特別変わらない。そしてそれが素晴らしい」です。
「変わらないことが素晴らしい」とは、少し分かりにくいかもしれません。多少くどい話になってしまいますが、これは BlueMix ではない他の PaaS と IaaS 間の移植を考えたケースと比較すると分かりやすいかもしれません。
例えば Google App Engine というグーグルの PaaS 環境があります。言語としては Java / Python / Go が使えて、データストアも KVS 型と SQL 型が選べて、メッセージング機能が含まれていたりする上に、負荷に合わせて勝手にスケールアウトしてくれます。しかもある制約の範囲内で利用する限りは無料！ というなかなか魅力的な環境です（個人的にも使ってます）。
ただ大きな悩みが１つ。他の環境とのポータビリティがほとんどないのでした。App Engine というパブリックな PaaS 環境内で使う前提であればこれは問題にならないのですが、（一部でも）自社サーバー環境で構築し直したいとか、サーバーはどこぞのクラウドのを使いたいとか、そういった要件にそのまま対応ができないのでした。言語として Java が使えると書きましたが、一般的な意味での Java アプリケーションとは少々違うもの（というか、App Engine 専用の Java アプリケーション）なのです。
で、「とはいえ同じ Java で作ったウェブアプリケーションなんだから、移植すればいいのでは？」という発想にたどり着きますが、これがまたややこしい話というか・・・ 確かに同じ言語を使ってはいますが、アプリケーションとして全然違うもの（Eclipse レベルの話をすると、最初に新規作成するプロジェクトからして別モノ）です。AppEngine 環境では専用の Base64 エンコーダー／デコーダーなど色々便利なライブラリが付属してはいるのは事実なんですが、それらを使ってしまうと移植時には全く別の手段を探すことになってしまうのでした。なお同じことが一般的な Java アプリケーションを App Engine 向けに（逆向きに）移植する場合でも同じことが言えます。
僕自身は過去に２度、App Engine プロジェクトを一般的な Java アプリケーションプロジェクトに移植した経験があります。（制約面では厳しい環境から緩い環境になるので）たしかに出来ないことではないし、同じ言語なので一部コピペが使えるのも事実ではあるのですが、やはりどうしても移植しきれなくて、一部機能だけは App Engine に残して併用する、という運用を今も続けていたりします。
これは App Engine が悪いというわけではなく、それだけ便利な環境を提供してくれていることの裏返しでもあるのですが、その便利さに頼ってしまうと後戻りができなくなってしまう、ということだと思っています。いわゆる「ベンダーロックイン」です。ないとは思っていますが、もしも Google が App Engine というサービスを止めてしまった場合、もうこのサービスは諦めるか、腹をくくって同じ機能をゼロから作り直す必要があると思っています。
同じことはセールスフォースの force.com プラットフォームにも言えます。一応 Java ライクな言語でアプリ開発ができる、ということになっていますが、これはセールスフォース独自の APEX という、ちょっと違う言語を使うことになります。実際に移植経験があるわけではないのですが、移植性とかの話になるとかなり厳しいのではないかな、と思っています。
そしてこれは App Engine や force.com に限ったことではなく、PaaS という OS やミドルウェアの概念を意識させないような便利なプラットフォームサービスを利用する以上は避けて通るのが難しいものだと思っていました。現に IaaS や SaaS などと比べて、その中間に位置する PaaS についてはどのベンダーも苦戦気味ですが、それはこういった「資産を移植しにくい」という背景も関係しているのだと思っています。
・・・なんか長くなってしまいました。話を冒頭に戻します。
私自身が BlueMix を使って感じた特徴の１つ、それは「オンプレミス環境や IaaS 環境とのポータビリティ」だと感じてます。オンプレミス用に作成したり、現にいま Amazon EC2 環境で動いている Java アプリケーションが、ほぼ変更なしにそのまま BlueMix で動かすことができる、ということです。もちろん例外的なケースもあるとは思いますが、一般的なウェブアプリケーションであれば、バイナリの WAR ファイルをほぼそのまま（ケース次第では１バイトも変更せずに） BlueMix / 各種 IaaS / オンプレミス環境全てにデプロイ出来る、ということも可能になります。
特に Java アプリケーションの（オンプレミスや IaaS 用の）資産が手元にある場合、BlueMix では WebSphere Application Server をベースとした（と思われる）"Liberty for JAVA" という Java アプリケーションサーバー環境を標準提供しています。この辺りは IBM の得意分野でもあるのでしょうが、我々開発者や開発ベンダーが持っている Java アプリケーション資産を動かすための準備は既に提供されていることになります。
冒頭で「（BlueMix は他の環境と比べて）特別変わらない、それが素晴らしい」と書いたのはまさにこのことです。オンプレミス／IaaS を選ぶお客様もいれば PaaS 環境を選択するお客様もいます。開発者はその２つの環境用に異なるアプリケーションモジュールを準備しておく必要があります。でもその PaaS が BlueMix や CloudFoundry であれば、その適応のための変更という作業はほぼ不要になります。もしかしたらそのまま動いてしまうかもしれません。これがメリットでなくて何？ということを言いたかったのでした。
そしてもう１つの特徴、それは「オープン」であることです。BlueMix はオープンソースの CloudFoundry V2 をベースに作られています。そのため万が一 IBM が BlueMix サービスを打ち切ることがあっても、PaaS 環境としての CloudFoundry に移して運用を続けることもできますし、自社に CloudFoundry 環境を構築してオンプレミスな PaaS 環境（？）の上で運用を続けるという選択肢もあります。更に CloudFoundry の活発なコミュニティの中で開発・提供されている便利なツールや資料など、コミュニティのパワーを借りることができることもオープン環境の強みだと思っています。
アプリケーションを開発する立場では複数環境用の移植メンテナンスがほぼ不要で、シングルソースのまま各種環境向けの提供できるようになります。 また運用する側も CloudFoundry コミュニティから提供される各種情報を便りに、場合によってはコスト比較をしながら運用環境や体制を変えていくこともできるようになります。少し前の PaaS では考えにくかったこんなことが今はできるようになっているのでした。
もちろんこれだけではないのですが、こういったオープン性を背景にしたことによる BlueMix のアドバンテージは計り知れないと感じています。繰り返しになりますが、オンプレ／IaaS 用に開発された Java アプリケーションの WAR ファイルがもしかしたらそのまま、そうでなくても最小限の変更で PaaS 上で動くかもしれない、というのはやはり魅力的です。今は本家 CloudFoundry も有償版しかないので、無料で CloudFoundry が試せる環境という意味でも BlueMix はなかなかおいしくて気にいってます。CloudFoundry や PaaS に興味を持っているアプリ開発者の方は、BlueMix という名の CloudFoundry を試してみて、手元のアプリがどれだけ動くのか、動作確認だけでも早めにやっておくといいかもしれません。今なら無料なので（笑）。
コメント