ThoughtWorks技術雷達釋出四大技術趨勢

上周，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放在了“暫緩”次元上。

indiastack

indiastack是一組開放apis，由印度研發。open api驅動了印度政府在認證服務、數字簽名（esign），統一線上支付和電子合同層（e-kyc）上的一系列數字創新，可以使印度公民通過統一的id接入上述服務。

從這個層面上說，indiastack實際上代表一組關系國計民生的微服務規範，在此規範上可實作印度人民網上支付等需求，以及與每個人生活息息相關的功能和内容，形成這樣的規範其實是對每個公民的基本權利的保障。

由此，徐昊也得出一種反思——如果從政府的角度來講，個人身份除了在實際實體空間存在特定訓示外，難道不應該有一個開放網上服務，通過這種固定的身份表征讓個人快速接入或關聯一些政府相關的網站麼？

印度的indiastack是很好的技術實驗。它所傳遞的一種思想是：當我們真正見證到軟體正成為整個行業乃至社會的核心驅動力時，我們也應該思考，政府在網際網路環境中或資訊化時代裡應扮演怎樣的角色、處于怎樣的地位。

overambitious api網關

在亞馬遜提供了api網關後，很多的大型企業也希望自己有能力開發這樣的api網關（除了開源架構之外），他們不太滿足于使用現有的開源架構，或者直接購買亞馬遜的服務。

去年5月，thoughtworks在其服務的一家企業中發現，對方正開發一個所謂的微服務架構，該架構主要是提供分布式事務和服務事務處理，而裡面的“微服務”就是僅提供了資料crud操作，即上面提到的“貧血rest”服務，通過網關進行各種流程編排、功能聚合和事務處理，但最終結果的确失敗了。是以thoughtworks也提出，整個api網關應該是做輕量級服務的注冊和發現，過度龐大的api網關産品，其功能在本質上就是反向代理，這助長了難以測試和部署的系統設計。

本文轉自d1net（轉載）