上周,ThoughtWorks在北京發布了其最新一期的技術雷達。會上,ThoughtWorks中國區CTO徐昊和中國區高級敏捷咨詢師陳加興分別對該期技術雷達所包含的四大主題及接下來可能會產生“浪潮效應”的一些技術趨勢進行了分享。InfoQ也對兩位的預測觀點做了梳理和總結,以為軟件開發者和決策者提供可借鑒的行情統計和經驗洞察。
ThoughtWorks技術雷達擬定依據
ThoughtWorks在每年都會出品兩期技術雷達,這是一份關于技術趨勢的報告。相對于一些根據量化指標制定而出的分析報告和行業預測報告而言,技術雷達中的象限和條目均由行業內一線工作者的經驗和具有洞察力的人員篩選得出。他們根據對軟件研發的理解和判斷,對技術進行過濾,最終擬定而成。徐昊相信,統計數據不能代表任何問題,富有洞見力的一線工作人員以及對軟件開發有著充分運用、領先理解的開發者,其所持觀點才能為行業預測帶來更精準的價值,并將其積累的真實經驗帶到更多的技術開發者和決策者面前。
11月期技術雷達圖概覽
本期技術雷達依舊是以技術、工具、語言和框架、平臺四方面內容為切入方向,同時每個象限內又由中心向四周依此分為“采用”、“試驗”、“評估”、“暫緩”四大維度,以通過這四大不同維度表示每一項技術的成熟度。
用徐昊的話來解釋,即在“采用”象限里的技術條目,只要場景恰當,就應該是技術開發者或決策者選擇采納的默認選項。“試驗”環里,強調的是這項技術擁有足夠的成功可能性,它們大多屬于較新的技術領域,有較大發展潛力,只要在合適且風險可控的情況下,開發者即可嘗試使用。此外,“評估”和“暫緩(proceed with caution)”象限則需要開發者對收益、風險、成熟度等條件評定下再謹慎使用。
通過直觀的圖形展示,技術雷達能將相關領域中值得注意的或新的技術提煉并表述出來。例如這一次在“采用”環的14項技術條目中,就有9項是新入圍條目,包括Pipelines as code、Babel(JavaScript編譯器)、Grafana(白板生成工具)等。
四大主題預示下一波技術浪潮
根據對技術雷達上眾多技術條目的總結,ThoughtWorks也看到行業內一線在軟件開發及使用上的整體情況和趨勢,從而總結了本期技術雷達的四大主題。
容器即進程,PaaS即機器,微服務架構即編程模式目前行業內一批企業客戶在引入容器時,常把Docker按照以前虛擬機的使用方式加以同等對待,將應用程序部署在Docker中。因此,ThoughWorks提出要將Docker設想為一個進程,可以在任何地點隨時啟動并銷毀,不會隨著業務遷移而增加搭建時長。
其次,ThoughWorks也發現許多大型企業正將開發者工具部署在他們自身平臺內,從而形成了一整套開發語言生態。因此,PaaS應該就是一個部署目標平臺,并非圍繞開發者提供的工具,或者是一些在線開發工具。
此外,由于容器化和強調松耦合,微服務風格的架構呈現了一個更抽象的開發者世界,為企業提供了更高層次的運行隔離。在ThoughWorks總結中,決策者應將微服務架構看作新的編程模式,這也意味著需要拋棄以前一些舊的觀念,去認知和實踐微服務這種新架構模式。
智能釋放的力量隨著Nuance Mix和TensorFlow等通過框架進入到實用領域,以前看上去很復雜的人工智能、機器學習等技術,也因為云計算和智能算法具體數據的大維度開放,離商業應用越來越近。而這些因素的綜合演變也將促成一系列新的工具,包括商品計算、特殊定制的硬件(如GPUs)、云端資源等。
團隊結構的全局影響面向企業客戶的市場一線團隊,不再是只有短暫生命周期的項目團隊,而要把互聯網的產品思維引入到企業級項目中來,即產品思維高于項目運作。其次,應該在企業級項目里構建全功能團隊,項目團隊要建全自己的力量,向產品團隊靠攏,把互聯網的產品思維真正引入到內部IT項目中。例如,這兩年ThoughtWorks一再強調,微服務不僅僅是一種技術,而是將它看作重新構建一線開發團隊戰斗力的一種文化或方法。
AR/VR漸入佳境雖然像OpenVR和Unity這樣的軟件開發平臺已非常成熟,但新的NLP工具及硬件提供的接近自然的交互,為AR/VR技術的采用提供了較大助力。在建立實驗室探索下一代應用時,ThoughtWorks發現,由于通過抽象介質向用戶直接傳遞沉浸式體驗,因此VR在遠程協作和講述時有驚人的移情作用。但同時挑戰也在于,創作和交付VR/AR內容應用的技能和能力遠遠跟不上硬件發展的步伐。
枚舉最令人興奮的幾大技術條目
在ThoughtWorks團隊梳理出110項技術條目同時,徐昊和陳加興也對其中幾項較新或具有較大拓展潛力的技術模型進行了解讀和分享,例如Anemic REST、APIs as a product、IndiaStack、CMS as a platform等。
這些模型大多分布在“試驗”、“評估”、“暫緩”三大維度內。這也意味著,即使很多技術條目在目前階段并沒有龐大的利益產出以證明其未來可能釋放的價值,但其形成的影響并不會掩埋其創新上的成敗。限于文章篇幅,InfoQ主要選取了分享中三則較為典型的技術成果進行展示。
Anemic REST(貧血 REST)談論微服務越來越火熱的今天,很少人會想到其技術是基于RPC的調動方式實現的。而REST里面最吸引人的地方,即它屬于遷移或遷轉的一種過程,可自然的鑒定業務的當前及未來的狀態,使企業劃定業務的場景和業務邊界,從而幫助企業更好的描述現在所產生的業務模型。
但一部分批評者職責REST導致了系統間繁瑣低效的交互,且無法適應客戶端需求的變化。ThoughtWorks發現,這類問題出現的根源并不在REST本身,而是源于未能將領域作為一組資源來正確建模。通過模板化的URL、簡單地暴露靜態分層數據模型開發一個服務,會導致出現貧血REST。貧血REST是一個反模式,它與貧血領域模式密切相關,根據它所設計出來的服務,在Richardson成熟度模型中,會處于成熟度較低的層次。
此外,RSET雖然能非常忠實的反映頁面上的各類交互。但如果核心API是圍繞極易發生變化的UN交換設計,那變化快速的APIs將無法跟隨企業的發展和業務模式的轉變一起成長。這樣,REST承諾的優點就無法恰當表現。因此,ThoughtWorks將貧血REST放在了“暫緩”維度上。
IndiaStackIndiaStack是一組開放APIs,由印度研發。Open API驅動了印度政府在認證服務、數字簽名(eSign),統一在線支付和電子合同層(e-KYC)上的一系列數字創新,可以使印度公民通過統一的ID接入上述服務。
從這個層面上說,IndiaStack實際上代表一組關系國計民生的微服務規范,在此規范上可實現印度人民網上支付等需求,以及與每個人生活息息相關的功能和內容,形成這樣的規范其實是對每個公民的基本權利的保障。
由此,徐昊也得出一種反思——如果從政府的角度來講,個人身份除了在實際物理空間存在特定指示外,難道不應該有一個開放網上服務,通過這種固定的身份表征讓個人快速接入或關聯一些政府相關的網站么?
印度的IndiaStack是很好的技術實驗。它所傳遞的一種思想是:當我們真正見證到軟件正成為整個行業乃至社會的核心驅動力時,我們也應該思考,政府在互聯網環境中或信息化時代里應扮演怎樣的角色、處于怎樣的地位。
Overambitious API網關在亞馬遜提供了API網關后,很多的大型企業也希望自己有能力開發這樣的API網關(除了開源框架之外),他們不太滿足于使用現有的開源框架,或者直接購買亞馬遜的服務。
去年5月,ThoughtWorks在其服務的一家企業中發現,對方正開發一個所謂的微服務框架,該框架主要是提供分布式事務和服務事務處理,而里面的“微服務”就是僅提供了數據CRUD操作,即上面提到的“貧血REST”服務,通過網關進行各種流程編排、功能聚合和事務處理,但最終結果的確失敗了。所以ThoughtWorks也提出,整個API網關應該是做輕量級服務的注冊和發現,過度龐大的API網關產品,其功能在本質上就是反向代理,這助長了難以測試和部署的系統設計。