はじめてのにき

_ モノリシック vs マイクロサービス

定期的に「モノリシックなものをマイクロサービス化したらとんでもないことになった」という話を聞くように思う(つまりちょっと前も聞いた)。僕がよく聞くパターンは、モノリシックでわけわからんくなったものをマイクロサービス化したら、わけわからん RPC が飛びまくる、よりわけわからん、非効率なものになった、というもの

たぶんだけど、あまり理念とかを考えずに、マイクロサービス化することが目的化するとそうなるのかなーと。つまり、今あるモジュールの境界を是として、現在の境界で分割してしまう、っていう。これまぁ、元のコードを書いたのが自分じゃないと、モジュール境界のひきなおしとかって難しくて、しょうがない面もあると、「あんま理念を考えずマイクロサービス化しちゃった」人たちを弁護したい側面もある

つまりなんというか、本当に必要なのは、キラキラした「マイクロサービス化」ではなくて、泥くさいけど「とりあえずモノリシックなままでテストを可能にして、機能を破壊せずに、疎結合になるようにモジュール境界をひきなおす」ってことであるってケースが多そう。これが適切にできてしまうと、マイクロサービス化でも、別言語から使う API の提供でも、そういうのが単純作業に近くなってることが多いように思う

最初からマイクロサービスな開発をするってのは、手間がかかるってのはもちろんあるんだろうけど、ある程度疎結合なデザインを強制する、ギブス的な役割を果たす面がある気がしている。ただまあ本当は、そのためにマイクロサービス開発する必要は無くて、心がまえの問題で、モノリシックだろうが、「今は切れてないけど、やろうと思えば API 化もできますよ」みたいな気持ちで書くのがいいんだろうと思う。個人的には、 C++ でヘッダを小さくするとかは、そういうデザインを強制してくれて良いように思う。なんかヘッダに関数がいくつもある大きいクラスがあって、その関数をあれこれ呼んでいく、てのはつらいめ

最近 ONNX runtime の quantizer を読んでいると、これが極めて密結合でかなりひどい。 ONNX runtime の他の部分の印象は良かっただけに、ガッカリ感が強い。なんかまぁ MS ですらこんなコード書いちゃうんなら、なかなか「疎結合だいじ」てのは、意外と達成しにくいゴールなんだろうな、とか

(17:51)