觀點：有關DevOps的7個趨勢

爲了不成熟落後於人的痛苦，企業們紛紛開始實施並不斷改進本身的DevOps實踐。在這樣的環境下，運維和開發團隊必需要搞清楚技術的發展方向，以便在大潮到來的那一天作好萬全準備，或是在各方的大肆宣傳中保持冷靜的頭腦。

關於可能到來的挑戰和機會，咱們不妨來看看DevOps、雲計算、微服務架構、容器、無服務器等領域的專家觀點。

DevOps的明肯定義將終於成形

回顧過去，不少技術公司已經在DevOps轉型中掙扎多年了。J. Paul Reed，Release Engineering Approaches公司的任事股東認爲，DevOps的明肯定義將在2017年底終於成形。

「（DevOps）已再也不是新興現象，做爲一種原則和實踐的集合，它已經積累了大量的定義和代碼方面的工做。」

Reed認爲，DevOps的分歧窘境在於「衆說紛紜」。或許分歧在將來一段時間內仍將繼續，但你們廣泛接受的DevOps定義將逐漸造成，而其餘定義將隨之逐漸被淡化，「DevOps的最終定義是什麼？咱們如今已經開始關注了，但到了2018年給你一個準確回答。」

Jeremy Likness，是一位博客達人，同時仍是iVision的應用開發總監。他認爲DevOps的最終定義能夠總結爲：應用生命週期管理（ALM）新方法。

」企業會愈來愈看重敏捷性，並會意識到DevOps實際上是超越敏捷的ALM，而非擴展。做爲改變的一部分，Infrastructure as Code（Ioc）在持續交付pipelines中的地位將會愈來愈穩固「。

不會寫代碼的測試將被淘汰

TJ Maher，是一名自動化開發程序員。在過去兩年時間中，他花費了大量時間學習，以便讓本身從傳統的手動測試升級爲自動化開發。也就在過去兩年，他的不少測試崗位上的同事丟掉了工做，緣由正在於未能跟上測試行業現下正在發生的變革。

「持續集成和持續交付像是颱風同樣席捲了整個軟件測試行業，不少手動測試員都未能倖免。」

對於不少測試工程師來講，2016年留給你們的教訓即是：learn to code or perish。如今的測試工做幾乎全都集中在網絡服務層面，對於RESTFUL API需求極大，固然還有對於各類測試工具的使用要求。

C2 IT Solutions Consulting的全球QA測試實踐負責人Andy Tinkham相信，還有一個重要緣由能夠解釋QA專家爲何會在找工做時碰壁——測試的商品化。

Andy認爲，測試這一職業創建在，一家家企業中的高水平測試員施展他們在測試系統方面的知識和技能。

「咱們一直致力於讓測試變得可重複，每一個人均可以按圖索驥。咱們將測試工做與自動化方法結合起來，試圖把人類活動「翻譯」成腳本和一種開發文化，弱化了角色之間的界限，最終將測試行業商品化。

而結果是，愈來愈多的測試工做被自動化完成（固然，自動化不是萬能的），其餘崗位替代了本來測試工程師的任務。在一些案例中，測試工做被轉給了外包團隊。

Tinkham和Maher都說，2017年是測試工程師極爲關鍵的一年，大部分工做都比以往要求更高的專業度。

敏捷化運動「迴歸基本」

敏捷概念提出15年以後，敏捷和scrum被不少人認爲是最佳實踐，但也有不少人被教條的敏捷方法的負面影響整得精疲力竭。「咱們其實已經偏離的敏捷概念的核心，今年（2017年）也許會是屬於敏捷化運動‘迴歸基本’的一年。

Tinkham相信有兩件事會在行業內得到主流注意。一是Joshua Kerievsky's Modern Agile，二是Heart of Agile（Agile Manifesto signatory，Alisrair Cockburn）

不少敏捷大會都在談論這兩個理論，也爲精疲力竭的企業從新注入了活力。Tinkham表示，「估計這兩個理論會在將來12到18個月內開始影響主流的敏捷觀念」。

更多企業上雲

Cloud Technology Partner高級副總裁David Linthicum表示，「2017年會是大多數企業會大規模上雲的一年「。

」若是他們2016年把20個應用放在了雲端，那麼在2017年這一數字極可能會是500。「

企業使用雲的方式也會在今年逐漸開始改變。」傳統PaaS會逐漸失去競爭力，企業們會更傾向於容器化的解決方案，選擇可讓他們靈活、可自由移植的混合雲／多雲環境，同時使用一個或多個供應商的雲計算服務」，Likness說。

他補充說，但願看到更多的Linux商品服務器和組織利用.NET Core遠離對基於Windows的機器的依賴。 「更多的供應商不只將提供軟件即服務（SaaS），並且還將提供容器即服務，所以運行內部部署的客戶能夠輕鬆訪問一個正在運行的開箱即用的解決方案「。

對於微服務架構的追捧將趨於理性

