Infrastructure as Code(IaC)もずいぶん使い古された感のあるワードですね。
出始めの頃は自分もChefとかPuppetを使いさえすればいいもんだと勘違いしていました。
実際はもっと大きな考え方であり、この本は網羅的にIaCの考え方を抑えていってくれるので、 視野狭窄にならないようにするためにも、読んでおいて損はない本だと思いました。
内容
この本はIaCに関する技術的トピッックを取り上げるというよりかは、概念とか思想とかそういったものを教えてくれます。 よくあるアンチパターンとどうやってIoCを取り入れていくか、トピックごとにパターンを提示していきながら、 再現可能でセキュアで品質の高いシステムを作っていく方法が書かれています。
そう、システム。当たり前だけどシステムはインフラだけで動いてるんじゃないんです。
読んでる間は結局うちの組織にどうやって適用すればいいんだよっていう葛藤との戦いでした。 何度この本を読みながら天を仰いだことか。 IaCを適用していく上での組織論みたいな部分もあるにはあるんですが、 100個組織があったら100個の文化があるわけで、そんな綺麗に当てはまるわけもないですし、 そんな細かいところまでこの本も解決するつもりはなく、こんなベストプラクティスがあるよって程度です。
それでも、この本が提示してくれたメリットには夢がありました。
特に面白かった所
結局、アプリケーション開発の良い部分を、インフラに持って行こうという点が、特に後半では強くなります。 ユニットテストやCIをインフラに適応させていく話は、数年前はアプリケーション開発をやってた身としては、非常に納得感のあるものでした。 コードを描いてて、テストがあることによる安心感は相当なもんです。 そしてインフラに何か変更を加えるとき、様々な要素が検証環境と違うことがある中で本番環境に手を入れる時の緊張感も相当なもんです。
考えたこと
自分の組織に如何に適応していくかを考え続けた読書であったことは前述の通りです。 そして最後に思ったのは、結局アプリ・インフラとあまりに分かれている組織はダメなんだなということでした。 アプリはもっとインフラを理解しないといけないし、インフラももっとアプリを理解しないといけない。 これもずっと言われ続けてきていることですけど。
アプリ屋さんがセルフサービでインフラを構築できないと、IoCの求めている姿にはならないし、そのためにはインフラの知識が必要です。 そしてインフラ屋さんは、アプリケーションのニーズを理解しつつ、アプリ屋さんがセルフサービスでインフラを構築できるような基盤を整えていくことが必要になっていくんでしょう。
まとめ
古き良きインフラ運用のデメリットと、IaCがもたらしてくれる明るい未来を予感させてくれました。 まだまだやることがあるなと途方に暮れつつも、ワクワクさせてくれる本でした。