どうも、最近Herokuの勉強をさぼりがちのおっぴーです。 そのため今回は、「試してみた！」という内容ではなく、主観が多く含まれる内容となっております。
さてHerokuの勉強をサボっているさなか、改訂版が出版されたAmazonWebServiceの『クラウドデザインパターン設計ガイド』を週末に読みました。
クラウドデザインパターンを読んでいる（かつ、操作もしてみる）と、
- Webサービスを運営するためのサーバー群の調達が早くできる
- サーバー、ネットワーク、DBなど各コンポーネントに拡張性がある
- IaaSのトップランナーとして進化し続けている
という点をしみじみと感じます。 実サービスでAWSを利用することが一般的になってきた今、いまさらな感想ですが、本当に便利なサービスだと感じます。
なにか新しいサービスを始めよう！と思った時に、まずはサービス規模を想定し、CPU、メモリ、ハードディスクの容量を予測し、消費電力を考え、回線使用量を見積もり、、、 それが終われば、各業者に相見積もりをとって、、、といったことを作業にまつわる悩みが減らせることは大きなメリットです。 さらにCloudDesignPatternというサーバー構成のパターン集は、ある特定の状況における十分に検証された解決策なので、「こんな問題に対処したいのだけど、どんなサーバー構成にすれば良のだろう？」と悩む時間を減らせます。
このことにより、「こんなサービスを始めよう！」と決めてから、「つくってみた！」までの期間を短くできます。意思決定から結果にいたるまでの時間が短くなることはビジネスのアジリティをあげることに直結します。
このように考えると、PaaS、Herokuの魅力とは、IaaSよりもさらにサービスの構想段階で悩むことを減らせる、というものだと感じています。 なぜならば、Herokuはサービスとして、いくつかのCloudDesignPatternに対応済みの環境を提供しているからです。
たとえば、CloudDesignPatternの基本パターンで紹介されている5つのパターンのうち、ScaleUpパターンやScaleOutパターンはもちろん、可用性のパターンで紹介されるMulti-Serverパターンは、提供されているコンソールから2,3クリックで完了してしまいます。 また、動的コンテンツの処理パータンであるScheduled Scale OutパターンもAPIと無料のAddOnであるHerokuSchedulerを組み合わせると簡単に設定できてしまいます。
くわえて、Ondemand Activationパターンのような機能は、One-Off Dynoが提供しています。
さらにさらに、CDPではありませんが、AWSをはじめとしてIaaSを利用することでサーバーの調達とセットアップの手軽になったことから実現できるようになったBlue-GreenDeployはどうでしょうか？ これもPrebootという仕組みやAPIからリリースをロールバックできることから、簡単に実行できます。
いやいや、「Herokuではこんなことができないでしょ？AWSではできるけど」という部分はもちろんあります。 たとえば、有償のAddOnを利用しないと、HerokuではAutoScaleができません。LogAggregationパターンについても、Papertrailやlogentriesなどの有償AddOnの利用が必要です。 さらに、メモリやCPUの選択肢はほとんどないといって良いと思います。たとえば、10GB以上のメモリが必要になるシステムを動かしたい！と考えるとHerokuは選択肢に入りません。 Herokuでスペックが一番良いPX Dynoでも6GBまでしかメモリの提供がされていないからです。
Herokuを選択することはCloudDesignPatternに対応済みの環境を享受できる一方で、AWSなどのIaaSにある自由度や選択肢が狭めることになるのは事実です。 一方で、強引に良い方向に考えると、そもそもできないことは悩む必要がなくなる(というより、これもやりたい、という点を切り捨てる）、という点でもWebアプリケーションをつうじてサービスを提供したい、というゴールに到達するための悩みが減らせる、といえます。
上述したように、IaaSやPaaSに感じるメリットは、サービスが提供する拡張性を前提として「開発の前の悩みがすくなくなる」ことから、ビジネスのアジリティをあげられるというです。 ですので、IaaS？PaaS？、AWS？Heroku?など、どちらを選べばよいの？ということをお悩みなら、「どれだけ最初に悩むことを減らしてWebアプリケーションを利用したサービスを提供したいか」を軸に検討してみるのはいかがでしょうか。
たとえば、Ruby on RailsやSpringBootのようなWebアプリケーションのフレームワークを用いて開発を行うようサービスは、まずはHerokuを利用することを考えて良いと思います。 もちろん、厳しい非機能要件があらかじめ想定される場合は、おすすめできない部分もありますが、アイデアベースのサービスをはじめたい、という場合ならオススメできます。
ちなみに、Herokuのプラットフォームの背後にはThe twelve-factor appという考え方があります。 もしも、Herokuを検討する場合は、現状の機能がなぜこうなっているのか、今後はどのように発展しそうか、という点の参考になりますので目を通しておくと良いと思います。
あと、AWSにはElastic BeanstalkというPaaSに類するサービスもありますね。 これとの比較はまたこんど。（できたらいいな）