@antipop
技術的負債の分類 (Kruchten et al., 2012)
- コードの負債は見えるので検出し易いけど、アーキテクチャの負債は見えないので大変
- アーキテクチャの再構築、リファクタリング
可能的代替システムとの差異(Schmid, 2013)
- 負債の要因や意図を問わないモデル化
- 可能的代替システムとの差異を問う
- 負債返済の意思決定について
未来は不確実なので、意図の有無に関わらず、負債は避けられない あり得る未来と、未来において可能になる選択肢の間で、其の時にとれるベストな選択肢を取る
負債, 比喩として使えばコミュニケーションに便利
Immutable Infraセッション
- Storage, Log収集はまだ解決されてない
- Log収集, あるにはあるけどコストに見合わない
- テスト, Agile, もっとベーシックな話できてないとこ多い
- そもそも前段階あるだろ、ちゃんとやれ
- DevOpsしたいと思って言われて行ったらAgileしたいだった。
- 銀の弾丸っぽくとらえられがち、ツールや概念の一人歩き
- やるべき事やってて、知らない間に辿りついてたみたいなのが理想
- IIやりたいんだけど、ってよくわかんない人に言われそう
- II的なものから利益を享受できる人
- ふつうのWebApp作ってる人
- うまく制約を入れ込める人
- 楽さ
- インスタンス使うのに稟議書…
- 現場が上手く使って、中間が理解する感じでいいのでは
- 経営的なメリットはどこに
- ディスポーザブルなのは開発速度上げるのに役立ちそう
- そこに利益があるのは明白
- ダマされた人が取り組むといい恩恵があって便利
- 作るもののライフサイクルが長いvs短い
- Rails -> ガンガンバージョン上がったり後方互換性切ったりする
- ライフサイクルが長いものほどディスポーザブルにすべき
- 1年前に作ったサーバのアップタイム1年、みたいなのは悲劇
- ゴールデンイメージ作れなくなっちゃうかもしれない
- 環境もコードにあればいい？
- 別に捨てなくてもいいのでは
- ChaosMonkey -> ディスポーザブル前提
- RDS
- サービスの特性に依存する
- どっかでRDB使う前提が破綻する
- Web+RDBってどうなの？
- 購買履歴 -> S3に置いてある。RDBに入ってない。
- DBに頼らないってのもありなのでは
- データ溢れるし、減らない
- 性能測定やった瞬間大変なことになったりする
- RDBのDBの部分をImmutableにするのは厳しい
- だからといって移すのも厳しい
- ハードウェアが超高性能になって解決
- Statefulな部分もImmutableにとか考え始めると意味分かんなくなる
- 課題: Application ServerがよくてもMigrationとかDB周りのギャップ
- Databaseもブランチできるといい
- ブランチきるとデータも全く同じものができて, マージできたりするといい
- 概念が広がって対応する圧力が産まれるといいですね
- ホスティングだとデータも預かってる, そこがImmutableにできればいいとは思う
- さいご
- 当たり前の事を当たり前にしましょう
- Infrastructure's Codeをちゃんとやりましょう
- どんどん捨てれる環境大事
- サービスを動的にしたい
- serverspecは静的なふるまいしかテストできない
- serverspecでしっかりテストしたものをデプロイ、みたいにできるといい
- 遷宮