[B! IaC] わたしたちにIaCはまだ早かったのかもしれない

l__LINE__l スクリーンショットは、uiが変わった時に混乱を生むのでIaCが望ましい（メジャーなクラウドはuiが結構な頻度で変わるので）

2022/12/17 リンク

rryu IaCしようがしまいが構成図は必要という。結局コードだけでは全体像を把握するのが難しい。

システム運用

2022/12/17 リンク

quabbin 「そもそも変更機会が少ない」に全て集約されている

2022/12/17 リンク

tpircs なんか微妙な違和感があるな。1か0かの話でなく適用範囲を決めるよねっていうのと、IaCの恩恵にあずかるのは運用がそれなりに継続してからだから投資の意味でどれだけやるかっていう感覚かなぁ。

2022/12/17 リンク

bellonieta たとえばTerraformならtflintやterrascanなどで潜在的な問題を見つけられる。マネコンで自由に操作してたら気づかないバッドノウハウに気づける、そういうメリットに意味を感じないならIaCはしなくて良い。

2022/12/18 リンク

arx0balest その数百行相当の構成が、どこの画面ともわからないWebGUIに埋まる方がヤバイと思うが

2022/12/17 リンク

masatomo-m IaCはサービスが長続きしてエンジニアが入れ替わったりした辺りで効いてくると思う。人は辞めるのでノウハウや記憶と共に失われてしまうがコードは残る。ただサービス立ち上げ期にメンテが重く感じられるのはわかる

2022/12/17 リンク

Karosu コード化すると設計書に落とす作業がものすごく楽だし、再現できない部分を手順書にまとめればもっと楽、ただしできないエンジニアを雇いまくると俗人化一直線

2022/12/17 リンク

matsu-fermat IaCのコードを管理、理解するのが大変と。思ったのは構成図をIaCから自動で作成できないのかなと言うこと。

あとで読む

2022/12/18 リンク

ryuichi1208 コードから全てが生成される世界になればよいのだが...

2022/12/25 リンク

ryousanngata 手順書やパラメータシートを書くのが嫌でIaC使ってるけど、IaCはたいてい依存関係がなければ並列で動くせいで反映時にこけたときにどういう状態になっているかが分からなくなる時があって特有の辛さを感じてる

2022/12/23 リンク

yosio_ism サービサーでプロダクトも少なければ確かにメリット少ないのかも。似たような構成でサービスをいっぱい作るようなお仕事だと、インフラコードを使い回せてお得よね。

2022/12/18 リンク

wtatsuru 14ページ目のこれなんだな "自分たちに必要だったのは、コード化ではなく、ブラックボックス化したインフラアーキテクチャの可視化であり" 。初手はコード化よりはメンテされてる構成図なんだろう

2022/12/18 リンク

launcher 結局コンテナそのものの整備やIaaSのOS(Ansible)とか付随するFaaSとかその他諸々の整備も必要なので思ったよりもシンプルにはいかない

2022/12/18 リンク

nakamura-kenichi 英語やからなあｗ。日本語を捨てん限りはどこまでもついて回るんやでｗ。

2022/12/18 リンク

ALM0ND linuxみたいにguiでやってもIaCでやってもどこかのconfigに反映されていれば良いと思うんだけどなーterraformer とかでわざわざ吸い出さないといけないというのがなあクラウドベンダーで対応してくれんかな

2022/12/18 リンク

sora_h 短期的メリットと長期で見るかって話だよなぁ

2022/12/18 リンク

katsyoshi 課題の解決法だと思っていたことが実は違うということはよくある。まだ数100行程度みたいなのでこのまま進めてもいいんじゃないだろうか。コストに見合わないかもしれんが

2022/12/18 リンク

onesplat まぁこの規模のチームならまだ要らんというのはそうかも。近いうちにまた欲しくなると思うけどね

2022/12/18 リンク

i_luv_kneesox 身につまされる話だ…。というか今まさに直面してる話でもある。他山の石として覚えておきたい。

2022/12/18 リンク

matsu-fermat IaCのコードを管理、理解するのが大変と。思ったのは構成図をIaCから自動で作成できないのかなと言うこと。

あとで読む

2022/12/18 リンク

rrringress ブラックボックスの言語化の取り組み

2022/12/17 リンク

soybeancucumber 技術を手段ではなく目的として本質を理解せずに取り入れるから失敗する。日本のテック企業にアーキテクト不在の組織多すぎ

2022/12/17 リンク

arx0balest その数百行相当の構成が、どこの画面ともわからないWebGUIに埋まる方がヤバイと思うが

2022/12/17 リンク

do_su_0805 なんかモヤモヤしてた部分への解のひとつな気がする。いろんな考え方があると思うけどひとつの参考として覚えておきたいいいまとめだった。

2022/12/17 リンク

nabinno IaCは詳細設計・証跡/変更管理であって、基本設計ではない。手順書はレビューフローが煩雑になるだけなのでIaCの方が安全。「扱えるのが少数であること」が問題ではなく「その少数の能力」が問題。

2022/12/17 リンク

craftone 「鶏を割くに焉んぞ牛刀を用いん」というやつですね

2022/12/17 リンク

asuka0801 何だろう、スクショ手順書作るくらいならterraform勉強会でもやって覚えてもらうのがベターな気がする

2022/12/17 リンク

joker1007 んー……？ってなる。気になるのはドキュメントや図がコードよりメンテ可能なのかという点。コード化の利点はコードを読めば現在の構成が確定出来ることで、覚え易くしたり作業の高速化とかではないと思う。

2022/12/17 リンク

for-my-internet-demo やり遂げたが最後はドキュメンテーションスキルの方が全員嬉しかった説

2022/12/17 リンク

turanukimaru IaC のコードを書くのは日本語を書くよりも難しく学習コストがかかるのでドキュメントに間違いがなくオペの回数も少ないならまぁそうやね。頻繁にリリースするなら IaC ぽくやらないとやってられないけど。

2022/12/17 リンク

yellowdomestic ドキュメントでわからない→わかるにするのは理解できるが、敢えてIaCをやらない方が良い理由になってないと思った　ドキュメントと実際の構成合わなかったり、環境間で差が出たりするんじゃないかと思う

2022/12/17 リンク

diabah_blue わかりみ。

2022/12/17 リンク

quabbin 「そもそも変更機会が少ない」に全て集約されている

2022/12/17 リンク

l__LINE__l スクリーンショットは、uiが変わった時に混乱を生むのでIaCが望ましい（メジャーなクラウドはuiが結構な頻度で変わるので）

2022/12/17 リンク

規約違反を報告

わたしたちにIaCはまだ早かったのかもしれない

AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code（IaC）を導入したものの、IaC化した... AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code（IaC）を導入したものの、IaC化した恩恵が思っていたより少なく、IaCで基盤を統一していく方針を転換していった話をご紹介します。