DevOpsへの追悼文

 (matduggan.com)
23 ポイント 投稿者 GN⁺ 2024-06-30 | 2件のコメント | WhatsAppで共有

DevOpsの概念と歴史

  • DevOpsは2007年ごろに導入された概念で、ハードウェアを管理する人々とソフトウェアを書く人々の間の区別をなくすことを目指していた
  • 初期にはNASAの手順やアイデアを模倣し、コードデプロイの安全性を高めようとする試みだった
  • 当時のソフトウェア配布プロセスは次のようなものだった:
    • 開発チームがサーバーソフトウェアのリリースを準備し、QAチームがテストした後に顧客へ配布
    • 運用チームは、ソフトウェア変更点や問題発生時の対処方法を含むプレイブックを受け取る
    • データセンター内で段階的にアップデートをロールアウトしながら監視
    • デプロイ日を決め、デプロイ後に監視

DevOpsの問題点

  • DevOpsは非常に労働集約的だった
  • 開発チーム、QAチーム、テクニカルライター、運用チームの協力が必要だった
  • 機能のデプロイは遅く、重要なアップデートが優先された
  • 多くの組織がDevOpsを導入した理由は次のとおりだった:
    • 技術人材を簡単には代替できなかった
    • 採用が難しく、コストも高かった
    • SaaSベンダーが複雑さを減らしてくれた
    • クラウドプラットフォームの利点が強調された
    • 開発者は、小さな変更がデプロイされるまでに長い時間がかかることに不満を持っていた

DevOpsの実態

  • DevOpsは開発チームと運用チームを1つのチームに統合することを目指していた
  • QAチームは解雇され、迅速なデプロイとフィードバックによって内部テスト期間が短縮された
  • DevOpsはGoogleのSREと混同されることもあるが、SREはより構造化され、厳格なアプローチを取る
  • DevOpsの実際のプロセスは次のようなものだった:
    • 開発者がgitでブランチを作成し、機能を追加
    • PRを開き、チームメンバーがレビューした後でmainにマージ
    • CI/CDシステムがビルドを開始し、コンテナをレジストリへプッシュ
    • CDシステムがサーバーに新しいリリースを通知し、デプロイの成功可否を監視
    • リリース認識メトリクスを通じてデプロイ後の変化を監視

DevOpsの失敗要因

  • 開発者がローカル環境でテストし、Linuxサーバーにデプロイする過程で小さな差異が生じた
  • 運用チームがデプロイを監視しなかったため、問題解決が難しかった
  • 開発者はシステム運用に関する知識が不足していた
  • コンテナの導入で一部の問題は解決されたが、運用の複雑さは依然として残っていた

コンテナの導入と限界

  • コンテナは「自分のマシンでは動いたのに」という問題を解決した
  • Linuxサーバーの構成要素を単純化した
  • それでも残った問題
    • 運用(Operate): インフラ保守、アップグレードなど専門性が求められる
    • 観測(Observe): 複雑なモニタリングシステムの構築と管理が難しい
    • 継続的フィードバック: 内部フィードバック処理が不十分
    • 発見(Discover): チーム間の知識共有が不足
    • 計画(Plan): 中央集権的な計画策定が難しい

Platform Engineeringの登場

  • Platform EngineeringはDevOpsの後継概念であり、開発チームがプラットフォーム運用を理解して問題を解決する代わりに、プラットフォームチームがそれを担う
  • このアプローチは開発チームとプラットフォーム運用の責任を明確に分離して役割分担をはっきりさせるが、それでもなお多くの技術を必要とする
  • 開発者と運用チームの双方が、より多くの作業をしなければならない

結論

  • インフラ領域では、シンプルでプラットフォーム非依存のツールを求める傾向が強まっている
  • 多くの組織がKubernetesのような複雑な技術を手放し、よりシンプルなワークフローへ戻りつつある
  • Platform Engineeringは万能な解決策ではなく、組織は本当に必要なものと不要なものを見極める必要がある
  • DevOpsアプローチの利点を維持しつつ、単純化と安定性に焦点を当てるべきだ

