Closed6
Java on Azure Day 2023 参加メモ
sou (08thse)Azure App Service - PaaS を活用した頑張りすぎないモダナイゼーション
注意点
- App Service
- D: ドライブしか使えない
- タイムゾーンを考慮する
- SQL Database
- タイムゾーン設定ができない。SQL 文で工夫する必要がある
- Azure Monitor
- アラートメールの本文は既定で変更不可。変更するなら Logic Apps で行う
sou (08thse)クラウドネイティブ Java 技術 Jakarta EE 11 & MicroProfile ディープダイブ
- Java 11 がベース
- パッケージ名の変更 (javax -> jakarta) の影響が大きい
- Eclipse Transformer による修正
- maven-plugin による Classfile の自動変換
- CLI でのソースの自動変換
sou (08thse)テック・リードと語る 最新技術導入の秘訣から現場の生の声
SNS 投稿不可パートがあったため割愛🙏
sou (08thse)アーキテクチャの進化から学ぶマイクロサービスの本質
- 本質は "変化に素早く対応し続ける能力" であり、その意味では界隈では古くからのチャレンジと変わらない
- Agile
- Scrum は電車の例え。定員制。やりたいことと今やるべきことの分離
- 課題は「モノリスと調整」
- Cloud
- DevOps
- 運用にとって最大のリスクは「変化の受け入れ」
- Microservices
- 機能的にも非機能的にも分離する
- リリース調整の排除、ブルーグリーンデプロイやサーキットブレーカー
- すべてをマイクロサービス化しようとするのは誤り (Twitter CTO)
- 一括再構築は危険。Netflix ですら 8 年かかっている。時間がかかる
- Cloud Native
- Agile
- 積み重ねられた進化を無視しない
- Agile / DevOps 文化の土台が無いと機能しない
- でも、先人が拓いてくれた道を進んでいけば…！
sou (08thse)マイクロサービス適用の現実的アプローチ
- ビジネスが成長すると必ずアーキテクチャは汚くなる。しかもそこに悪意はない
- 『マイクロサービス化が目的なら、その案件からは逃げろ』ｗ
- 既存モノリスへの適用は「段階的適用」必須
- 機能分割はむしろオーバーヘッド
- ビジネス設計をまずやる
- 『ケーキの切り方、水平に切る人はいませんよね？』
- ビジネス視点で切る
- ドメイン駆動設計も決め手ではない
- バリューストリームで分ける
- バリューステージを跨がない！
- システム側で統合しない！
- 分けた後は従来のモデリングでも大丈夫
- 更新は境界を跨がないようにすること
- パターン批評ｗ
- ストラングラーパターン
- 既存の分割が苦痛。やるなら新規に開発して並行稼働が良い
- 数年かかるし、急いでも失敗するし、結果としてお金もかかる
- データベース分割
- 絶対無理、苦痛
- 『上手くいった人がいたら教えてください』ｗ
- 共有データの実装
- 大事。CQRS はオススメ
- ほぼ変わらないデータ (都道府県オブジェクトとか、マスタデータとか) は共通化して OK
- JOIN (DB, SQL)
- クライアント側でやるか、データレイク的なものを立ててサービス化するか
- Saga パターン
- ほぼ確実に複雑化するのでオススメしない
- 更新目線での設計が適切でない可能性あり
- 間違って機能目線で分割しちゃっているとか
- モジュラーモノリス
- 最終ゴールではないが、段階としては適している
- 「今よりは数段マシ」的な捉え方もアリ
- ストラングラーパターン
- チーム組織・文化
- ビジネス視点、ビジネス分析が必須
- 信頼と協調
- 逆コンウェイの法則
- とはいえ全チームにスーパーマン触れるほど潤沢ではないはずなので、エースで CoE を作って、CoE で各チームをガバナンスすると良い
- CoE は全体設計とアーキテクチャ統制 (昔の EA みたいな)
- とはいえ全チームにスーパーマン触れるほど潤沢ではないはずなので、エースで CoE を作って、CoE で各チームをガバナンスすると良い
- 経営コミットメント。数年かかることも含めて理解
- チームメンバの成長と共有
- 失敗も本音ベースで伝えあうことが大事
このスクラップは2023/05/03にクローズされました