この記事は PagerDuty 社がElixirを採用したときのことについて語ったCees de Grootさんの Elixir at PagerDuty の翻訳です
ところどころ適当な訳になっていますが、その場合は編集リクエストなどもらえると幸いです。
PagerDutyが立ち上がった時、開発スピードがとても大切でした。
だから私達PagerDutyがRailsを最初に選んだことは驚くに値しないでしょう。
まもなく限界が来てScalaがスケールアップのため選ばれました。
しかし、RubyとScalaの間には言語自体の見た目やコミュニティが大切にするところなどで大きな差があり、つまるところ全く違ったものだったのです。
Rubyコミュニティの特にRailsサブコミュニティでは開発者の体験が何より大切にされています。
一方Scalaではより学術的で形式的なルーツがあり正しさが何より重視されていました。
この技術スタックの差異をどう埋めるかという問題に我々は悩まされていました。
RubyとScalaの差異が大きすぎるためScalaは私達の主要な問題に対応出来るか分かりませんでしたが、
Railsより優れたパフォーマンスとスケーラビリティを持つものが必要でした。
見通しもよく変更可能性も高いScalaのコードを書くのは難しく予想以上にスケールするのが困難なことが分かったため、初期のScalaコードベースはあまり気に入っていませんでした。
2015年に以上の問題を考えた時私は古いエクストリームプログラミング手法のSystem Metaphorに飛び込んでました。
私は通信業界で働いていましたが、PagerDutyをなんらかのスイッチのようなものと見なしてもそう間違いではないでしょう。
何かが入ってきて、何らかのルールとロジックを元にどこかに出て行きます。
どのようなアナロジーでもそれを元に想像することは出来ますが、私にとってはその動作するメタファーで十分でした。
通信業界のプログラミング言語といえばErlangといって間違いないでしょう。以前私はErlangを触ったことがありますが、あまりよくは思いませんでした。
仕事で関わったシステムにも適用出来そうなところはあまりありませんでした。
しかし今回はPrologをベースにしたような言語（大文字と小文字を混ぜたような言語）では適用可能な部分は残っているように思えました。
その考えは一旦保留して仕事に戻り、Elixirに取り組むまでの１ヶ月か２ヶ月後までは忘れていました。
そしてもう一度やり始めた時にはこれはなんておもしろいんだろう！誰かRuby/Railsに取り組んでいた人がやっていてErlang VMの上に構築されておりモダンで速くて高度でLisp/Schemeスタイルのマクロがあってユーザにとってよいものでした（博士課程の学生よりも）
いうまでもなくそれはすぐに私の「今年やるべき言語」リストのトップに躍り出て、ドキュメントを読み、サンプルのコードを試したりし始めました。
期待通り、いや期待以上に実行面でも開発スピードの面でもとてもよいパフォーマンスを発揮しました。
そして何より、Elixirで開発することはとても楽しかったのです。
Elixirを触るにつけ私はScalaが必要な箇所がなくなると思い、Ruby開発者にとってよいもので、速くなるしそしてより楽しいので、パイロット版のプロジェクトを探し始めたのです。
Elixirの導入
言語の導入はやっかいなものです。新しい言語の導入にはとてもコストがかかるため人々を説得するのはとても難しいものです。
矛盾するようですが、人を説得するためのいい方法は実際に始めてみて何が起こるかを観察することです。
なのでパイロット版にはミッションクリティカルで複雑だけど、古い言語ですぐにやり直せるくらいには十分限られたものである必要があります。
私達のチームではRails流の方法でKafkaにトランザクションを使用しつつやりとりしたいという時に使う機会がやってきました。
MySQLのトランザクションの重いRailsアプリの立ち上げを簡単にするために、Kafkaのメッセージのためのデータベースのテーブルを参照してKafkaに送るようなシステムが必要でした。
この方法がKafkaとやり取りする一番良い方法ではないと分かっていましたが、この方法はActiveRecordのトランザクションの一部としてKafkaメッセージをシンプルに処理することが出来ました。
これは既存の副作用のあるKafka周辺のコードやロールバックで何が起こるかということに関するコードを簡単に改善しました。
私達はこのプロジェクトをパイロット版として始めることにしました。これはとても重要な価値があり、最初に計画していたKafkaのメッセージはクリティカルな経路に存在していましたが、このプロジェクトは自己完結的でScalaに比べてプロジェクトが失敗した時にやり直すことが容易でした。
新しい言語に完全に最適なパイロット版のプロジェクトが見つかることはまれですが、今回はそのケースでした。
私達はしばしば本格的にやり始めて何週間か経ったあとチューニングやブラッシュアップが必要なサービスに当たりますが、Elixirではそういったことに出くわしたことはありません。
いうまでもなく、「いいね、Elixirで全部書きなおそう！」なんてことが会社全体で決まることはありませんが、これは最初の大事なステップです。
私たちはElixirを布教して他のチームが困っていることを手伝ったりしました。そしてゆっくりとではあるけど普及し始めました。
またElixirが好きな人を雇ったりし始め、トロントのElixirミートアップを開催するなどしてローカルコミュニティとの繋がりを持ちました。
ゆっくりではあるけど確実に色んなチームがElixirを採用し始めました。
今日では、Elixirで全て開発するチームや採用し始めたチームや「Elixirでやってみるよ」と言う機会を待っているチームが存在します。
Elixirはその売りの通り、まずちゃんと動作して、頑強なプラットフォームの上で動作し、コードは分かりやすくコミュニティはRailsの黒魔術的な態度に反する健全な意思を持っていて
そして、選択するのに十分なほど全体は小さくシンプルです。
今ではPagerDutyを流れるトラフィックがElixirのコードに触れられないということはほとんどありません。
今年はいくつかの重要な機能をElixirに置き換えるということをしますが私達はPagerDutyが処理するトラフィックをElixirが処理出来るということを確信しています。
最初のパイロット版からフルスケールのプロダクションに乗るまでは穏やかな流れでしたが、私達の内の何人かはいつかElixirで全て置き換えることが出来る日を望んでいます。
Elixirの記事を書くにあたってコミュニティのリーダーシップに助けられたことはいうまでもありません。
ElixirのインベンターJoseをはじめ、言語の文化にとても感謝しています。
Elixirは親切で最も素晴らしいコミュニティの一つでSlackやElixir ForumやStack OverflowやIRCなどで人々は誠実で親切で協力的です。
議論になることは珍しく進化は驚くほど速いです。それだけでもElixirをやる価値があります。