DevOps與NoOps現狀分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建立了可複製的基礎設施(這幾乎是第一步的必要操作)。

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

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

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

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

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

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