シード期だけどマイクロサービスをやっている

ここに書かれていること：最初からマイクロサービス化するのもいいよっていう話。うちはシード期だけど開発スタイルやプロダクト性質的には分散型のほうが合っていて理由はこうだよという話。

ズボラ旅というサービスをリリースしてから1ヶ月間、毎日毎日ユーザー対応をしていたのだけど、徐々にプロダクト開発に時間を使えるようになってきました。個人的な時間の使い方としては、ユーザー対応自体は引き続きやっていて、時間を区切って開発業務をやっている状態。

で、そこで例えば決済まわり・観光庁ガイドラインに沿うためのページ・チャット管理画面の一部とかをマイクロサービス化して作っています。

「シード期にマイクロサービスってぶっちゃけそんなリソースなくない？」という指摘はまぁ一理あって、弊社もエンジニアは現在自分いれて2人だけで、ぶっちゃけすでにあるアプリケーションの上に乗せるほうがこれまでのマインドセットのまま作れるとか、動作環境準備しなくていいなどの面では早いです。じゃあなんでマイクロサービス化してんだよという話。

理由はざっくりまとめるとリソースの集中投下・知見の蓄積・俯瞰で考える習慣づけ・実はそんなに大変じゃないこと。

うちは代表も含めマーケ寄りの会社で、プレスリリースからまず作るというAmazon流のWorking-Backwards方式をメインにプロダクトを作っています。「こういうリリースを出すと1番ユーザーに響きそうだからそこに向けて必要なものを作っていこう」という方法になります。超極端に言えば毎回新しいプロダクトを作っている感覚が近い。そういう場合は、小さく作ってすぐに捨てたりくっつけたりできるようにしたくなります。サービスが分かれていると他を無視してそこだけにリソースを集中投下できます。

知見の蓄積について、マイクロサービス化にあたって、それぞれのサービスの特性をみて適していると思う言語やデザインパターンで作っています。良いと思うものは試して社内でフィードバックとして蓄積するべきだと思うから。こうして外に向けて発信できる材料も増えます。採用的にも、「うちはRubyの会社だから」「うちはJavaの会社だから」といって得意不得意を無視して無理やり既存サービスに押し込むようなのは、ただでさえ採用力の低い状況なのにさらに採用できる人材の幅も狭くなるだろうという思いがあります。「新しくやりたいことがあるのにできない」という理由でうちで働くのを諦めてしまう人がなるべく生まれないようにしたい。

俯瞰で考える習慣。リリースごとに歴史的経緯や制限を一旦置いて何が1番理想かを考えやすくなる。「これってなんで必要なんだっけ」みたいなマクロの視点で見やすくなります。営利組織としてはお金を生まない領域に全力で突っ込むのは絶対に避けないといけなくて、各人が広い視点で物事を見られると話が早いです。

シード期なのもあって、マイクロサービス化にあたるコストって実はそんなに大きくないです。動作環境整備は慣れればすぐだし、シード期なのでユーザーも数千人が常時接続とかないし、万が一失敗しても困る人は少ないので、大きなユーザーを抱えているプロダクトよりもやりやすいです。ということでリリース当初からDocker化・Kubernetesクラスタ化をして、マイクロサービス開発をしやすい土壌を作ってあります。これまで巨大なモノリスでなんとか動いているスタートアップをたくさん見てきて、最初から小さく分けて作っておくのでもそこまで工数変わらないんじゃないかという思いがありました。小さいので開発環境構築もコマンド1つ叩けば数分で終わるし、ちょっとした変更なら誰でもすぐにできる。マイクロサービスだろうがなんだろうが常時リソースは不足しているので、すぐ動いて誰でも変更できるというのは超強みになります。

具体的にどういう構成なのかというと、例えば昨年12月にリリースしたものはES2017+Rails5.2でできています。理由は比較的単純なWebアプリケーションだったのと、当時唯一のエンジニアであった私がRailsに慣れていることから。今作っているものの1つは大きいのでReactでしっかりめに、もう1つは小さいので簡単にVue+Golangで作っています。今後たぶんバックエンド同士のやりとりにはgRPCを入れるでしょう。

採用に関すること・サービス開発に関することなどでなにか気になった方がいましたらTwitterやFacebookでメッセください。