⇧ システム障害の再発防止を目指すよりも、システム障害が起きる前提で如何にリカバリーを滞りなく実施できる体制を作る方が重要な気がしますけど...
システム障害を0にすることは不可能だと思うので、解決する課題の設定が間違っている気がしますな...
上記のシステム開発、保守・運用に、どれだけの数の人間が関係してきたか分かりませんけど、様々な要因がどう影響するか神のみぞ知る世界だと思うので、システム障害の再発防止に焦点を当てた対策の効果は薄い気がしますな...
IaC（Infrastructure as Code）とは
Wikipediaさんによりますと、
Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバーなど）の構成管理・機械処理可能な定義ファイルの設定・プロビジョニングを自動化するプロセスである。定義されたファイルはバージョン管理システムで保持することもある。
従来、手動のプロセスではなくスクリプトや宣言的な定義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられている。
⇧ とある。
システムの環境構築をコードで行えるようにする手段ということらしい。
つまり、環境構築の自動化であると。
詳しくは、上記のWikipediaの続きを参照。
AIIaCツールでもIaCツールによるクラウドのリソース環境構築ファイルの相互変換はでき無さそう...
で、クラウドでの環境構築の話に焦点を当てると、
「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」って、メジャーどころだけでも、
- AWS（Amazon Web Services）
- Microsoft Azure（【旧】Windows Azure）
- Google Cloud（【旧】GCP：Google Cloud Platform）
⇧ みたいな感じで、複数存在しますと。
そして、人類は歴史に学ばないので、
⇧ 上記サイト様にありますように、「IaC （Infrastructure as Code）」ツールが乱立しているらしい...
で、困ったことに各ツールで、統一感が無いというね...
つまり、意図的なのかは分からないのですが、再利用性が考慮されていないという...
まぁ、どちらにしろ、各「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」間で、提供しているサービス、環境が異なるからして、相互の環境依存を解消する術は無さそうなので、どの「IaC （Infrastructure as Code）」ツールを使うにしても、各「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」に対応したコードを作る必要があると。
ちなみに、
⇧「AIIaC（Artificial Intelligence Infrastructure as Code）」なるツールも出ているようなのですが、2024年3月17日（日）時点で、相互変換する仕組みは実現できてい無さそう...
マルチクラウドの例になってしまうのだけど、Terraformでも
⇧ 結局のところ、それぞれの「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」用に環境構築のファイルを用意する必要があると。
1つのテンプレート（雛型）を作ったら、それを元に他の「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」用のファイルに変換してくれる機能が欲しいですな。
ちなみに、
このライセンス変更はHashiCorp社と競合する企業に対して競合プロダクト内にコミュニティ版HashiCorp製品を無償で利用できなくなるもので、Terraformなどを利用するユーザー自身には影響はありません。
Terraformはコードを元にインフラストラクチャを自動で構築することで、安全かつ効率的に構築、変更、バージョン管理できるようにするツールです。2014年からMozilla Public License 2.0のオープンソースソフトウェアとしてHashiCorp主導で開発されてきましたが、HashiCorpは2023年8月10日に突然Terraformのライセンスを商用利用を一部制限するBSLに切り替えると発表。これに反発したコミュニティによって、オープンソース版のTerraformとして「OpenTF」の開発が進められていました。
Terraformのオープンソース版フォークの名称が「OpenTofu」に決定、Linux Foundation Project化も行われる - GIGAZINE
⇧「OpenTofu」とか誕生した経緯は、Terrformのライセンス変更が発端らしい。
とりあえずは、環境構築ファイルについて、各「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」間の相互変換を実現する有効な手段は無さそうなので、人手で頑張るしか無い感じなのが分かり絶望しかありませんと...
1つだけ言えることは、Terraformは、「HCL (Hashicorp Configuration Language) 」という独自のコーディングをユーザーに強制するところが悪手でしたな。
ユーザーには、普段使いのプログラミング言語を選択できる猶予を与えておいて、Terraformの内部でプログラミング言語の差異を吸収するようにすれば良かったのに、ユーザーのことを全く考慮できていない設計だったということですかね。
「OpenTofu」はTerraformと方針を変えない場合は、同様の使い辛さが問題になってくる気がしますが、「OpenTofu」含め、他のツールが上手いこと機能を追加・改善していければ、Terrformが廃れていくということもありそうですな。
何と言うか、
⇧ 職人を生む方向のツール設計は個人的に好きじゃないんよね...
属人化が全て駄目というわけでは無いのだが、学習コストとかの負担をユーザーに強いる感じになっているのが納得いかないんよな...
「OpenTofu」には、そのあたりの課題に取り組んでもらいたいんですけどね...
理想を言えば、ユーザー側は利用したいサービスの一覧をインプットとして用意しておくだけ担当すれば良い形にして、後は「IaC （Infrastructure as Code）」ツール側で良しなにサービス同士の依存関係とかも解決して環境構築してくれる感じにして欲しいんですけどね。
各「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」は自分たちのサービスを利用して欲しいだけで、他社を利することになり得る機能の追加に取り組んでくれそうな可能性は限りなくゼロと思われるので、対応が期待できそうなのは、各「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」以外になってきそうね...
そして、
⇧ インフラエンジニアの方でも、「IaC （Infrastructure as Code）」に対する費用対効果に疑問を感じることがあると。
リカバリーがし易い環境じゃないと、トライアンドエラーするモチベーションが湧かないですし、環境構築ってブラックボックスな部分が多くて本当にストレスなんですよね...
何にせよ、「システム開発」において「人間中心設計（HCD：Human Centered Design）」って考え方があるとは思うのですが、エンジニアをユーザーと見なすサービスについての話になると、途端に「ユーザー」のことが蔑ろにされがちなのがいつも不思議で仕方ないんですよね...
「ユーザー」がエンジニア以外の場合だったら、クレームとかにも発展し兼ねないことを平気で行っているからして、各「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」は、顧客に対してサービスを提供し、その対価としてサービス利用料という形で請求しているのだから、サービスに欠陥があることを自覚してサービス改善のための企業努力をして欲しい...
結局のところ、
⇧ この乖離が顕著に起きてるのが、「IaC （Infrastructure as Code）」のツールという気がしますな...
「顧客（エンジニア）が本当に必要だった物」が理解できていない、つまり、課題が分かっていないんだと思うのだけど...
課題は分かっていて、意図的に対応していないとしたら、論外ですけど...
エンジニアだから技術を理解して当然という暗黙の前提で、顧客がエンジニアだった場合にもその考えを適応して顧客（エンジニア）にコストの負担を強いる悪しき習慣、そろそろ無くして欲しいんですけどね...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
