※ 脳内感想垂れ流し文章
まずベストプラクティスを教えて下さい
筆者の嫌いな言葉ですから始まる，陳腐化しにくい普遍的なクラウド設計の原理原則を知りたい人に向けた蛍光黄緑の光を放つこの一冊．
サービスが停止した時間は大体人的要因だからSDP使って守りは左から固めていく．
障害が起きた時は復旧の許容できる目標（RTO/RPO）を決めてビジネスのニーズを忘れない現実的な落とし所を決める．自動フェイルオーバーは使うがフェイルバックは手動で行う．
再試行は自作しない．クラウドサービスで提供しているSDKを利用する．確かな実績があり，デフォルト値や設定できるオプション，ポリシーがサービスの性質や要件に合わせて最適化されているから．適切な再試行回数と間隔と，べき等性を持つアプリケーションを設計を考えることに時間を使う．
俺メモ：補正トランザクションについては知見がないのでSagaパターン以外についても後日調べる．OutBoxパターン特にわからない．何もわからない．TTL長くして問題ないのか．
ペシミスティック/オプティミスティック並列性制御．いつだって楽観的並列性制御一筋．早いもの勝ちこそ正義．ロックな考え方でロックなどしない．１０数年前に進捗報告用の共有Excelがいつまで経っても開けなくて泣かされたトラウマなのかもしれない．
スケール，RDBMSの話はそれはそう．
高凝集疎結合なサービスの構築，ドメインナレッジをカプセル化する．永遠の課題．出来たと思っていたら出来ていなかったを繰り返して今を生きている...
APIコントラクトはしたことがない．新バージョンはリプレイスする時．
マイクロサービスアーキテクチャの話がとてもいい．ストラングラーフィグでレガシーコードを徐々に締め出していく．Facadeパターンを利用して段階的に移行，リファクタリングを行っていくという発想がなかった．悔しい．
GWオフロード/ルーティング/集約．これアプリケーションが依存しない方法あるのか？
ビジネスニーズは技術の現場から遠ざかりやすい．ね．現場と組織で合意形成するのって難しい．コスト最適化を数値化したとて，言っていることはわかった！でも今困ってないからヨシ！
それでも，具体的で現実的な目標設定を行い文章化は行っていこうと思った．動いて当然，止まればさっさと直すが前提になると本当に必要な予算取りできないもんなぁ．
予算取り出来ないので有事にスケールアップで暫定対応．ピークが終わったら下げる．なんてことしてしまっている...成長とともに，スケールアウトして分割していくことが当たり前にしないとならない．
結局ここで詰むんだよなぁ．良くなることはわかったけど，今はこれを進めなければならないによって現状維持．終わりかけのジェンガを眺める生活．