Frugal Architect Everything fails, all the time. (Design for failure) オッカムの剃刀 「ある事柄を説明するためには、必要以上に多くを仮定するべきではない」 Werner が Amazon.com CTO として学び実践してきたこと Monoliths are not dinosaurs シンプルするということと複雑さの制御とその関係性 原理原則にしたこと「シンプルさ」 これまでの振り返り 複雑性は誰かが作ることも、壊すこともできない（結果からなるもの） ただし、意図する複雑性と意図しない複雑性に分類することができる 意図しない複雑性に気づくために Complexity warning signs システムは進化するもの コンポーネント数が複雑性の尺度ではない Discipline(規律=原理原則的な考えと理解) によってシンプルさを維持できるように運用する システムは流動であり、進化が必要 Lehman’s Law 進化可能性をもつ Building evolvable systems Warning signs を見逃さない Brake complexity into pieces. 結合性を分解しAPIをもつBuilding blockにする Align organization to architecture Smallチームとオーナーシップ Organize into cell セル型アーキテクチャ 設計・構築段階よりも運用の寿命が システムの寿命と進化可能性を左右する Security is Everyone’s Job どこにコストをかけるべきか 複雑性とシステム内の影響度を抑えるためのアーキテクチャ Design predictable systems 自動化による複雑性 Automate complexity What don’t we automate? Everything starts with security することよりもしないことを決める 脅威への対応の自動化 We all have support tickets Unix哲学(Small is beautiful) Share your lessons
Frugal Architect Everything fails, all the time. (Design for failure) オッカムの剃刀 「ある事柄を説明するためには、必要以上に多くを仮定するべきではない」 Werner が Amazon.com CTO として学び実践してきたこと Monoliths are not dinosaurs シンプルするということと複雑さの制御とその関係性 原理原則にしたこと「シンプルさ」 これまでの振り返り 複雑性は誰かが作ることも、壊すこともできない（結果からなるもの） ただし、意図する複雑性と意図しない複雑性に分類することができる 意図しない複雑性に気づくために Complexity warning signs システムは進化するもの コンポーネント数が複雑性の尺度ではない Discipline(規律=原理原則的な考えと理解) によってシンプルさを維持できるように運用する システムは流動であり、進化が必要 Lehman’s Law 進化可能性をもつ Building evolvable systems Warning signs を見逃さない Brake complexity into pieces. 結合性を分解しAPIをもつBuilding blockにする Align organization to architecture Smallチームとオーナーシップ Organize into cell セル型アーキテクチャ 設計・構築段階よりも運用の寿命が システムの寿命と進化可能性を左右する Security is Everyone’s Job どこにコストをかけるべきか 複雑性とシステム内の影響度を抑えるためのアーキテクチャ Design predictable systems 自動化による複雑性 Automate complexity What don’t we automate? Everything starts with security することよりもしないことを決める 脅威への対応の自動化 We all have support tickets 予測可能であることと 可観測性の関係 Unix定理(Small is beautiful) Share your lessons
Frugal Architect Everything fails, all the time. (Design for failure) オッカムの剃刀 「ある事柄を説明するためには、必要以上に多くを仮定するべきではない」 Werner が Amazon.com CTO として学び実践してきたこと Monoliths are not dinosaurs シンプルするということと複雑さの制御とその関係性 原理原則にしたこと「シンプルさ」 これまでの振り返り 複雑性は誰かが作ることも、壊すこともできない（結果からなるもの） ただし、意図する複雑性と意図しない複雑性に分類することができる 意図しない複雑性に気づくために Complexity warning signs システムは進化するもの コンポーネント数が複雑性の尺度ではない Discipline(規律=原理原則的な考えと理解) によってシンプルさを維持できるように運用する システムは流動であり、進化が必要 Lehman’s Law 進化可能性をもつ Building evolvable systems Warning signs を見逃さない Brake complexity into pieces. 結合性を分解しAPIをもつBuilding blockにする Align organization to architecture Smallチームとオーナーシップ Organize into cell セル型アーキテクチャ 設計・構築段階よりも運用の寿命が システムの寿命と進化可能性を左右する Security is Everyone’s Job どこにコストをかけるべきか 複雑性とシステム内の影響度を抑えるためのアーキテクチャ 自動化による複雑性 Automate compexitty What don’t we automate? Everything starts with security することよりもしないことを決める 脅威への対応の自動化 We all have support tickets 予測可能であることと 可観測性の関係 Unix定理(Small is beautiful) Share your lessons Design predictable systems
Ambassador AWS All Certifications Engineer コミュニティ向け AWS Community Builder AWS Gold Jacket Club AWS Samurai AWS Hero APJ Community Leaders Award 2024 AWSの認定・表彰制度 ※山口調べ
kinunori
aki_iinuma
danielanewman
thoeni
pedronauck
wjessup
davidbonilla
tammyeverts
hannesfritz
62gerente
lemiorhan
samanthasiow
stephaniewalter
