Subscribed unsubscribe Subscribe Subscribe

SE Can't Code

A Tokyo based Software Engineer. Not System Engineer :(

MicroServiceで小さく作る.

友人らと1カ月くらい前からMicroServiceについて調べている。いろんな書籍を漁ったり、ネットに転がっている文献を読んではなんとも掴み難い雲のような概念だなという印象が強かった。

腑に落ちたのは、building MicroServicesを読んだ時だった。著者のSam Newmanは「Microservices は Conway の法則を味方につけるための舞台装置だ」と主張する。ソフトウェア開発をしている人なら一度は聞いたことのあるConwayの法則だ。

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations — M. Conway

小さいチームは小さいコードを生み出す。その組織構造はソフトウェアのアーキテクチャに反映され、プログラマーとしては当然コードが小さければ小さいほど良い。MicroServiceのようなモダンで堅牢なアーキテクチャはいろいろなことを楽にする。一方で、従来のソフトウェアは規模が大きくなるにつれて様々な依存関係と共に複雑性を作り上げていく傾向があるので、MicroServiceによりその複雑性が無くなるのは素直に嬉しい。とても大きな、それに複雑性を持った設計やコードを見るのはかなり辛いし、何よりもそれらをメンテナンスすることに対する労力は計り知れないからだ。

チームが小さければコミュニケーションが取りやすい、というのはすぐに理解出来るだろう。コードも同じでたとえば小さいコードを書いてそれぞれがAPIとして出力を最小単位でするのならば、それ以上に分かりやすいものはない。MicroServiceでのチームの規模についてAmazonが言及した有名な話で二つのピザチームがあるが、このように組織の構造がMicroServiceの開発と運用の成功可否を握ると言われている。

また、MicroServiceは4つの制約の元で行われる。

より小さい単位で設計されたアーキテクチャAPIのみでやり取りが行われることになり、その時大事な設計思想として、そのAPIを例外なく外部に公開出来るレベルに保つことが挙げられる。これは組織論的にも同じ事が言えるのではないだろうか。

複雑で巨大なアーキテクチャが存在した時、組織構造そのものから振り返ってみると良いかもしれない。ソフトウェアは人と組織が作り出すものであるため、そこの関係性はかなり深い。こうした構造を設計する人はプロジェクトマネージャになるのだろうか、だとするとプログラマーでないプロジェクトマネージャもMicroServiceを学ぶことはConwayの法則的に良いと思う。

願わくば、プロジェクトマネージャも自分で設計とプログラミングが出来て、こうしたアーキテクチャに精通しているエンジニアであってほしい。少なくともいずれ僕がマネージャになる時が来たならば、そういったマネージャ像を目指したい。

最後は脇道に逸れてしまったが、MicroServiceは面白そうなので是非どこかで導入してみたいと思った。

Remove all ads