Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
[B! IaC] わたしたちにIaCはまだ早かったのかもしれない
[go: Go Back, main page]

記事へのコメント33件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2022/12/18 リンク

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

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

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

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

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

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

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

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

2022/12/17 リンク

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

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

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

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

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

2022/12/17 リンク

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

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

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

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

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

2022/12/17 リンク

その他
diabah_blue
わかりみ。

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

2022/12/17 リンク

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

2022/12/17 リンク

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

2022/12/17 リンク

その他
mizukmb
現実わかる。個人的にはコードにする事でレビューがしやすくなったり、変更理由をgit commit messageに残せる事がメリットかなと思ってます

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

2022/12/17 リンク

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

アプリのスクリーンショット
いまの話題をアプリでチェック！
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

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

AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code（IaC）を導入したものの、IaC化した...

ブックマークしたユーザー

すべてのユーザーの
詳細を表示します

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2026 Hatena. All Rights Reserved.