5月にHerokuの新しいCeladon Cedarスタックが発表され、既存のRubyスタックに加えて、新たに2つの言語（Node.jsと、驚くべきことにClojure）が利用可能になった。InfoQでは、Herokuの共同創業者であるAdam Wiggins氏に話を聞く機会を得た。
Cedarは2010年Q1から開発されてきたもので、最初のHerokuプラットフォーム以上に力を入れて取り組んでいる。これは、HerokuチームがPaaSスタックを提供するだけでなく、Herokuスタック上に自らのインフラを次々と動かすことで、いろいろと経験し学習したことの集大成だ。
本記事は、その非常に興味深いお話についてまとめたものだ。
Adam氏は今年、Herokuにおける現在の開発を明確に示した2つのブログ記事を書いた。4月の最初の記事はEphemeralization（短命化）「より多くのことを、最終的には何もなしにできるまでより少ないことで実現する技術的進歩」（Wikipediaより）についてだった。Adam氏によると、これはPaaSプロバイダとしてのHerokuの目標のひとつだそうだ。クラウドOSを作るということは、ほかのOSと同様に、プロセス（サービス）がどこでどのように動いているか、どのようにリソース、スケジューリング、アップデート、可用性を扱うべきか、といった詳細からあなたを解放するということだ。したがって、あなたのアプリケーションの一部がクラウドのどこで動いているのか、どうやってスケールし、デプロイされ、マイグレートされるのか、あなたは気にしなくてよくなる。
興味深いことに、Herokuは自らのスタックからカスタムビルドのコンポーネントを徐々に削除して、これらをOSやライブラリレベルにある実績あるツールボックスで置き換えようとしている。これらはそれ自体で強力であり、さまざまに組み合おわせることでさらに力を発揮する。「Unixの美しさとは、切れ味のよいツールをいくつか組み合わせることで非常に多くのことをこなせることです。」
ひとつの例は、Webアプリケーションと関連workerのために、システムレベルサービスのOSメカニズムを再利用することだ。かなり長い期間、彼ら自身のスタックでdynoとworkerを提供してきたが、それらにはそれほど違いはなく、典型的なシステムレベルプロセスともあまり違いがないことがわかった。プロセス記述（Procfile）を解釈して、それらを好みのシステムレベルサービス（UbuntuのUpstartのようなもの）に変換するforemanのようなツールを使うと、Webアプリやworker、スケジュールされたプロセス、優先度の高い、低いプロセスといった特殊なプロセスなども簡単に定義できるようになる。
Procfileの例:
# clojure web: lein run -m demo.web # node.js web: node web.js # ruby web: bundle exec ruby web.rb -p $PORT fastworker: QUEUE=urgent bundle exec rake resque:work slowworker: QUEUE=* bundle exec rake resque:work clock: bundle exec clockwork clock.rb tweetscan: bundle exec ruby tweetscan.rb
Adam氏は、将来はサービス（現在はAdd-On-Providersによって外部提供されている）をこうしたプロセスとして実行できるようになるかもしれない、と述べた。（もしHTTPベースのものを動かしていないなら）異なるプロトコルを扱うところが課題になるだろう。
このプロセスアプローチを使うと、ほかの言語とのインテグレーションもずっと簡単になる。あなたは適切な実行環境（ClojureのためのJVMや、Node.jsのためのnodeなど) をプロセスとして実行するだけでよい。Herokuが新しい言語をCedarスタックに追加するのも簡単になる。現在プライベートベータにある言語もあり（例えば、Python）、それほど遠くない将来にリリースされるだろう。
自らのプロセスを動かすという強力なメカニズムが可能になると、その力を保護された環境にとどめなくてはならない。Herokuはそうした環境を作るのに、LXC（Linux Containers）とchrooted jailsを使ったサブバーチャライゼーションを利用している。
デプロイメントの仕組みにgitを使うのは、HerokuにおけるEphemeralizationのサインのひとつだ。特定のタスクに一番適した利用可能な、主にオープンソースのパワーツールを使うことで、独自のソリューションを開発、メンテナンスすることから解放される。
Herokuはオープンソースのツール（Ubuntu、PostgreSQL、Ruby、RabbitMQ、Memcached、Beanstalkd、Nginxなど）を使って作るだけでなく、オープンソースコミュニティにも還元している。また、Logplex、Doozer、Pulse、WAL-E、Tapsのようにインフラの一部をオープンソースとしてリリースしている。またHerokuの開発者も、Rails、Chef、RabbitMQ、Sinatra、Gem Bundler、Ring、RestClient、Beanstalkdのような多数のオープンソースプロジェクトを立ち上げたり、貢献している。
bundlerを使った依存関係管理やRuby on Railsのカスタムの中断のように、さらに上位レベルのライブラリでも同様のことが進行中だ。
Clojureの実行環境について、Adam氏はclojureアプリケーションのためのプロセスとして動いている平凡なOpenJDKにすぎないと指摘した。彼はまた、仮想マシンであるかどうかによらず、この方法を使えばどんな言語でも動かせるのだが、依然としてJVMには、実行プラットフォームの低レベルな詳細を（あまり）気にせず、その言語に集中できるという、言語設計における独特な優位性があると強調した。
Clojure自体については次のように述べている。
私たちは第三の公式サポート言語としてClojureを選びました。なぜなら、関数プログラミング言語やLispと同様、私たちのプラットフォームを使う開発者に対して、新しいタイプのアプリケーションや新しいユースケースの道を開くものだからです。私たち自身もClojureを気に入って使っていたので、これは自然な選択でした。私たちはClojureコミュニティにも参加しています。
Herokuの将来ビジョンは、1つの小さな（カスタム）カーネルがPaaS環境を提供しつつ、Herokuのサービスを徐々にそのスタックで動かしていくことだ。彼のウィッシュリストには、次のようなものがある。さらなる言語サポート、ログ分析/警告ファシリティの改良（一部log-drainsで利用可能）。もうひとつHerokuで見られる興味深いトピックは自動スケーリングのためのgems/librariesの出現だ。これは主に自動スケーリングのための基準とアクションを開発者が設定できるようにするといった問題を解決する難しいトピックだ。
Herokuの最終目標は、開発者がサーバ、ルータ、アプリケーションのデプロイメント、アップグレード、その他システム管理の詳細について考える必要なく、実際のドメインレベルのアプリケーション開発に集中できるようにすることだ。
モバイル開発について聞いてみると、Adam氏は多くのモバイル開発者がHerokuをバックエンドとして利用していると述べた。これはサービスの立ち上げと運用が非常に簡単であるためだ。Herokuでは、モバイル開発に具体的なフォーカスがあるわけではないが、Objective-Cについて尋ねると、彼は実に興味深いオプションだと答えた。
私たちはこの機会を利用して、Adam氏にHerokuの新しいチーフサイエンティストYukihiro "Matz" Matsumoto（まつもとゆきひろ）氏について聞いてみた。
Matzと一緒に仕事をすることに、本当にワクワクしています。彼は一番得意なこと、Rubyの改善を続けること、にフルタイムで働くことになるでしょう。Rubyの美学と使いやすさは、Herokuプラットフォームの構築に大きなインスピレーションを与えてくれます。私たちはRuby言語にお返しができることをうれしく思っています。
最後に、Salesforceによる買収について、これがHerokuの運営にどんな影響を与えるのか、彼が考えている現在および今後の相乗効果はどんなものかについて聞いてみた。明らかに、Herokuは極めて自立したまま、自らのスタッフを抱えたまま、自らのロードマップに基づいて運営されている。2つの企業の大きな相乗効果は、異なるユーザを引き付けることだ。Herokuは開発者にフォーカスしており、Salesforceはビジネスやマネジメントにフォーカスしている。個人的支持者にほかのプラットフォームがどんな機能を提供しているかを見せること、同時に、もっと簡単なインテグレーションを提供することが主な目的だ。
Adam氏に話しているとき、Amazon AWSで今年2度目の大規模障害が発生した。そこで基盤となるIaaS層の依存関係について話は飛んだ。Herokuの唯一のIaaSプロバイダとしてのAWS EC2との現在の依存関係について、特に企業としてのSalesforceのコンテキストで質問した。
Platform-as-a-Serviceはまだ完全に成熟しているわけではありません。低レベルの問題（例えば、ハードウェアエラー、ネットワークエラー）が高レベルの抽象化に影響を及ぼすと、これは抽象化の漏れです。数年前には定期的にこれを目にしました。現在はそう頻繁ではありませんが、依然として発生しています。中期的には、問題のない状態になっていくことを期待しています。
私たちは、ほか環境についても調査し、環境にとらわれないようプラットフォームを構築してきました。我々の規模のプロバイダにとって、現時点では、AWSがコスト、柔軟性、ロバスト性において最高のコンビネーションを提供しています。しかし、その他のオプションについても評価を続けています。もっとよいサービスを提供できるとなれば、ためらうことなく切り替えるつもりです。