很抱歉，我為了吸引注意力，用了這個詭異的標題。時下的IT趨勢中，DevOps 正是一個熱語。它起源于幾年前SPA (單頁面應用) 的前端應用.我認為常態的IT技術適應就是，在新技術爆發的那一時刻開始，立馬就會被敏銳的人們所采用，然后被快速傳播開來。最近幾年的DevOps 就是這樣的。但再過幾年，你將會聽到另外一個流行詞：NoOps。

DevOps和 NoOps的差異

DevOps是開發和運維的融合，是開發和運維工程師共同協作，定義應用從設計到交付全生命周期過程的實踐。

NoOp的意思是無須操作。它的理念是去掉所有的平臺管理部分，從而降低開發人員與基礎設施之間的摩擦。

為何需要DevOps?

隨著技術和業務需求越來越具有挑戰性，IT服務也變得越來越復雜。這使得交付變得越來越重要，也讓我們不得不投入精力來編排整個應用交付過程。

有了云平臺之后，對系統管理員需求開始下降，但對DevOps技術和業務技能的需求依然很高。要實現DevOps并恰如其分的使用它。這讓我們需要考慮技術交付之外的情況。

為何以前沒有DevOps?

答案有很多個，你可能會說以前的業務場景更簡單或沒有足夠的技術文化氛圍。我很認同上述觀點，但我認為那些不是根本原因。根據我的經驗，更大的原因應該是技術。交付的自動化其實是很難實現。

十年前的大多數系統，在默認情況下，都沒有一步構建或如git-flow一樣定義良好的工作流。當時也沒有高性價比的CI解決方案，所以難以實現自動化交付。

我記得2009年，我打算部署我自己的一個.net門戶。我花了一個周六的上午嘗試使用開源工具創建一個自動部署系統，但最后我還是放棄了。因為我知道維護自動化交付比手動部署它的成本要高得多。到了現在，如果使用Azure DevOps服務的話，我只需使用web瀏覽器就可以在十分鐘內完成。果然是時過境遷啊!

為何我所需的比DevOps能做到的要多?

這個原因很好理解，當你歷經波折將DevOps引入到你公司后，你可能會認為狀態良好啦。但是事實卻是IT世界，事物的變化比人快，現在市場需求越發火爆，不斷的需求帶來了不斷的變化和調整，而你不能簡單的應對一句：“我已經疲于應付變化，需要歇一下。”

云時代的到來讓事情變得更加復雜。它讓我們得以實現復雜的解決方案并解決許多挑戰，但也需要我們具備更多的技能。

云端的所有組件都是可伸縮的，但是它會牽扯到某些DevOps的配置，既總是需要一些手工干預，在大部分流程運轉的背后，仍然需要有人參與。可以理解為這還是舊的工作模式。

NoOps的目的是定義一個不需要開發與運維相結合，就可以使流程順利進行的過程。NoOps有一個目標:通過設計使所有東西都可以完成部署，而不需要任何人參與。

NoOps大致的方法如下:開發人員將代碼提交到代碼庫就已經完成了全部的部署。看起來與連續交付非常相似，但它所包含的范圍更大，這里面不僅有應用程序，還包含了基礎設施的部署。

NoOps是如何做到的?

相對于DevOps, NoOps是需要技術支持的。這個支持有很多選擇，但基本上，我們可以總結如下:

NoOps是一個PaaS解決方案，像 Heroku或由Azure, AWS等云服務商所提供。

從AWS,Azure等服務商處購買的無服務器計算服務。

創建了可復制的基礎設施(這幾乎是第一步的必要操作)。

上述類似的方案很適合解決基礎設施部分的工作，而讓傳統部署工具能夠推動流程處理，交付應用。

閃光的未必都是金子

我坦承，取消基礎設施管理的想法很有誘惑力，感覺就像拔掉一顆壞牙。因為在通常情況下，基礎設施占用了大量的管理成本，還帶來了開發和運維之間的摩擦。

但另外觀點是，問題不在于基礎設施，而在于流程。如果流程設計良好，就不會有摩擦，不會有延遲，一切都可以有條不紊的進行。

你會擔心管理成本嗎?其實你應該考慮整體成本，而不僅僅是管理成本。也許您云上基礎設施的管理成本更高，但最終的成本會是相同的。但這也不絕對。困惑嗎?這其中的秘密就是有些應用程序可以部署在PaaS上，有些則不能。僅此而已。如果您的應用程序很簡單，那么PaaS是一個很好的解決方案，DevOps人員將樂于減少工作量。但如果你要推出的是下一個Netflix，那你將需要更多的控制權利，PaaS服務就沒那么貼切啦。這就是根源所在。

說到最后，其實無所謂DevOps或NoOps。最根本的驅動是:用盡可能少的維護工作,去創建智能的基礎設施，并將一切自動化。使用如谷歌云或其他的公有云服務，您都能為你的應用場景找到最佳的解決方案。

那么，從這個角度來看，什么是NoOps?本質就是云化趨勢中的另一個流行詞。