2020/03/28 15:00
stk132
"5分で作り終わる作業が10–30倍以上の時間を掛けてしまう" マジでこれ。awsコンソールからボタンぽちぽちで終わる設定をcdkでトライアンドエラーでコード化してて、割に合わない感ヤバかった
2020/03/29 22:55
inductor
わかるなぁ。作り込みすぎると教えるのも大変。。。
2020/03/30 01:33
fumikony
terraformingとかcodenize.toolsなどでaws構成を継続的にダンプしていればだいたい間に合うのではという気がしてる
2020/03/30 06:27
monomoti
“それはチームとして今後のキャリアパス的に伸ばしたいスキルですか？” これなー！
2020/03/30 06:57
kamocyc
IaC(コード化)する前に費用対効果を考える．コード化に工数かけなくても，AWSの仕組みやコマンドのログの記録で十分なことも多い．
2020/03/30 07:33
ngsw
コード書いて運用し続けたうえでこう思うというのがチームにとっての財産な気がする。
2020/03/30 08:52
minamijoyo
要はバランスおじさんの気持ちはわかるが、課題にツールが追いついてない問題なので、そこをなんとかしたいのだ。
2020/03/30 08:53
akahigeg
最近は汎用的に使いまわせる初期構築だけ書いてるかな。ソロか数人のチームで
2020/03/30 08:56
naofumi-fujii
“Infrastructure as Codeの概念は非常に魅力的で優れています。でも残念ながら現時点では銀の弾丸ではなくてツールが追いついていないのが現状です。”
2020/03/30 08:57
tettekete37564
Ansible + AWS で地獄を見ているがあれは Ansible の AWS 周辺がうんこなのが大きい
2020/03/30 09:00
rmanzoku
「一回失敗すればいい」まで含めて完全に同意だ。ちゃんと体系的に言語化されていて素晴らしい。
2020/03/30 09:23
watarux
クラウド領域というかOS領域はみんなが変更し（やすく）て、仮想化やマネージドサービスはイジる頻度が少ないって言ってるだけな気がするな。IaCは変更管理もそうだけど環境コピーなんかでメリットがあるもんだと思う
2020/03/30 09:49
sashiharajp
インフラをコードで管理するのは完全に賛成でメリットは理解してるものの ・5分で作り終わる作業が10–30倍以上の時間を掛けてしまう ・1回作るのに数十分かかる この2つは毎回辛いなーと思いながら書いてる。
2020/03/30 09:59
baronhorse
とはいえ書かないと辞められないからな。クラウドんとこもそれこそコードよまないやつはコンソールから設定拾えばいいわけだし書いた方がいい。時間かかるみたいなのは慣れじゃね。
2020/03/30 10:06
tourism55
“ 5分で作り終わる作業が10–30倍以上の時間を掛けてしまう”1000台に適用する(または10台に100回)とわかってる時はいいがそうじゃない時、これがつらい。Excelの“マクロに記録”のような物欲しいなと思ってしまう。
2020/03/30 10:28
yuno001
やりたい事って多分そっちの方向性じゃないのでは。手動で変更した時にだれが何のために変更をしたのかを自動でトレースしてくれるというこじゃないのかな。 それを管理者が検知できれば運用は回る気がするが。
2020/03/30 10:38
shinobue679fbea
便利でいけてたはずの仕組みに殺されかけることあるある、と言いたいがまずその仕組みの導入すらできない人もいるんだよ
2020/03/30 11:24
knjname
手作業のほうが時間かかる場合もある　クラウドインフラの構築って結局リソースのキーを転記するような作業ばかりで、Terraformでキー参照したほうが確実で早い　あとほぼゼロからコード一発構築の路線は捨てた方が幸福
2020/03/30 11:26
asa_ca3
何したいかコードで読めるのは便利なんですけどね。
2020/03/30 12:20
kamemoge
組織や事業としてどうしたいのか問題
2020/03/30 12:31
hiroomi
“DevOpsにも通じますが、インフラを継続的に改善し続ける環境を作るために、変化に強いインフラを作る必要があります”
2020/03/30 13:18
onesplat
awsコンソールからボタンポチポチはいかなる時もやめろ。最悪cliあるんだからスクリプトでもなんでも書けばええやん。それがCode化の大きな第一歩で、それ以上の高度なツール導入は好きにすればいい
2020/03/30 13:30
quabbin
ROIを考える。まさしく。次にBCPを考えるようになったら、だいぶ前進するんじゃないか。BCPで必要な部分と、必要でない部分と考えると、IaCの使いまわしどころがかなり見えてくるはず。
2020/03/30 13:37
k2wanko
"作らない""作り込みすぎない" わかる(わかる)
2020/03/30 14:04
sinsoku
「全てをIaCで管理しない」と「複雑にしない」の2つ話が混ざっている気がする。コードに残ってないインフラを引き継ぐの辛いのでIaCはして欲しい。
2020/03/30 14:23
kuniku
cdk だけでなく samも時間かかるんだよな、SAM CLI (sam local start-api )でCORS問題、authorizers問題 。 Serverless Frameworkの方に期待
2020/03/30 16:13
tohokuaiki
全然わからない世界だ…
2020/03/30 16:56
ptiringo
よい。
2020/03/30 17:02
atsu10
いろいろ参考になりすぎる。
2020/03/30 19:01
kahlua-dane
IaCを行わない一番の怖さはメンバーへの共有だと感じる。 ドキュメンテーションで解決出来る所もあると思うけどOS領域へのIaCと同じ問題があると思う。 ただ、ツールが追いついてない/足回りが悪い問題は深刻だよなぁ。
2020/03/30 19:09
wata88
逆にコンソールからどれをポチポチすればいいかわからない体になった
2020/03/30 20:55
diveintounlimit
分かりみが深い。。。
2020/03/30 21:40
eigo_s
新規参入者向けに参考になるドキュメントとかハンズオンみたいなのをreadmeにかいて、手を動かして触ってもらい、その後実際の環境への小さな変更からやってもらって、怖さを軽減する工夫をしてはいるけれど、悩ましい
2020/03/30 22:25
katzchang
状況を見ようぜ、という話はそう。しかし、道具を知るには一回使ってみないとわからないよなー。
2020/04/01 21:49
masutaka26
最近チーム向けに Terraform ガイドラインを作った。「こんな考えで設計した。（provider ごとに）、コードを捨てても良い、捨てると把握が難しくなるけど維持も大変」とか。※ 自分以外で Terraform 使う人はあまりいない