GN⁺の見解

  1. DevOpsの進化と現在の状況は、技術業界のトレンド変化をよく示す事例だ。初期の理想的な目標と現実の間にあるギャップを認識し、実用的なアプローチを探っていく過程が興味深い

  2. Platform Engineeringへの移行は、DevOpsの限界を認めて新たな解決策を模索する試みと見える。しかし、これもまた完璧な解決策ではなく、組織の規模や特性に合ったカスタマイズされたアプローチが必要だろう

  3. クラウドネイティブ技術とマイクロサービスアーキテクチャの複雑性が増す中で、単純さと安定性の再評価が進んでいる。これは技術選択において、ビジネス価値と運用効率をより重視すべきことを示唆している

  4. DevOpsとPlatform Engineeringの変化は、ソフトウェア開発と運用の分野における継続的な学習と適応の重要性を強調している。技術者は新しいツールや方法論を学ぶだけでなく、ビジネス要件と技術的複雑性の間でバランスを取る能力も養う必要があるだろう

  5. 今後のソフトウェア開発と運用のあり方は、より柔軟で状況に応じたアプローチを採用していくと予想される。大規模組織と小規模スタートアップが同じ方法に従うのではなく、それぞれの状況に適した最適なプロセスとツールを選ぶ流れが強まるだろう

関連記事

2件のコメント

 
kaydash 2024-07-02

かなり頻繁に
管理者たちは
DevOpsという概念さえ導入すれば
努力なしに大きな変革が現れると
期待するという（大企業中小企業を問わず）
古い企業の誤った考え
 
GN⁺ 2024-06-30
Hacker Newsのコメント

  • 「devops cycle」の図で重要なのは「build, test, deploy」に集中すること

    • 速度が重視され、エンジニアリングの卓越性は考慮されなかった
    • 運用チームを解体し、QAを再編した
    • すべてのチームがオンコールのローテーションを持つようになった
    • 短期的な利益のためにシステムへ混乱を招く変更を加えた
    • 数か月後には、変更のたびに問題が発生するようになった
    • devopsツールは有用だったが、高コストでフラストレーションも大きかった
    • 新しい開発者はdevopsを知らないが、コンテナは知っている

  • devopsチームが経験した問題に基づく意見

    • 新しいサービスを追加し、インフラを安全に管理できなければならない
    • devopsは標準になっており、手作業中心のシステム管理者業務は不要になった

  • Kubernetesへの批判は的外れ

    • Kubernetesは優れたソフトウェアエンジニアリングの例であり、サポートも充実していて、どこでも動作する
    • 行き当たりばったりにbashスクリプトを使うより、Kubernetesを学ぶほうがよい

  • devopsとは、ソフトウェアのデプロイを容易にするために障壁を取り除くこと

    • 毎日のデプロイは、より高品質なコードの配布に役立つ
    • コードの準備ができたときにだけデプロイできるという選択肢が重要
    • 月次リリースはプレッシャーを生み、非効率な選択につながりうる

  • devopsは方法論ではなく哲学

    • 運用をSDLCに統合することが目的
    • クラウドによってそれが容易になった
    • 「DevOps」チームが生まれたことで、本来の哲学は歪められた

  • リーダーシップの「サイロを壊す」は、ほとんど儀式的なもの

    • 責任を伴わない権限は効果がない
    • 最高のdevops人材は、自分自身をコードで置き換えることを楽しむ
    • devopsツールは成熟しており、ドキュメントも整っている
    • Kubernetesを学ばない開発者は、Linuxコマンドを知らない開発者と同じ

  • ユーザーがテスターになれるなら、そうすべき

    • 問題は経済性だけ
    • 顧客が多ければユーザーにテストしてもらい、顧客が少なければ自分たちでテストすべき

  • プラットフォームチームは大企業でしか成り立たない

    • 中小企業はdevops人材が不足しており、ストレスとリスクを受け入れざるを得ない
    • プラットフォームチームの不在は多くの問題を引き起こす

  • devopsは方法論ではなく哲学

    • サイロ化されたチームでの経験が、devopsの必要性を証明している
    • devopsは、チームがプロジェクトを完全に理解し、デプロイできるようにする

  • devopsには良い意図がある

    • 速いフィードバックループは開発速度にとって重要
    • 組織と製品に合った最適な解決策を見つける必要がある