PaaSのリリースアップ

機能もUIも少しずつ変化していくのがクラウドの常で、Google/AmazonなどのようなSaaS的なものでは、皆さんもなじんできたかとおもいます。ではPaaSではどうでしょう。ある時点のリリースのPaaSの上でユーザーなどが開発したアプリケーションがあるわけです。そのPaaS自身が自動的にリリースアップしていくとどういうことになるか考えてみました。

企業システムで言えば、例えば、ある時点でWindowsが勝手にリリースアップするようなものです。企業アプリケーションにとっては一大事です。今までの普通の企業アプリケーションであれば、新しいWindowsですべてのアプリケーションを稼動検証のテストをしてからWindowsをリリースアップするわけですが、クラウドで膨大な数のユーザーが存在すると、足並みをそろえてテストするなどとはいきません。何月何日からリリースアップしますと宣言し、自動的にリリースアップすることが起こりえます。

シングルテナントで、ユーザーごとに異なるリリースのPaaS環境を提供するという手段もありえるとは思いますが、クラウドベンダーにとっては規模が大きくなるとコストが見合わなくなるでしょう。複数のリリースのソフトウェアをメインテナンスできず、古いものをサポート中止にしている現在のソフトウェアベンダーを考えれば、ビジネスの利幅から考えて、クラウドベンダーのほうが複数リリースを常にサポートするのは、より困難だと推察できます。

では、ある日突然リリースのあがるPaaS上でのアプリケーションはどうすればいいのでしょう。おそらく技術的にはリリースアップ時には過去のアプリケーションがそのまま動くように、上位互換性に細心の注意を払らったリリースアップが、クラウドベンダーに求められるでしょう。

ただ今までのオンプレミスの環境では、企業は常に注意深くほぼすべてのアプリケーションをテストした上でリリースアップしてきたというのが今までの実態ではないでしょうか。これでは頻繁にリリースアップするPaaSは企業アプリケーションでは使えなくなってしまいます。

とはいえ、増え続けるオンプレミスの企業アプリケーションでも、ミドルウェアやOSのパッチの適用、リリースアップで、その上のアプリケーションのテスト作業を、現実的にコスト削減する方法が、いろいろな企業の実例でよく見かけるようになりました。それを簡単にまとめると、

- テストするアプリケーションをミッションクリティカルなものに限る
- テストするアプリケーションの機能を業務で利用する重要なものに絞り込む
- テストをやらず、段階的な展開、業務で試験利用、万一の対応検討など、何かおこってから対応する

要は、完全にすべてのアプリケーションが正しく動くことを確認してからリリースアップするのではなく、リスクを重要度により許容するとか、試験運用などでリスクを時間で分散させる、実際使われるものだけに絞ったり、万一動かなくても対応だけは考えておく、そして思い切ってテストしない、こういった考え方でかなりのコストダウンを計っているというものです。

もともと、いくらアプリケーションをテストしても所詮ソフトウェアですからバグはどこかに残ります。こういった現実的なやり方は、すべてがミッションクリティカルなアプリケーションではありませんから、広い範囲で効果的で、まさに勝手にリリースアップするPaaS環境に適用できる考え方だと思いました。変化が常になるクラウドでは、リリースアップでも、その変化をいかにコストを低くして受け入れるかが重要に思えます。

昔、PaaSのような開発環境をもつクライアント・サーバーのシステムを、あるお客様に展開したことがあります。その後、その環境がユーザーに評価され、その上でのアプリケーション数はうなぎのぼりに増加し、開発環境のリリースアップのたびに、すべてのアプリケーションのテストをきちんとやる姿を見たことがあります。そこまできちんとやらなくてもいいのではと思っていたのですが、案の定、数年後にお客様のCTOに、｢最初の導入よりリリースアップのほうがお金がかかったんだけど、どうしてくれるの。｣、と飲みながら責められたのを思い出しました。