在許多情況下，軟體有正當的理由必須更新。有時，軟體更新是為了提供原本已宣傳、但出貨時卻來不及加入的功能。因此，裝置開箱、連上網路、下載最新軟體以獲得最新功能，對今日的消費者來說就像家常便飯。但像這樣的更新不一定每次都很順利，有時候功能遠比預期還晚推出，或者功能根本就不如原先所預期。
除此之外，一些透過更新取得的功能，也可能導致不預期或不良的後果。例如：Spectre 漏洞最初的修正就會導致某些系統的效能變慢。除了 CPU 效能問題之外，有些案例是儲存效能也受到影響，而這又可能進一步影響系統的其他效能，因為資料讀取速率突然變慢。
大體而言，裝置能自動更新對使用者來說是件好事。許多裝置軟體所發生的問題，可透過更新來修正當然最好。只不過，軟體更新有時候也可能反而讓裝置變得無法使用。這樣的問題通常是因為更新規劃不當，或是硬體上的變異所造成。例如裝置用到一些不良 (或仿冒) 的晶片 (這樣的情況並非罕見)，所以才會讓裝置在更新後出現異常行為，甚至變成磚塊 (完全不能用)。
此外，更新流程的安全性，也必須經過審慎規劃和妥善協調。如果有緊急變更的話，也必須考量用戶端和伺服器的更新順序。此外，對於大型企業環境，要讓所有裝置都在同一時間更新，可能會發生無法負荷的情況。尤其，伺服器的更新通常較為複雜，但許多時候卻必須先將伺服器更新之後才能更新用戶端。
要在這麼多的依存狀況下正確安排更新的先後順序，已經快變成一項不可能的任務。不僅如此，開發營運 (DevOps) 環境的伺服器更新已經不再是絕對不可逆的程序，企業經常會試探性更新看看有沒有狀況，如果萬一出了問題，就回復到先前的狀態。雖然這樣的策略聽起來大致可行，但有時卻會讓人懷疑是否該花力氣去擬定一個可能不會執行的計劃。
移轉至「一切皆由軟體定義」(Software-Defined-Everything) 的模式，意味著專業人員必須具備工程師一樣的思考能力
我們的世界正相當程度地朝一切由軟體定義 (Software-Defined-Everything) 的模式發展，而 DevOps 或許是始作俑者。雲端運算的潮流，帶來了透過程式設計來定義及部署系統架構的概念，包括：在基礎架構服務 (IaaS) 平台上部署虛擬伺服器、在平台服務 (PaaS) 平台上部署虛擬應用程式，以及將軟體服務 (SaaS) 中的應用程式虛擬化以實現零伺服器的架構。
儘管這一切都能透過網頁控制台來管理，但其背後卻相當複雜，需要透過某種形態的程式碼來部署與管理這些架構。而且這些程式碼必須設置在雲端服務所部署的程式碼之上。換句話說，就是透過雲端廠商的程式碼來提供服務給客戶當中負責部署與管理應用程式的架構。不僅如此，雲端廠商也可提供某種形式的軟體定義網路來管理架構元件之間的網路。所以，就 DevOps 的角度來看，雲端架構從頭至尾都是軟體定義的，因此在面對新的狀況時，只需修改幾行程式碼就能迅速因應。而更先進的作法是讓系統能自行調整架構，如此一來，系統架構設計師的工作就變成了建立一套管理這些架構的機器學習系統。
「軟體定義網路」已經在各種不同產業中實踐，進而奠定了「軟體定義系統」的基礎。新一代的電信架構甚至將此列為標準規格，並且加入了協調機制。所以，未來 5G 系統將可視需求而快速進行底層架構的調整。在工業領域，隨著工廠不斷進化，再加上工廠對彈性和效率的需求越來越高，它們也逐漸朝軟體定義的方向發展。某種程度而言，今日的工業機台已經可以套用數個電腦數值控制 (CNC) 程式，不過，未來的工廠需要更加彈性的程式化來隨著手上的工作和環境而調整。將來，工廠管理員的工作將更像一位 DevOps 工程師，運用軟體來動態管理實體工作流程。
不久的將來，每一位專業人員都將必須具備像工程師一樣的思考能力。或許程式「語言」會隨著應用領域而改變，但所有軟體的弱點都將與他們的工作如影隨形。這些專業人員必須同時兼顧自身的專業領域與軟體開發，而這得靠專門的訓練來達成。
下期待續:軟體無所不在(5-5):軟體高度普及的三大缺點與對策