一人でやる時、チームでやる時
SRE, DevOps, マイクロサービス
技術選定
どのやり方を選んでも究極的には人の問題になる。
自分より力量の高い先輩とやることになってもコード品質に対する考えが違えばどちらかが必ずストレスを抱えることになりうる。
多国籍なチームの場合やはり専門用語の使い方や理解度に大きな差がありコミュニケーションが円滑に進まないことが多々ある。
背景、各技術への習熟度、好みが全く違うメンバーが一人以上集まった際に、ビジネスを前に進めるためのコラボレーションを円滑にするにはどうするか。コーディングする喜びをどうしたら殺さないことが出来るか。
ベロシティが異なる人がコラボレーション(例えばコードレビューが導入される)する場合ベロシティの低い方にあってしまう。
どれくらいYAGNIでどれくらいYAGNIじゃないべきか。
ボトルネック、単一障害点
トラフィックがさばききれないほどになるサービスは実際には非常に少なく多くのソフトウェアは品質を保ち継続的デリバリーが実現出来ればモノリスでも問題ない可能性がある。
トラフィックがさばききれないと感じた際に、現実に最もボトルネックとなるのは、技術選定ではなく、コードやデータベースの品質が低い可能性がある。
境界づけられたコンテキストを見つけられていれば、モノリスだろうとマイクロサービスだろうと品質を高められる可能性が高い。
問題が発生するのは新人エンジニアを採用した時やそのフレームワークに関する習熟が低い人が参加した時である可能性が高い。
モノリスが密結合なわけでは無い。マイクロサービスにすれば疎結合になりやすいわけでは無い。むしろエンジニアのレベルが高くない場合、マイクロサービスの密結合は文字通りカオスになる可能性が高い。
どこまで品質を落とせるか。納品があるなら落とせるか。納品がない場合落とせないのか。
品質が低くベロシティの遅いエンジニアが生きることは出来ないのか、境界を作りうまく仕事をふれないのか。
一人で
自分と同じか自分よりも力量の高いメンバーと
自分と採用した初心者メンバーと
自分と誰かとその部下と
DHH
モノリス <-> マイクロサービス (接続部分、密結合<->疎結合)
MVC <-> MVC + アルファ (抽象化の階層・段階の必要性)
REST <-> RPC (ステートレス <-> ステートフル)
マイクロサービス
境界づけられたコンテキスト
デプロイ
テスト
監視
3章 安定性と信頼性
4章 スケーラビリティとパフォーマンス
5章 耐障害性と大惨事対応
6章 監視
7章 ドキュメントと組織的な理解
6.3 ロギング
6.4 ダッシュボード
6.5 アラート
6.6 オンコールローテーション
https://www.amazon.co.jp/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3-Sam-Newman/dp/4873117607
https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%AC%E3%83%87%E3%82%A3%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9-%E2%80%95%E9%81%8B%E7%94%A8%E3%81%AB%E5%BC%B7%E3%81%84%E6%9C%AC%E7%95%AA%E5%AF%BE%E5%BF%9C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%A8%E6%A8%99%E6%BA%96%E5%8C%96-Susan-J-Fowler/dp/4873118158/ref=cm_cr_arp_d_product_top?ie=UTF8
DevOps
コラボレーション
アフィニティ
ツール
スケーリング
SRE
分散
自動化
リリース
インシデント
テスト