2000年頃に登場した「VMWare ESX」（仮想化技術）、2006年の「Amazon EC2」（パブリッククラウド）などが可能としたのは、コンピューティング資源を一カ所にプールしておくことでインフラ調達にかかる期間の短縮に加え、構築・運用コストの削減、コンピューティング資源の有効活用などを実現することでした。これらは多大なメリットをもたらしました。特に新たなインフラを構築する際に何カ月も待つ必要がなくなり、極端なことを言えば半日もあればインフラ調達が完了する時代の到来を感慨深く思われた方も多いでしょう。
ところが、便利なものはつい乱用してしまうのが人間の性というもので、想定よりもはるかに多くのサーバーを構築してしまい、管理すべき対象が爆発的に増えてしまいました。その結果、手作業での管理は現実味を失い、コード（プログラム）化による自動化を推し進めるよりほかの選択肢はありませんでした。具体的には、2009年の「Chef」や 2012年の「Ansible」など、サーバー構築作業を自動化するインフラ構成管理ツールが該当します。これらのツールはインフラの構築／維持管理という作業の特性にマッチするよう冪等性（べきとうせい。ある操作を1回実行した場合も、複数回実行した場合も、同じ結果となること）を保証する機能の提供を通じ、対象環境の「あるべき状態」をコード化するという新しい考え方を根付かせ、インフラ構築の自動化に大きく貢献しました。
もちろん理想と現実の姿にはギャップがあります。全ての構築あるいは設定変更作業のコード（プログラム）化は理論上可能ですが、現実世界における人的、時間的制約下では難しいことも多いのが実情です。特定のサーバーだけ一時的な変更を手作業で行って後で戻し忘れる、あるいは職人技による手作業にも職人ごとにそれぞれの流儀があるなどの問題に起因して構成・設定の差異が紛れ込む（構成ドリフト問題）、これらのドリフトが蓄積して詳細把握が困難になりアンタッチャブルになる（スノーフレークサーバー問題）、さらには、これが原因で構成管理ツールの実行結果が予測不能になる（オートメーション恐怖症）といった悪循環と苦闘されてきたインフラ関係者も多いと思います。
しかし、IaCを通じた自動化という大きな流れはもはや止めようはなく、ハイパーバイザーによる仮想環境やクラウドサービスなどの外部からの操作を可能とするAPIが公開されるなど、環境の構築そのものも自動化の対象となりました。代表的なツールとしては、2010年頃に登場した「Vagrant」や2014年の「Terraform」などが挙げられます。また、IaCにより自動化された作業は人間による手作業よりも品質面で有利であるという当たり前の事実が広く認識されるに至り、インフラ構築の考え方が大きく転換します。
すなわち、インフラ環境の初期構築・構成作業が自動化され、短時間で正確に行えるようになった現在、一度作ったインフラ環境を構成ドリフトやスノーフレーク問題に耐え、状態管理しながら使い続ける苦行はいっそやめて、インフラ環境をバージョン管理しながら使い捨てる（新しいアプリケーションコンポーネントをデプロイする際にインフラ環境を新たに作り直す）方がいいのではないか、という「イミュータブルインフラストラクチャー」の考え方です。イミュータブルとは「不変」、すなわち「環境に手を加えない」という意味です。さらに2014年頃に登場したマイクロサービスのアーキテクチャーで作られたコンテナー型アプリケーションなどと組み合わされ、そうして作成可能になった「完全な金太郎飴」は、ユーザー数の急激な増加や頻繁な構成変更にも対応できる現実解として広まっていきました。
運用は枯れてなお運用
このようなインフラ構築の世界における革命的な変化は、当然のように従来の開発（Dev）と運用（Ops）にも大きな転換を迫りました。まず開発（Dev）の側からすると、インフラ環境は運用（Ops）に作成を依頼し、その出来上がりを根気強く待つものではなく、自分たちで必要な時にIaCを呼び出して作ることができるものになりました。さらには自分たちが開発したアプリケーションをデプロイする作業も、デプロイの手順を作成し運用（Ops）に渡して実施してもらうものから、自分たちでデプロイの仕組み（デリバリーパイプライン）を構築し、自分たちで実施できる作業になりました（注：多くの日本企業においては開発環境と本番環境がネットワーク的に分離されており、開発チームによる本番環境へのデプロイは不可ですが、これはデリバリーパイプラインを通じた自動化の推進そのものを妨げるものではありません）。
そうなってきますと、運用（Ops）チームの責任対象は、何らかの理由により自社のデータセンター（オンプレミス）で従来の手順での運用を続けざるを得ない領域に縮小され、その分予算や責任は開発（Dev）チームに重点的に配分されていきます。いきおい、クラウド技術を活かし動画配信サービスの領域で一時驚異的なペースで成長したNetflixの元エンジニアで、有名な「カオスエンジニアリング」を提唱したAdrian Cockcroft氏が”NoOps”を主張するに至ります。
これに対してはさまざまな反響がありましたが、なかでも手芸や古物の電子商取引サイトEtsyの元最高技術責任者（CTO）であるJohn Allspaw氏が「OpsDoneMaturelyButStillOps」つまり「運用は（成熟し）枯れてなお運用」として建設的な反論を試みています。その大意は概ね以下のようなものです。
まずNoOpsの主張の背景には、従来では当たり前に見られた、明確な役割と責任範囲の境界線で区切られたDevとOpsがもたらすさまざまな弊害があります。例えば、DevからするとOpsチームは現行システムを安定稼働させるために必要な消火活動にきゅうきゅうとしており、Opsチームに何かを依頼するための打合せや作業依頼書の作成一つをとっても多大なオーバーヘッドがかかるといった問題です。これに対し、EtsyではDevとOpsがフィードバックループを通じたコラボレーションにより、消火活動を事後対処的なものから予防的なものへ移行（シフトレフト）させることに成功しているとしています。
