2017/02/22 このエントリーをはてなブックマークに追加 はてなブックマーク - オレオレ実装で良いと思う

オレオレ実装で良いと思う

カテゴリ: ,


一人で書くときは。


個人で書くときとチームで書くときは良いコードの意味が違う。



2017/02/19 このエントリーをはてなブックマークに追加 はてなブックマーク - 第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会 に参加してきました

第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会 に参加してきました

カテゴリ:



オライリーが出版しているマイクロサービスアーキテクチャの読書会に参加してきました。

第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会

今回は6章です。


この読書会は「本の内容をなぞって担当者が発表」→「ディスカッション」という形式をとっています。


6章のテーマは「マイクロサービスにおける」”デプロイ”に関してです。
が、まぁ本の内容をなぞって説明をしてもらって、話を聞いている間に6章を初見で読んで、これは嫌な予感がするなーと思いました。

その時の感想がこちら。

他の章をきっちり読めてないっていうアレな状態なんですが、とにかくこの章はCI/CDというテーマに対して文書量が少ない。かつ、マイクロサービスアーキテクチャについてのCI/CDって意味での深掘りが無いです。

したがって、これはCI/CDの話に内容がすり替わってしまってマイクロサービスの文脈からは離れてしまうのではないかという懸念がありました。


結果的にやはり「マイクロサービス」の文脈というよりはCI/CDのディスカッションという意味あいが強くなってしまったんじゃないかなぁと思います。6章を語る上でおそらく、CI/CDというのは「前提」であって「本論」ではないんですが、どうしても自動化とかそっちの方にディスカッションの話題が行ってしまいがちでした。
本来ならマイクロサービスの文脈でCI/CDとはどうあるのが良いかというディスカッションになれば良かったんですが。

どっちかというと、CI/CDやってますよね? やってます or やってませんみたいなレベルになってしまって少しもったい無かったかなと思います。

だって、自動化とか別に出来てても出来てなくても良いですけど。この本の主題は、マイクロサービスですから、マイクロサービスにおいて自動化はどうあるべきかに注力出来た方がホントは良いのです。


結構座席的には面白い人が集まっている島だったんですが、マイクロサービスと組織論的な話が面白かったです。SIの文脈においてはマイクロサービスのサービス単位でチームが出来て縦割りになる。その際の政治的な問題とか。
はたまた「過剰なマイクロサービス」の話も面白かったです。CRUDでサービスが分かれるとか。Spring系のマイクロサービスの本とかであるんですって。まぁサンプルとしてはCRUDとかでサービス分けると分かりやすいんでしょうけど。実際やりすぎなんですよね。
でも技術書とかのサンプルがそうなっちゃってるから偉い人が「それが正しいんだ!こういう風にしよう!」みたいなことになったりするらしいです。


マイクロサービスで考えてた時、本にも書いてありますが、CIとCDはあって当たり前かつ、必要不可欠な存在です。かつ、筆者の主張に従うと、1サービス、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 このエントリーをはてなブックマークに追加 はてなブックマーク - Kotlinのkaptの話

Kotlinのkaptの話

カテゴリ:


Pushing the limits of Kotlin annotation processingを読んだ。
よくまとまっている。

ちょっとこの記事をなぞって感想文を書きます。


GA