Message Passing

私が仕事で開発している firecracker-containerd は、

• 自分たちのチームが開発している Firecracker Go SDK
• 同じ会社だけど時差もある別チームの開発している Firecracker
• Cloud Native Computing Foundation の containerd
• Open Container Initiative の runc

を使っていて、これらは当然のように別のレポジトリに入っている。オープンソースでない社内のコードも、2019年の Interconnecting Code Workshop のショートペーパー、The Issue Of Source Code Repository Management In Large Enterprises で触れられているように、基本的にはモノレポではない。

というわけで、私はモノレポをやったことがない。モノレポの利点とされるものについては、Envoy の Matt Klein が Monorepos: Please don’t! で細かく反論していて、それならこのままやり過ごしてもいいかなあと思っている。

検索なんてすぐに git grep には任せられなくなって、どうせインデックスが必要になる。コードレビューは空気を読まずによそのチームに出せばいい。インフラやツールの統一はバージョン管理システムの仕事じゃない。別にモノレポじゃなくていいんじゃない?

ビルドナンバーのない世界

Matt Klein もふれているけど「このリビジョンから API 変更するけど、呼び出してる場所も全部変えといたから、あとは心配しないでね」というのは、全体をリンクしてビルドナンバーがついたバイナリがリリースされるようなソフトウェアではできるだろうけど、マイクロサービスで、サービスの境界をまたぐ変更だったりすると、途端に難しくなる。

The Amazon Builders' Library にある Automating safe, hands-off deployments で詳しく説明されているけれど、会社での本番環境へのデプロイは、安全を確保しつつ、継続的・自動的に行われるようになっている。達成度にはチームによってばらつきがあったりもするけれど、目指すべきゴールはここ。

結果として何がおこるかというと、あるサービスのデプロイと、それを呼び出す別のサービスのデプロイを揃えるのは難しくなる。最初のほうのリージョンでは揃うかもしれないけれど、後半のリージョンではそろわないかもしれない。揃っていたと思ったら、どこかで片側だけロールバックされるかもしれない。ひとつのリージョン、ひとつのロードバランサーだけをみても、デプロイ中は新旧のバージョンが混在することもある。

こうなってくると、全てのサービスがひとつのレポジトリに入っていて、アトミックな変更が出来たとしても、そのアトミシティはデプロイ中にバラバラになってしまう。我々の世界にビルドナンバーは存在しないのだ。

もしかしたら Google や Facebook には、そういうアトミシティを担保する何かハイテクがあるのかもしれないけれど、でもまあ、無くてもいいハイテクは無いままでもいいかなあ。