1940〜50年代に活躍した映画監督オーソン・ウェルズは、「制約がないことが、創造の敵になる」という言葉を残した。これは芸術において「制約は必ずしも悪ではない」ということを意味するが、ソフトウェア開発者にとっても同じではないだろうか。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (1/3)|CodeZine（コードジン）
現代のITシステムはとても複雑だ。オンプレミス、クラウド、OSS、SaaSといった複数の技術領域が絡み合い、その組み合わせの選択肢はレゴブロックのように増え続けている。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (1/3)|CodeZine（コードジン）
自由度が高まったことで、スピードや柔軟性の面では大きなメリットが生まれる一方、それぞれの技術を理解し、使いこなすための認知負荷も増大するばかりだ。各領域でベストプラクティスやブループリントの整備は進んでいるものの、ベンダー固有のIAM設定や監視体制、運用ルールなど、理解しなければならない前提条件や作法は、かえって増えてしまった。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (1/3)|CodeZine（コードジン）
さらに、オンプレミスやマルチクラウドなど複数の環境を使い分けることが当たり前となり、環境間の差異や複雑性が増大した結果、原因の切り分けが困難なトラブルが増加している。例えば障害が発生した際、影響範囲の特定も難しくなり、対応の長期化を招いてしまう。その結果、サイロ化の進行を招くとともに、安定的な運用を維持することも難しくなっている。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (1/3)|CodeZine（コードジン）
このような複雑性は、開発者にも悪影響を与えている。本来、開発者のミッションは、ユーザーに対していかに早く継続的に価値を届けるかという点にあるはずだ。しかし、開発者は「何を選べばいいのか」「どう構成すればいいのか」「この選択は本当に正しいのか」という運用面での判断を常に迫られている。こうした判断の積み重ねが、開発者にとっての大きな負担になっている。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (1/3)|CodeZine（コードジン）
「技術的な選択肢が数多く存在するからこそ、その自由度の高さがかえって迷いを生み出し、開発者が本来の生産性を発揮する妨げになっています。そこで、環境に依存しない共通の運用作法を整備するとともに、開発者向けの推奨ルート（Golden Path）を定めることで、開発者が運用面で煩わされる負担を減らすことが必要です」（町田氏）
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (1/3)|CodeZine（コードジン）
それでは、共通の運用作法を実現するには、どこから着手していけばよいのだろうか。町田氏は、共通化を考えるポイントを以下の3点に整理する。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (2/3)|CodeZine（コードジン）
第1に、「どのように環境を変更するか」という点だ。これは、変更手順やチェック、ロールバックの仕組みを揃えることを指す。第2に、「どのように環境を守るか」だ。環境を守る、とはポリシーによる最低基準の自動的な担保を指している。最後に、「どのように環境を保つか」。環境の作成・更新・廃棄というライフサイクルの管理をしなければいけない。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (2/3)|CodeZine（コードジン）
この3点を揃えていくことで、開発者がコードを書くことに集中でき、ユーザーに向けて自信を持って、より頻繁にリリースできるようになるはずだと、町田氏は伝える。
「自由」がゆえに「複雑」になったクラウド／OSS時代、Nutanixが提唱する「統制のススメ」 (2/3)|CodeZine（コードジン）
⇧ まぁ、「開発現場」では、このあたりが、「メンテナンス」されていないこと、あるあるなのですな...
所謂、「ぼくのかんがえたさいきょうの○○」的な「暗黙知」が至る所に蔓延る状態になっていること、あるあるなのよね...
俗に言う、何ちゃって「DevOps」、「DevSecOps」になっていることが多いのだが、そもそも、複雑さがマシマシな世界になって来たのに、「DevOps」、「DevSecOps」を導入していくのはハードルが高い気もする...
最近、話題の「ハーネスエンジニアリング」でも同様に「メンテナンス」の困難さの問題が浮き彫りになってきておりますしな...
兎にも角にも、「コンテキストスイッチ」による認知負荷は増大し続けているわけでして、脳疲労が止まることを知らない状況ではありますかね...
何と言うか、「開発環境」を整備するのは至難の業ということですかね...
Linuxでdiff3と言うコマンドの存在を知る目視OKならvimdiffが良いかも
前回、
⇧ 上記の記事の時に、
- Dockerホスト
- Dockerコンテナ
のファイルを比較したいという話に触れたのだが、欲を言えば、
- Dockerホスト
- バックアップファイル
- 更新後のファイル
- Dockerコンテナ
の3ファイルの比較がしたいなと思っていて、ネットの情報を漁っていたところ、
⇧ 上記サイト様で、まさかの「diff3」という「コマンド」の存在を知る。
「diff3」という「コマンド」の「マニュアル」を確認してみたところ、
⇧ 上記にあるように、
diff3 - compare three files line by line
⇧ ズバリな「コマンド」が存在していた...
なのだが、
⇧ 上記サイト様にありますように、「vimdiff」という「コマンド」もあることから、
- 「
vimdiff」が使える環境である - 確認する行数が僅かである
- 目視での確認が許容されている
という条件下であれば「vimdiff」を使うで良いのかもしれない...
ちなみに、「vimdiff」の「マニュアル」を確認したところ、
⇧ まさかの8ファイルまで対応できるという...
試しに、「WSL 2（Windows Subsystem for Linux 2）」の「Ubuntu 24.04 LTS」環境にファイルを3つ作成して、「vimdiff」を実行してみる。
⇧ 差分がハイライトされたのだが、色合い的に、正直、見辛い...
一応、「diff3」も試してみた。
⇧ どうやら、各々のファイルの差分内容を横に並べて比較することはできないらしく、差分の確認がし辛いですな...
ちなみに、「ChatGPT」氏に、
- Dockerホストのファイル（バックアップ）
- Dockerホストのファイル
- Dockerコンテナのファイル
を「vimdiff」で比較できるか質問してみたところ、できるとの回答で、以下のような「コマンド」が返ってきた。
vimdiff backup_file host_file <(docker exec [container name] cat /path/to/file)
⇧ 動作確認はできていないのだが、
⇧ 上記に追記したように、Dockerコンテナ経由のコマンド実行に対する「プロセス置換」が動作しないので、「AI」の回答が「幻覚（ハルシネーション）」を引き起こしていると言える...
まぁ、そもそも、「自動化」が促進されている昨今の「ソフトウェア開発」において、「目視」による確認は極力無くしていく必要があると思われるので、個人的な「開発」のタスクなどで利用するぐらいでしか利用でき無さそうと言う気もする...
ちょっとした差分比較はしたいが、「セキュリティ」的に「インターネット」外の「ソフトウェア」を利用するわけにはいかない環境で作業している場合に「vimdiff」を利用するのが良いんかな...
当然のことながら、「vimdiff」を利用できる環境が用意されている必要はあるわけなのだが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
