最近では、DevOps を定義するのが非常に難しくなっています。それは、DevOps が当初解決していた問題がすでになくなってしまったからです。

最近の企業の中には、実際には問題が存在しなかったところもあります。すべてを正しく実行しているのですが、ソフトウェア エンジニアリングの状況が急速に進化したため、ツールとクラウド エンジニアリングによってギャップが埋められてしまったのです。

私たちは、DevOps の誕生と、Dev と Ops の間のサイロを打破することを目指したその文化の転換からまだ遠いところにあります。

開発と運用のサイロ

2008年にパトリック・デュボア彼が DevOps について最初に考えたのは、プロジェクト管理がウォーターフォールからアジャイルに移行したばかりの状況で、開発と運用の間の非効率的な連携に注目していたときでした。

当時の運用チームは、ネットワーク、サーバー、仮想マシン、OS、ソフトウェアの更新などすべてを管理していました。これにより、多くの手動操作が効果的に隠蔽されました。すべてが手動だったわけではありませんが、Puppet、Chef、Ansible、さらには Terraform が存在する前のことでした。

サーバーとソフトウェアのリリースの管理は決して簡単なことではなく、多くの専門知識が必要でした。これは、新しいソフトウェア リリースを迅速かつ確実に配信することを妨げるものでした。

クラウドはサイロの衰退の最初の兆候

2006 年に誕生した AWS は、最初の大手クラウド プロバイダーでした。DevOps は 2008 年に造語されましたが、クラウド管理の問題を解決することではなく、オンプレミス インフラストラクチャの運用間の実際のサイロを解決することを目的としていました。これが、DevOps とは何かという混乱の根源です。ソフトウェア エンジニアリングの分野では、ほぼ同時期に 2 つの大きな変化が始まりました。

クラウド コンピューティングに関しては、Software as a Service (SaaS)、Platform as a Service (PaaS)、Infrastructure as a Service (IaaS) という 3 つの主要なモデルが使用されています。これらの高レベルな構造を使用しているため、OPS (システム管理) はほとんどなくなりました。これは、DevOps の父たちが特定した元の文化の問題がもはや存在しないかのようです。

各モデルは、基盤となるインフラストラクチャの制御、柔軟性、管理レベルが異なり、オンプレミスのインフラストラクチャを維持する企業はほとんどありません。

そのため、DevOps 運動がDev と Ops 間の「サイロット」問題を解決しようとしている一方で、クラウド インフラストラクチャはOps を時代遅れにすることで、すでに問題の一部を解消しつつありました。

オペレーションなし、サイロなし

DevOps の重要なモットーは、「シフト レフト」と「構築したら実行する」であり、これは Ops タスクを開発部門に移管することにつながります。クラウドは IaaS モデルを提供することでシステム管理者 (Ops) の必要性を減らし、開発者がアプリケーションを自分で管理および展開する労力を軽減しました。

もっとわかりやすく言い換えましょう。運用チームは、ソフトウェアの統合と展開を簡素化するツールを提供することで開発者を支援し、インフラストラクチャを維持するために運用チームが行うべき重労働を軽減しました。その結果、システム管理 (運用) が不要になる状況になりました。

しかし、これらの「ソフトウェアの統合と展開を簡素化するツール」を保守する人が必要です。

この新しく出現した役割にはまだ名前がありません。これは、元 Ops が「DevOps 担当者」としてブランド名を変更して提案したためです。DevOps エンジニアと呼びましょう。おそらく誰かがどこかの時点でこの名前を言い、それが定着したのでしょう。

DevOps の再定義

DevOps はツールに関するものではなく、文化に関するものでした。ソフトウェア エンジニアリングもより「リーン」になり、ソフトウェア配信をジャスト イン タイムで実行できるという考え方です。DevOps の当初の問題は解決したかもしれませんが、ソフトウェア エンジニアリングで最も重要なアイデアである継続的配信が生まれました。

私は長い間、DevOps は役割でもチームでもないと主張する人たちを支持してきましたが、もしそう呼ぶのであれば、それは間違いです。後になって、物事はもっと複雑だということに気づきました。私たちは「ソフトウェアの統合と展開を簡素化するためのツールを管理する人」という不自然な役割を作り出しましたが、それに名前を付けていませんでした。

考えてみると、すべてがクラウド サービスである場合、「ソフトウェアの統合と展開を簡素化するツールを管理する担当者」が本当に必要でしょうか。完全に管理されていますか。ボタンをクリックするだけで機能しますか。

これは、ほとんどのクラウド プロバイダーや多くの DevOps SaaS 製品 (GitLab など) の夢です。しかし、現実はそれほど単純ではありません。理論上は、物事は単純になり、運用タスクは自動化され、サービスは完全に管理されるなどすることができたはずです。しかし、現実には、私たちはモンスターを作り出してしまいました。

その結果、ほとんどの運用/インフラストラクチャ チーム (別名 Ops) にとっての課題は、無数のツールとサービスのマップをナビゲートし、それらのツールを理解して展開し、開発者が使用できる一貫したインフラストラクチャとツールに接続することです。

DevOps が行き詰まっているというのは、DevSecOps、FinOps、GitOps、MlOps などに簡単に派生する重要な流行語です。

しかし、気づけば、残っている香りは常に Ops です。面白いのは、それぞれのアプローチが方程式から Ops を取り除くことを目指していることです。Ops とは、別名「システムにログインして、システムを機能させるために何かを行う人」のことです。

要約

DevOps が解決しようとした当初の問題は、クラウド インフラストラクチャの台頭により、もはや存在しない可能性があります。しかし、DevOps は継続的デリバリーという重要なアイデアを生み出し、ソフトウェア エンジニアリングの文化に変化をもたらしました。

「DevOps」という用語は流行語として定着しているかもしれませんが、DevSecOps、FinOps、GitOps などの新しいアプローチの開発につながっており、これらはすべて従来の Ops タスクの必要性をなくすことを目指しています。

結局のところ、DevOps とクラウド インフラストラクチャの状況は常に進化しており、最新の状態を維持し、適切なツールを選択するのは困難です。皮肉なことに、DevOps は当初、開発と運用のコラボレーションを意味していましたが、運用を方程式から除外する方向にシフトしています。