マイクロサービスを (Ruby on Rails 以外の任意の言語) で書くことについての意見

この文書は、ある組織において、ある一つの Ruby on Rails で書かれたサービスの全部または一部を、(言語A) で書き直したい、という proposal に対して qsona が表明した意見の文を、一部手直ししたものです。このサービスは、現在担当しているチームとは別の人が初期実装をしたものであり、現在はまだ小規模ですが、今後新しいチームの手により発展していくもので、現在の規模のうちに要件や新しいチームメンバーに最適な言語で書き直すという選択は十分合理的です。また、この組織内のコードは、Ruby on Rails で書かれているものが大半であり、さらに組織としてマイクロサービスアーキテクチャの方向を目指している、という前提の上でお読みいただければと思います。もちろん文責は qsona 個人にあり、qsona の属する組織の意見とは関係ありません。

------------------------

個人的な意見を述べるならば、(言語A) は優れていると思うし、マイクロサービスとの相性もよく、新しくサービスを作るときの有力な選択肢として育てていきたい気持ちがあります。

一方で、僕は Ruby on Rails は我々 (現在所属している組織) のようなWebアプリケーションの8割の要件で最速最強だと今でも考えています。教育事業という特性上、そこまで厳しいパフォーマンス要件が求められることは多くありません (広告やソーシャルゲームなどの事業と比べれば明らか)。また、複雑なアルゴリズムをゴリゴリ書いていくようなシーンは存在しますが、ものすごく多いわけではないと思います。Rails はまさにそういう「一般的なWebサービス開発」に最適なフレームワークです。僕が入社してから開発した機能や、今後作る予定の機能を思い浮かべても、この辺まではやはりRailsが最強最速だと思っています。

なお、この「8割」とか「最速最強」の度合いについては、人によるところがあります。僕がこのように考えるようになるまでには、Railsを始めて1年半くらいはかかりました。ある程度変な失敗をせずにRailsを乗りこなせるようになったのだと思います。

Rails での開発を習得したあと、事情により Rails 以外の言語・フレームワークで開発することが何度かありました。最初は新しいものを触っているので楽しいのですが、やっていくにつれて、「これ Rails なら1行でかけるのに、なんでこんな毎度コード書かないといけないんだ?」みたいな気持ちが増幅してきます。しかし Rails が提供している機能と同等のものを自分で作るわけにもいかないので、人生の無駄を感じてモヤモヤしながらコードを書くことになりました。

(ちなみに僕はRailsを書いていても人生の無駄を感じることがあります。僕の場合はRSpec、特にrequest specで、それはRSpec力とエディタ力が低いから、思ったようにサッと3秒で書き終えられないからです)

上記の理由により、僕はやはり全体の開発(人・時間)の6割程度はRailsで行われているのが理想なのではないかと思っています。急に8割ではなく6割と弱気になりましたが、ここで後出しをすると、2割というのは仕様のボリュームにおける割合をなんとなく意図していて、Railsが最強にならない残りの2割の要件は、Railsが最強にならないゆえんでもありますが、仕様の見た目以上に、単純なデータ構造では実現が難しいとか、非機能要件が複雑だったりして、実装に時間かかりがちなので、少し調整してみました。実際に社内でも、重要かつ高いパフォーマンス要件が求められる機能について、Rails で書かれていたコードを一部作り直すプロジェクトでは、Rails ではなく Go やその他の言語を利用していますね。

さて、上に書いたように僕は、2割くらいの要件については、Railsが最強だとは思っておらず、むしろRails以外の選択肢を積極的に検討すべきだと思っています。いや、Rails魔神であれば全部Railsでいいとなるのかもしれませんが、まあでも、Railsを2年やっても10年やってもそこまでこの「2割」という感覚はあまり変わらないんじゃないかなと思います。

僕が推奨したいパターンは、いわゆる "メインサービス" のようなもの、チームごとのモノリス的なサービスを Rails で書き、そこから切り分けられるようなサービスを (言語A、あるいは Rails 以外の要件に適した言語・フレームワーク) で書いていくものです。

僕の経験上では、いくらマイクロサービスといっても、全ての機能を単一責任で良い粒度のサービスに切り出す、なんてことは幻想で、事業ごとに中心となるデータを持ったサービスが存在していて、ある程度そこに雑多に機能が集まるものだと思っています。一方で、肥大化しすぎる前にサービスの切り出しを考えたり、あるいは作る機能のサイズによっては最初から新規サービスで作り始めることも大事です。そのような、チームの中でも大事に育てたい重要なドメインに対して、(言語A) でサービスを作る、というのを良い選択肢として育てていけるのではないかと個人的には考えています。

さて、(このチームで新しく作ろうとしている機能) は、Rails 以外の選択肢がマッチする2割に入ると思っています。なので僕はサービス全部を (言語A) で書き換えるよりも、その機能だけをサービスに切り出し、 (言語A) で書くというのを勧めたいです。

------------------------

蛇足ですが、言語AはGo言語でした。Goは素晴らしい言語だと思いますが、僕はNode.jsが好きなので、このポジションに第三勢力としてNode.js+TypeScriptを推して戦わせていきたい所存です。