一人で書くときは。
個人で書くときとチームで書くときは良いコードの意味が違う。
2017/02/22
2017/02/19
第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会 に参加してきました
カテゴリ:
勉強会
オライリーが出版しているマイクロサービスアーキテクチャの読書会に参加してきました。
第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会
今回は6章です。
前提
この読書会は「本の内容をなぞって担当者が発表」→「ディスカッション」という形式をとっています。
6章の危険な匂い
6章のテーマは「マイクロサービスにおける」”デプロイ”に関してです。
が、まぁ本の内容をなぞって説明をしてもらって、話を聞いている間に6章を初見で読んで、これは嫌な予感がするなーと思いました。
その時の感想がこちら。
6章自体内容に対してページ数すくなすぎる感ある(本が)#MSA読書会
— やんくです (@yy_yank) 2017年2月18日
ドメインの境界がハッキリしていない時っていつ？とかそれは開発の度のタイミングからハッキリしてきてCIビルドとか分割できるの？とか
— やんくです (@yy_yank) 2017年2月18日
それ5章に書いてあるのかな#MSA読書会
他の章をきっちり読めてないっていうアレな状態なんですが、とにかくこの章はCI/CDというテーマに対して文書量が少ない。かつ、マイクロサービスアーキテクチャについてのCI/CDって意味での深掘りが無いです。
したがって、これはCI/CDの話に内容がすり替わってしまってマイクロサービスの文脈からは離れてしまうのではないかという懸念がありました。
グループディスカッション
結果的にやはり「マイクロサービス」の文脈というよりはCI/CDのディスカッションという意味あいが強くなってしまったんじゃないかなぁと思います。6章を語る上でおそらく、CI/CDというのは「前提」であって「本論」ではないんですが、どうしても自動化とかそっちの方にディスカッションの話題が行ってしまいがちでした。
本来ならマイクロサービスの文脈でCI/CDとはどうあるのが良いかというディスカッションになれば良かったんですが。
どっちかというと、CI/CDやってますよね？ やってます or やってませんみたいなレベルになってしまって少しもったい無かったかなと思います。
だって、自動化とか別に出来てても出来てなくても良いですけど。この本の主題は、マイクロサービスですから、マイクロサービスにおいて自動化はどうあるべきかに注力出来た方がホントは良いのです。
グループディスカッションで面白かったところ
結構座席的には面白い人が集まっている島だったんですが、マイクロサービスと組織論的な話が面白かったです。SIの文脈においてはマイクロサービスのサービス単位でチームが出来て縦割りになる。その際の政治的な問題とか。
はたまた「過剰なマイクロサービス」の話も面白かったです。CRUDでサービスが分かれるとか。Spring系のマイクロサービスの本とかであるんですって。まぁサンプルとしてはCRUDとかでサービス分けると分かりやすいんでしょうけど。実際やりすぎなんですよね。
でも技術書とかのサンプルがそうなっちゃってるから偉い人が「それが正しいんだ！こういう風にしよう！」みたいなことになったりするらしいです。
マイクロサービスの文脈でのデプロイ
マイクロサービスで考えてた時、本にも書いてありますが、CIとCDはあって当たり前かつ、必要不可欠な存在です。かつ、筆者の主張に従うと、1サービス、1リポジトリ、１ビルド(CI)という比率であるべきと言っています。
加えてローカルでの再現が難しい。「バランスを考えてローカルでも環境を作るべき」、と。
また低速のテスト、高速のテスト、UAT、本番などで環境を変える場合はそれぞれの環境の違いを考慮する必要がある、など。
正直このあたりはもっと本の中で掘り下げて欲しいところで、もっと色々ケーススタディがあると思うんですよね。
でもきっと筆者的にはこの章はこのページ数で収めないと、、、とかあるわけです。（はしょりたくないけど）その大事なことをはしょっているんだろうなと言う感じを僕としては強く受けました。
結果的にはツールに発散する
Docker、Ansible、Vagrant、Vaultなど結果的にCI/CDツールの詳解で終わってしまったような章でした。
うーん、ちょっともう少し説明する必要あるだろうみたいな気持ちでしたが。で、そういうツール郡を熟知していればそっちにとらわれなくて済んだんでしょうけど。。。。
なかなか読書会の皆がそんなの当たり前に知っているというわけではないんですよね。
学んだこと
という感じで、なんだかモヤモヤしてしまう章ではあってのですが、学ぶこともたくさんありました。
- 1サービスは1リポジトリであるべき
- 1サービスは1ビルドであるべき
- ブランチだけでなくマスターへのコントリビューションが常にあるべき
- 1ホストに対して1サービスであるべき
みたいな話です。このあたりはマイクロサービス的に大事な内容なんじゃないかなと思います。
といっても、全てがこれに当てはまるわけではないですが、理想的にはこの体系にしていくのが良いのかなという感じです。
例えば、1リポジトリに複数のサービスがある場合は、サービスの境界を意識せず、複数のサービスに対してコミットしてしまいがちとか。つまりリポジトリが同じであるためコーディングをしていると無意識にモノリシックになりやすいということを言っています。（本の中だとあっさり書いてますけど）
まとめ
ということで、（初参加で言うのもなんですが）ディスカッションとしては今回はもったい無かったのではないかと思います。CI/CDの話になっちゃったから。その話をするのであれば、CiICDの勉強会をやれば良いと思うわけです。
ただ、そうは言ってもマイクロサービスやCI/CDの周辺のメリットデメリットなどの再確認にもなったので良かったのかなと思います。
2017/02/13
2017/01/28
DDD、やるかどうかは置いといて「わかる！ドメイン駆動設計 」は読むと面白い
良い本なので感想とか僕の考えてることを書こうと思います！
「わかる！ ドメイン駆動設計～もちこちゃんの大冒険～」というTechBoosterさんが出している本です。
DDDだからページ数多いんだろうなというイメージだったんですが、60ページ。しかも1000円は安い。
買ってハズレでもちょっと1日御飯を控えめにするだけでなんとかなる（大体控えめにすることはない）。と思いPDF版を買いました。
こちらから買えますよ！まわしものじゃないけどｗ
https://techbooster.booth.pm/items/392260
2017/01/08
世田谷公園の近くに引っ越しました
カテゴリ:
ひとりごと
引っ越しました！世田谷公園には行ったことがありません！
渋谷、三軒茶屋、中目黒などそのあたりで飲む際にはお誘い下さい！！！
それ以外の場所で飲む場合も誘って下さい！
理由
電車通勤の消耗を抑えるために、というのが一番大きいです。
年々電車通勤する体力が減退している。。
徒歩通勤になるので電車とおさらばというのが嬉しいです。
あと、前の部屋は安くて広くていい部屋だったのですが、
川沿いの大通り沿いに面していて、走りたがりなバイクとか、スポーツカーなどのブォンブォン言う音、
救急車消防車のサイレンの音などに悩まされていたため引っ越したいという気持ちがあったことなどもあります。
引っ越しお考えの方は、大きな道沿いの部屋はやめといた方が良いです
— やんく������ (@yy_yank) 2017年1月8日
車や、特にバイクの音が結構うるさいです
引っ越しは勢いが大事です。会社から補助してもらえる部分もあって勢いがつきました。
まとめ
渋谷、三軒茶屋、中目黒などそのあたりで飲む際にはお誘い下さい！！！
それ以外の場所で飲む場合も誘って下さい！
登録:
投稿 (Atom)