「企業對於微服務架構的熱情從2016年起便不曾消減。對於不少應用來講，微服務架構的確是偉大的進步，但微服務架構並非‘magic bullet’」，Bluefin Payment Systems高級軟件工程師Marco Troisi表示。他和Netflix軟件架構師Paul Bakker都認爲對於微服務架構的追捧將在今年趨於理性。

Marco Troisi表示，「可能會有更多的人開始談論，某些應用並不適合微服務架構。同時，幫助咱們管理分佈式架構的工具將達到更高的成熟度，讓微服務相關的工做變得更簡單起來。」

Bakker表示微服務當然很棒，但不少人對於微服務的理解有誤差，也不明白架構和工具之間的區別，這也就致使了不少微服務架構被作成了SOA，也所以花了不少冤枉錢。

Red Hat架構師Christian Posta也表示，不少開發者看待微服務架構的方式有問題，「企業會開始認識到，Java並非微服務開發的最佳語言，但依然會在該方向上花費不少精力。」

Posta同時認爲像Netflix、Twitter這樣的著名公司也許會從新考慮他們的開源策略，這些公司不少時候更像是「隔着牆扔代碼」。

「這些改變是很關鍵的」，Posta認爲這些主流公司開源的工具和libraries可能會取代傳統供應商的中間件，而一些新興的創業公司會加速整個生態的造成。

容器和編排工具會變得更易用

Likness表示，雲計算巨頭在容器方面投入了大量的投資，容器集羣管理是供應商開發解決方案的關鍵部分。

Troisi指望toolmakers專一於如何把docker等容器變得更易用，他對docker-compose很期待，而docker-compose在2017年會變得更成熟、更適合生產環境。

「把docker命令存儲在Compose易讀的YAML文件中，會是開發者們更傾向的運行Docker應用的方式，而不是記住大量的、很差讀的命令行命令「，Troisi說。

Linthicum預測container的熱度會繼續增加，但也只集中在新建的應用上，「將舊應用容器化難度和花費都不小。「

Likness表示容器在去年逐漸成了許多開發流程的一部分，而今年則會成爲最重要的部分之一。

Kubernetes將成爲標準

Troisi預計，Kubernetes將成爲容器編排的行業標準，相關的研究彷佛也證明的這一說法。可是，Kubernetes的設置和使用相對來講還比較困難，所以基於容器的PaaS系統，如RedHat OpenShift、CoreOS Tectonic，將幫助企業進入Kubernetes和容器的世界。

Bakker贊成Likness對PaaS的「緩慢死亡」預測，但只適用於較舊的嚴格鎖定產品，例如Google AppEngine。他預計基於Kubernetes的PaaS產品，如Google Container Engine和OpenShift，將在2017年蓬勃發展。Posta預期也是如此：「Kubernetes正在統一容器，基於Kubernetes的PaaS提供商將得到比其餘公司更多的牽引力。「

好雨雲幫，深度整合Docker和Kubernetes，提供以應用爲中心的無服務器PaaS。

連接：https://www.goodrain.com

無服務器將大熱

無服務器（serverless）是IT界的最新熱點，有很大的潛力。Navica CEO Bernard Golden預計，無服務器技術的影響力將快速擴大並被企業所接受。

「無服務器擁有IT組織徹底擺脫基礎架構管理業務的潛力，並專一於應用程序開發和部署，雖然IT一直是不斷變化的領域，但明年將爲IT組織提供比以往任什麼時候候更多的機會和挑戰。「

軟件諮詢公司Cloudbox Systems的首席技術官兼首席數據系統顧問Dean Hallman一直在研究無服務器框架，他看到無服務器框架提供了更多的嚮導式體驗，並填補了主要FaaS提供商（如AWS Lambda，Azure功能和IBM OpenWisk）之間的功能差距，以便無服務器應用程序能夠從單個代碼庫中定位任何這些供應商的服務。

Hallman也指望無服務器對DevOps的演進產生重大影響。在之前由Ops和DevOps管理的域中，開發人員將比以往任什麼時候候都更加參與。 「大多數無服務器框架已經提出了一個無服務器友好的DevOps工做流程，」Hallman說，「2017是無服務器奠基基礎的一年」。

「將會知足無服務器框架，AWS SAM和AWS子賬戶的整合趨勢，以知足開發人員的訪問需求和DevOps的安全性要求。「

哈爾曼預計，微服務架構和容器化基礎架構將在2017年與無服務器融合。

總結

• DevOps中，Infrastructure as code是核心組件
• 測試人員不只須要懂測試，還須要瞭解編程，有能力構建應用
• 敏捷化運動‘迴歸基本’
• 企業應考慮靈活可移植的PaaS服務提供商，探索基於kubernetes的PaaS產品
• 不是必定要微服務架構，在實施前應準確評估
• 應該在生產環境中嘗試容器技術
• 開發和運維應該開始嘗試無服務器架構

Author Mitch Pronschinske

原文：https://techbeacon.com/7-devo...