目の前に広がる世界にIaCがハマるのかを考える

IaCについては今年度に結構考えた。自分で取り組んでみてわかったけれど、マネジメントコンソールからインフラを作っていくよりもやはり効率が良い。

環境を簡単に再現でき、だからこそ簡単に捨てられる。手動で変な変更をされるといわゆる自動化が進まなくなるけど、IaCはそういった不統一を避けることもできる。さらに、インフラがコードで表現されているということは、その環境を構築するための手順が正確にわかるということでもある。「文書化されているけど保守のされない環境構築手順」とおさらばできるのもありがたい。

IaCへの抵抗感

業務とIaCとの相性は決して悪くないと考えている。一方で、IaCに取り組みましょうよと言ったところで、それほど周囲の反応が良いわけではないことが多い。 その理由として挙げられるのは以下になる。

• IaCの学習コストが高い。結果として生産性を下げる
• 個々のプロジェクトで個別にインフラをコード化したところで、別プロジェクトに適用できないので、生産性があがらない

IaCの目標と構築・運用の分断

書籍「Infrastructure as Code」では、IaCの目標を以下のように記述している。

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

• ITインフラが変化の障害や制約になるのではなく、変化を支えて実現すること。
• システム変更がユーザーやITスタッフのストレスや大事件ではなく、日常作業になること。
• ITスタッフが、日常的反復的なタスクではなく、彼らの能力を活かした価値のある仕事のために時間を使うこと。
• ユーザーがITスタッフに頼るのではなく、自分で必要なリソースを定義、プロビジョニング、管理できるようになること。
• 失敗を完全に予防できるという前提に立つのではなく、失敗が発生しても簡単かつスピーディに回復できるようになること。
• コストがかかりリスキーな「ビッグバン」プロジェクトではなく、継続的な作業により改善、改良を実現すること。
• 会議やドキュメントでソリューションを論ずることではなく、実装、テスト、計測を通じてソリューションの効果が証明されるようになること。

変化を支える、継続的、改善や改良といったキーワードが並ぶ。 IaCの主目標は、新規開発においてその生産性を向上させるというよりもサービスの成長に合わせてインフラを変化・成長させていくことにあるのだろう、というのがぼくの認識。

結果として、インフラの構築とインフラの保守の主体が分断されている場合はIaCを訴求する難易度が上がる。

• インフラの構築側は"特定地点までのインフラ構築"までを最適化するインセンティブが強くなる。「構成ドリフト」や「スノーフレークサーバー」といった運用時に起こりやすい問題をどう防ぐかといった考慮の優先度は低くなる
• 開発と運用が分断された状態で「同じ技術」を一緒に使っていこうという調整コストが高い
  • 渡された手順書を実行するだけの硬直化した運用である場合、そもそもインフラの変更は「運用」ではなく「保守開発」になってしまう

ビジネス的な観点

受託案件のシステムを開発する場合、一般にお客様へ納品するのは「動くアプリケーション」と「それを再構築できるアプリケーションコード」や「設計書」になる。そのあとのアプリケーションの改善はお客様側に主体が移るということだと考えている。 お客様がアプリケーションを修正・改善していくためにはどのようにアプリが動いているのかを理解する必要がある。「どのように」を理解するためには設計書があれば良い。そこに加えてコードを納品する意味は、果たしてなんなのだろう。

一方で、インフラの場合にお客様へ納品するのは「動くインフラ」であって「コード」を納品するケースは多くない。コンフィグは納品するだろうけど。 アプリはコード納品が必要で、インフラはコード納品が不要な理由は何なのだろう。インフラをコード化して納品でき、そのコードをお客様側で（スキル的にも、ビジネス的にも）修正できたとしたらどんな未来が広がるだろう。

諦めにも似た気持ち

これは以前に指摘されたことがあるのだけれど、ぼくは周囲の世界が自分の考えるように進まないことを人のせいにするところがある。 IaC便利じゃん、やるべきでしょと言ったところで世界はそう簡単には変わらない。訴求の仕方、人へのアプローチ、そういう戦略が良くないのだろう。確かに反省する部分が多い。

長い年月を費やして、少しずつ自分の見える世界を変えようとする人たちは間違いなく存在していて、ぼくはそういう人を本当に尊敬の眼差しで見ている。 それとともに、自分の人生という時間をそこに消費するモチベーションの源泉がなかなか見えない。

構築時の生産性に全振りしてみる

開発と運用との分断、技術の不統一、スキルの問題といったところからは一度目を背ける。これらはたぶん、いやほぼ間違いなく、一朝一夕にはいかない。 変えていこうとする場合は、相応の人生、時間を捧げる必要がある。

現在のスキームを変えずにIaCが価値をもたらせるとしたら、それはどのようなシナリオか。 プロジェクト間でIaCのコードの再利用性をあげ、構築の生産性を向上させるのが一案としてある。

個別案件でコードを書いたとしても、それは再利用しづらい。これはインフラであれアプリケーションであれ同様であって、著作権に代表される財産権が他プロジェクトへの共用を阻むところが大きい。アプリケーションは、そういった共用部分を自社あるいはOSSフレームワーク等に内包させることによって、こういった問題を解決してきたような気がする。

インフラも同様に考えれば良いのだろうか。一定の共通部分をアーキテクチャテンプレートとして抽出し、IaCのモジュール化を行い、それを利用してもらえれば生産性があがるのではないか。モジュールを組み合わせる時のコードは、納品後に廃棄される可能性もあるが、IaCとしての資産はモジュール側に残る。