• 無服務器計算,或者功能即服務(Functions-as-a-Service,以下簡稱FaaS),未來將會改變我們的產(chǎn)業(yè)鏈,凡是基于它的企業(yè)或者組織,最終會受益于它在價格、人力,以及上市時間等方面帶來的競爭優(yōu)勢.
• 許多無服務器應用程序,未來將會對FaaS和其他第三方提供的服務進行組合,以便提供功能預管理和狀態(tài)管理.
• 工具會有極大地提升,特別是在部署和配置方面.
• 較好的無服務器架構模式稍后就會出現(xiàn),現(xiàn)在了解細節(jié)為時過早.
• 未來需要基于真正的DevOps概念,無服務器可以提供的所有市場效益,最終將會被擁有自己管理能力、自給自足的產(chǎn)品團隊所收獲.

現(xiàn)在是2017年,距離兩年前無服務器計算革新只取得了少許進展(你聽見人們在唱歌嗎?).這次變革并不是像Docker那樣突飛猛進地前進,而是采用了相對平穩(wěn)的發(fā)展節(jié)奏.Amazon新發(fā)布了Web Services的Lambda特性,產(chǎn)品保持了一個有規(guī)律的發(fā)布節(jié)奏,另一個重要的第三方(微軟)正在一個接一個地發(fā)布生產(chǎn)環(huán)境版本,也有一些新的開源項目頻繁地加入這場盛宴.

當我們接近早期階段的末尾時,來做一個有趣的游戲,讓我們戴上預測護目鏡(開個玩笑),深入思考下一步會走向哪里,如何走到那一步,以及我們的組織需要去做什么來支持這一步的到來.所以,加入我們,讓我們看看無服務器計算未來可能發(fā)生什么.

讓讀者了解真實的未來!你可以通過閱讀這篇文章開始了解細節(jié).我們離無服務器還有多遠?2020年怎么樣?請寄一張明信片給我!

無服務器能力展望

計算

過去十年我們目睹了云計算的出現(xiàn),然后它迅速地異軍突起.9年以前,虛擬公有云服務器還只是手上的玩具而已,但是在相當短的時間里,當我們考慮任何新的部署架構方案時,它變成了大多數(shù)行業(yè)的首選平臺.

無服務器計算,或者Functions-as-a-Service(Faas),當我們考慮“IT”如何變化時,它會是這次重大變化的最新出現(xiàn)部分.這次變革是一次我們一直以來所期待的自然過程,從我們?nèi)绾谓桓稇贸绦蚪o客戶開始,到希望能夠刪除所有的部件和基礎設施.

我們開發(fā)的相當一部分應用程序,是由許多小的組件所組成的.每個這樣的組件包含了一個小的輸入集和上下文信息,需要消耗10毫秒或100毫秒完成組件的一些內(nèi)部工作,最終可能反饋一個結果,也可能更新相關內(nèi)容.這類場景最適合無服務器計算.

我們預測未來由于FaaS在部署上的方便、快速、廉價,會有越來越多的團隊基于FaaS開發(fā),這樣便于管理和擴展基礎設施.我們對FaaS可以有很多種使用方式,包括：

• 由大量的順序消息處理器所組成的完整的后端數(shù)據(jù)管道
• 通過HTTP API調(diào)用的同步服務
• 通過獨立的膠水代碼提供針對部署、監(jiān)控的自定義操作邏輯
• 對于計算密集任務,由實體服務器直接調(diào)用平臺縮放功能組成的混合動力系統(tǒng)

使用FaaS的企業(yè)相較沒有使用的企業(yè)具有競爭優(yōu)勢,包括價格、投向市場時間等.

管理應用程序狀態(tài)

廣泛采用FaaS的一個先決條件是針對快速而簡單的狀態(tài)管理方法的解決方案,或者一系列解決方案.無服務器計算是一種無狀態(tài)模式.我們不能假定任何有用的狀態(tài)存在,即不存在即時執(zhí)行環(huán)境內(nèi)不同的運行時調(diào)用之間的有用狀態(tài).一些應用程序在這種限制下依然適用.例如,單純進行數(shù)據(jù)轉換的消息驅動組件不需要訪問外部狀態(tài),擁有無限制響應時間需求的Web Service組件,其每一次調(diào)用時需要連接到一臺遠程數(shù)據(jù)庫,這種做法也是可以接受的.但是對于其他應用程序來說,這種限制就顯得有些不足了.

解決這類不足的一種方案是混合動力系統(tǒng),即在不同類型的組件里管理狀態(tài),而不是執(zhí)行我們的FaaS代碼.比較流行的混合動力方案是通過云端基礎設施提供其他服務的前端FaaS功能.我們已經(jīng)見到了這種類似于API網(wǎng)管的特定上下文邏輯的組件,它們提供了HTTP路由、授權,以及我們經(jīng)常在典型的Web Service里看到的節(jié)流邏輯,采用定義替換配置方式實現(xiàn).Amazon最近也在管理狀態(tài)的通用方式上露了一手,使用他們的Step Functions服務,允許團隊基于可配置的狀態(tài)機器定義應用程序.Step Funcations服務本身可能沒什么過人之處,但是通常情況下這種無碼解決方案是很受歡迎的.

當供應商服務不充足時,對于混合動力系統(tǒng)來說,一種改變方式是團隊堅持開發(fā)追蹤狀態(tài)的長生命周期組件.這些組件可能被部署在CaaS(容器即組件,Containers-as-a-Service)或者PaaS(平臺即組件,Platform-as-a-Service)環(huán)境,和FaaS功能協(xié)同工作.

這種混合動力系統(tǒng)組合了長期運行的組件邏輯和每一次FaaS功能請求邏輯.另一類做法是完全地聚焦于FaaS功能,讓這些FaaS功能超越它們當前執(zhí)行的環(huán)境,極其快速地獲取和持久化狀態(tài).一種可能的實施方式是確保一個特定的FaaS功能,或者一系列FaaS功能,確保它們擁有類似于Redis這樣的外部緩存機制,起到低延時訪問作用.通過啟動類似于Amazon的same-zone plancement groups(置放組群)這樣的特性可以做到這一點.雖然這種解決方案較內(nèi)存/本地磁盤狀態(tài)方案來說有些延遲,但是很多應用程序會認同這種解決方案.

混合方法的好處是經(jīng)常被訪問的狀態(tài)可以和邏輯一起保存在環(huán)境當中,那樣并不復雜,但是可能有點貴,必須要有邏輯網(wǎng)絡選址和外部狀態(tài).另一方面,一個單純的FaaS方式的有點是更加一致性的編程模型,外加無服務器帶來的更為寬廣的伸縮使用和可操作性優(yōu)勢.當前的發(fā)展勢頭顯示最終混合方式會勝出,但是我們也應該對其他方式開放,比如類似于啟用置放群組Lambdas.

無服務器協(xié)作服務

超越業(yè)務管理和狀態(tài)管理,我們可以預見到其他組件的服務化和商業(yè)化,即使在云端環(huán)境,傳統(tǒng)意義上我們希望開發(fā),或者至少自己管理這些服務.例如我們可以停止運行在EC2機器上面的Mysql數(shù)據(jù)庫服務器,轉而使用Amazon的RDS服務器,我們可以使用Kinesis替換我們自管理的Kafka消息總線安裝程序.其他的基礎設施服務包括文件系統(tǒng)和數(shù)據(jù)倉庫,而更多的面向應用示例包括認證和語音分析.

這種趨勢還會繼續(xù),我們需要進一步地減少創(chuàng)建或者維護產(chǎn)品所帶來的工作量.我們可以設想更多的預安裝的消息邏輯(把Apache Camel想象成服務,構建到Amazon Kinesis或者SQS里面),并且進一步開發(fā)通用機器學習服務.

這里比較有意思的一個想法是FaaS功能,由于它們輕量級的應用模式,可以將自己緊緊地綁定一個服務,使得FaaS調(diào)用服務功能的生態(tài)環(huán)境時可以調(diào)用其他的FaaS功能,諸如此類等等.這會導致“有趣的”級聯(lián)錯誤問題,對于這種錯誤我們需要更強大的監(jiān)控工具,會在本文稍后介紹.

站在數(shù)據(jù)中心后面

目前來看,絕大多數(shù)的無服務器計算是運行在供應商數(shù)據(jù)中心平臺上的.這就給出了一個替代方案,即如何運行你的代碼,而不是在哪里運行代碼.Amazon發(fā)布了一個有趣的新特性,即是允許它們的客戶在不同的地點運行Lambda函數(shù),例如,和Lamdba@Edge一起運行在CDN內(nèi),甚至在無服務器地點,例如,和Greengrass一起運行的物聯(lián)網(wǎng)(IoT)設備.這樣做的原因是,Lamdba是一個極端輕量級的編程模型,本質上的事件驅動的,并且非常容易適配相同的知識理念、新地點的代碼風格.Lambda@Edge是一個特別有趣的例子,因為它提供了在一個地點進行程序定制的可選項,這在以前是沒有出現(xiàn)過的情況.

當然,這種做法的缺點是和供應商深度綁定!對于那些不想使用第三方平臺,但是又想利用無服務器計算優(yōu)勢的廠商來說,有一種可以接受的解決方案,類似于Cloud Foundry已經(jīng)推出的PaaS.來自Kubernetes的Galactic Fog、IronFunctions以及Fission,是這種方案的早期作品.

我們將來需要的工具和技術

正如我之前描述的,這里有一個明顯的減速,使用無服務器方式時存在條件限制、性價比權衡.天下沒有免費的午餐.對于已經(jīng)過了早期適應階段的無服務器用戶來說,我們需要解決或者緩解這些問題.所幸,這方面目前發(fā)展勢頭良好.

部署工具

使用AWS的標準工具向Lambda部署函數(shù)挺復雜的,也比較容易出錯.向API網(wǎng)關中添加Lambda函數(shù),以響應HTTP請求,你更多要做的工作是安裝和配置.無服務器和ClaudiaJS開源項目項目已經(jīng)推動部署改進措施達一年之久,AWSSAM(AWS無服務器應用模型)也在2016年加入到了這一行動.所有這些項目通過在AWS標準工具的頂層增加大量自動化程序,簡單化了無服務器應用程序的創(chuàng)建、配置和部署.但是我們還有很多工作要做.未來將會有兩個關鍵動作實現(xiàn)完全自動化：

• 初始化一個應用程序或者環(huán)境的創(chuàng)建(例如,初始化生產(chǎn)環(huán)境,以及初始化臨時測試環(huán)境)
• 持續(xù)多部件應用程序的交付/部署

第一條很重要,我們也已經(jīng)開始認識到,以便更廣泛地推廣“生產(chǎn)提前期概念”.部署一個全新的無服務器應用程序應該是像創(chuàng)建一個新的Github倉庫一樣容易,填充少量字段,然后按下按鈕,通過這種一鍵部署方式讓系統(tǒng)自動創(chuàng)建你所需要的所有東西.

然而,光有簡便的初始化部署方式是不夠的.我們也需要有比較好的工具,支撐前面提到的混合動力系統(tǒng)的持續(xù)交付和持續(xù)部署.這意味著我們應該可以部署一系列的計算函數(shù)以及CaaS/PaaS組件,連同所有應用程序封裝服務的變化(例如,在一個API網(wǎng)關配置http路由,或者一個被單一應用程序使用的Dynamo表),一鍵生效和回滾能力.此外,這些動作都不應該是很費腦力去理解的,也不會需要幾天時間去完成安裝和維護任務.

這是一個很艱難的抉擇,但是我前面提到的工具(類似于Terraform這樣的混合動力工具)正在指引解決這些問題的方式,我完全相信他們在未來的幾個月或者幾年時間里可以在很大程度上解決問題.

本文不僅僅討論部署代碼和配置服務.其他一些操作上關心的問題也會被討論.安全問題是一大問題.當前,獲取AWS憑證、角色,以及設置和維護都可能是一大麻煩事.AWS擁有一套完善的安全模型,但是我們需要一個工具,這個工具可以讓這套安全模型對于開發(fā)人員來說更加友好.

總之,我們需要開發(fā)人員在開發(fā)他們的Webtask產(chǎn)品時,做到UX和Auth0都很好,就像AWS一樣的寬廣而有價值的生態(tài)系統(tǒng).

監(jiān)控、日志和調(diào)試

一旦我們的應用程序被部署完畢,我們就會需要針對監(jiān)控和日志的良好的解決方案,這類工具目前有幾個組織正在嘗試積極地發(fā)展著.除了評估其中一個組件的功能,我們也需要號的工具追蹤請求,這些請求穿越了一個完整的多個無服務器計算功能和配套服務體系的分布式系統(tǒng).Amazon正在將X-Ray推向該領域,目前說這個還有點為時尚早.

調(diào)試也是挺重要的.程序員很少在第一次代碼運行通過之前不犯錯誤,我們也別寄希望于這種情況會有所改變.我們依賴于監(jiān)控,在FaaS功能的開發(fā)階段評估問題,但是這種調(diào)試方式是石器時代的工具.

當我們調(diào)試傳統(tǒng)的應用程序時,我們從IDE工具那里可以得到很大的支持,通過設置斷點、單步調(diào)試代碼,等等.使用現(xiàn)代化的基于Java的IDE工具,你可以綁定一個正在運行的遠程進程,并且遠程執(zhí)行調(diào)試工作.因為我們更加傾向于使用云端部署的FaaS功能完成大量的部署工作,希望未來你的IDE工具也可以具有類似的功能,可以連接到一臺正在運行的無服務器平臺,查詢每個功能的執(zhí)行情況.這需要工具和平臺開發(fā)商之間的協(xié)作,如果想要讓無服務器被廣泛采用,這些措施都是必要的.這些想法對于云計算來說有一定開發(fā)工作量,也有大量的測試工作量.

測試

我到目前為止所討論的所有關于無服務器工具的話題,我認為最落后的是測試工具.值得關注的是,無服務器方案較傳統(tǒng)解決方案來說有著相當大的測試優(yōu)勢,主要是兩點,(a).無服務器計算的各個功能的單元測試很成熟,(b).無服務器服務寫的代碼更少,并且至少在單元測試層面,只需要做簡單的測試.

但是這并沒有解決跨組件功能/集成/驗收/業(yè)務流程等測試問題.無服務器計算時我們的邏輯是分散在幾個函數(shù)和服務內(nèi)的,因此,更高級別的測試甚至比使用接近單一方法的組件更重要.當我們?nèi)绱艘蕾囉谠谠贫嘶A設施上運行時,我們應該怎么做呢?

對于我們來說,測試可能是最沒有看清楚的.我猜測未來基于云端的測試會變得很普遍.這一部分會變得更加容易部署、監(jiān)控,以及調(diào)試我們的無服務器apps,甚至于比我現(xiàn)在描述的這些原因更加豐富.

換句話說,為了運行更高級別的測試,我們將會部署整個生態(tài)系統(tǒng)的一部分到云端,并且對部署在那里的組件執(zhí)行測試用例,而不是針對部署在我們自己開發(fā)機器上的系統(tǒng)運行測試用例.這種做法有一定的優(yōu)勢：

• 執(zhí)行部署在云端的組件的真實度較本地模擬來說更高.
• 我們較過去,更有可能可以運行高負載/高豐富度數(shù)據(jù)測試.
• 生產(chǎn)環(huán)境數(shù)據(jù)源的測試組件(例如,一個發(fā)布訂閱模式的消息總線,或者一個數(shù)據(jù)庫)會更加容易,雖然顯而易見我們需要關注能力/安全問題.

但是這種解決方案也有弱點.首先,執(zhí)行測試的周期時間很有可能由于部署和網(wǎng)絡延遲而相應增加.其次,當網(wǎng)絡連接中斷以后,我們就不可以繼續(xù)運行測試用例了(例如,在飛機上).最后,因為生產(chǎn)環(huán)境和測試環(huán)境最終部署方案很相近,我們也需要格外小心,當我們打算改變測試用例時,不要發(fā)生不小心改變了生產(chǎn)環(huán)境的事故.如果我們使用AWS,我們可能需要通過類似于IAM角色這樣的工具安全地部署,或者對于不同類型的環(huán)境使用完全不同的賬號進行部署.

測試并不僅僅是一個二進制程序運行成功或者失敗,我們也想要去弄清楚測試是如何失敗的.我們應該可以調(diào)試本地運行測試和正在運行的遠端組件,包括可以單步調(diào)試一個運行在AWS上的Lambda函數(shù),因為它可以相應測試.所以所有的遠端調(diào)試,例如,我前面章節(jié)提到的工具也需要測試,而不是僅僅交互式開發(fā).

請注意,我并不是基于這些暗示我們的開發(fā)工具需要運行在云端,也不是測試本身需要運行在云端,雖然兩者將來都會或多或少地走到這一步.我只是表示正在測試的系統(tǒng)僅運行在云端,而不是一個非云端環(huán)境.

使用無服務器作為測試驅動環(huán)境可以收獲有用的結果.一個例子被稱為“無服務器火炮”,這是一種負載測試工具,由運行著的許多并行的AWS Lamdbas組成,執(zhí)行即時、廉價、易于擴展性能測試規(guī)模的負載測試用例.

值得指出的是,在某種程度上,我們避免了一些失誤.由于技術進步,傳統(tǒng)的高層及測試實際上正在變得不那么重要,例如(a)生產(chǎn)環(huán)境測試/使用監(jiān)控驅動開發(fā),(b)平均解決時間(MTTR)的顯著降低,(c)基于持續(xù)部署.對于許多的無服務器apps應用廣泛的單元測試,度量業(yè)務水平的生產(chǎn)環(huán)境監(jiān)控&預警,以及一個專用于減少MTTR和基于持續(xù)開發(fā)的方法,都將會是有效的代碼驗證策略.

架構：有很多問題需要回答

系統(tǒng)架構較好的無服務器應用程序是怎樣的?是如何演變的?

我們正在逐漸看到一些無服務器被有效地應用的案例,即系統(tǒng)架構的學習案例正在逐漸增多,但是我們還沒有看到針對無服務器Apps的“模式組”.在2000年早些時候,我們看到了一些這方面的書,比如Fowler的《Patterns Of Enterprise Application Architecture》,以及Hohpe / Woolf的《Enterprise Integration Patterns》.這些書著眼于很多項目,派生出橫貫不同領域的通用系統(tǒng)架構知識.

重要的是,在做出統(tǒng)一意見之前,這些書著眼于基礎工具幾年的使用經(jīng)驗.無服務器技術存在時間太短,還不足以需要編寫一本書進行描述,但是這一時刻正在逼近,一年內(nèi)我們會看到一些有用的實踐案例出現(xiàn)(當無服務器架構需要出一本高調(diào)的書時,大家一般會選用“最佳實踐”這樣的術語描述).

系統(tǒng)架構之后(即無服務器應用程序是如何被構建的),我們需要思考部署系統(tǒng)架構(無服務器應用程序如何部署).我已經(jīng)談了一些部署工具,但是我們可以如何使用這些工具呢?例如：

• 環(huán)境這樣的術語在世界上意味著什么?“生產(chǎn)”看上去較過去有點不明確.
• 什么是一個軟件棧的side-by-side部署?看上去像是從一組功能/服務版本緩慢地移動業(yè)務到另一組功能/服務版本(滾動部署)?
• 世界上有么有類似于“藍-綠”這樣的部署方式?
• 現(xiàn)在的回滾方式是怎樣的?
• 我們?nèi)绾喂芾頂?shù)據(jù)庫的升級/回滾,當我們可能有多個不同的代碼生產(chǎn)版本,并且這些版本在同一個功能內(nèi)運行,這類有狀態(tài)組件應該如何管理?
• 當使用第三方服務時,如果你不能夠完全下線服務或者重新完整地部署,那么一臺phoenix-server看起來更像什么?

最后,當我們從一種系統(tǒng)架構樣式遷移到其他架構,什么遷移模式是比較有效的?或者是否包括無服務器組件?我們的架構以怎樣的方式進化?

許多這些尚未定義的模式(反模式)都不是很明顯的,通過我們幼稚的想法明顯表現(xiàn)出來的是,如何最好地管理無服務器系統(tǒng)內(nèi)的狀態(tài).毫無疑問,有一些神奇的模式出現(xiàn)了.

我們的組織將會如何變化

成本效益是無服務器前進的一項驅動,最有意思的優(yōu)勢是“生產(chǎn)提前期概念”的降低.通過提供“超級能力”方式,無服務器為大多數(shù)既不是系統(tǒng)管理專家,也不是分布式系統(tǒng)開發(fā)專家的美國工程師提供了進入無服務器領域的可行性.這些只有一點點技術的應用程序開發(fā)工程師,不再需要編寫一行Shell腳本,即可完成整套MVP(即Minimum Viable Product,最小可行性產(chǎn)品)的部署,擴展平臺能力,或者配置一個nginx服務器.前文中我提到了配置工具還在開發(fā)當中,我們現(xiàn)在還沒有這類“簡單的MVP”解決方案,能夠解決所有類型的應用程序問題.但是,我們確實看到了相對于簡單的Web Services服務,甚至為其他類型的應用程序部署一些Lambda函數(shù),也比管理操作系統(tǒng)進程或者容器來得更容易.

除了MVP以外,我們也看到了重新部署應用程序的周期時間正在縮短,不再需要關心腳本維護、系統(tǒng)補丁級別,等等.

無服務器為我們提供了技術手段去實現(xiàn)這些需求,但是還不足以真正實現(xiàn)對于一個組織的改進.為了實現(xiàn)這些目標,公司需要去克服、適應以下這些變化.

真正的DevOps

DevOps已經(jīng)在很多領域都變得很重要了.在開發(fā)工作上,額外技術的技術操作越來越常見.我所看見的是系統(tǒng)管理內(nèi)部的自動化增加和自動化測試,這只是Patrick Debois在創(chuàng)造DevOps概念時所想到的很小一部分.

真正的DevOps是我們思維方式上的變化,以及文化上的變化.讓我們假設有這么一個團隊,這個團隊需要緊密合作、開發(fā)和維護一個產(chǎn)品.這就意味著寫作,而不是基于協(xié)商的工作序列方式.也意味著開發(fā)人員需要提供技術支持.而意味著開發(fā)工程師需要參與應用系統(tǒng)架構.換句話說,意味著技能與責任的融合.

如果一個公司分離了開發(fā)團隊和運維團隊,即將“DevOps”團隊分離,那么他們不會在無服務器領域有任何收獲.如果一個開發(fā)人員僅僅只是對應用程序進行編碼,而部署工作又交給另一個外部團隊負責,那就會沒有真正意義上的系統(tǒng)部署情況反饋.如果一個業(yè)務工程師不會到應用程序的部署環(huán)節(jié),那么他們也不可能適應生產(chǎn)環(huán)境的部署模型.

換句話說,未來會從無服務器領域收獲實際收益的公司,必然是真正使用DevOps的公司.

政策/訪問控制的變化

即便一個組一個組地嘗試改變文化,也是做得不夠的.很多時候,一個大公司里的一個很有工作熱情的團隊,往往面對的是冷冰冰的公司政策.這可能意味著在缺乏外部批準的情況下,缺少部署新系統(tǒng)的能力.很有可能是由于對于所有現(xiàn)有應用程序的數(shù)據(jù)訪問限制.也可能是因為超級嚴格的支出控制.

雖然我不提倡公司把所有與安全和成本相關的問題拋到外部解決,但是為了盡可能做到無服務器化,需要調(diào)整他們的政策,允許團隊對操作請求作出改變,而不是每一次小的更新操作都需要一個團隊外部人員的批準.訪問控制政策目前還不是很有必要構建.團隊需要被給予一定范圍內(nèi)的預算自由.所有的實驗應該被盡可能多地提供免費的沙盒,同事還可以保護公司內(nèi)部真正敏感的數(shù)據(jù)或其他需求.

通過我之前提到過的IAM規(guī)則和多個AWS賬戶的使用,訪問控制工具正在逐漸完善.然而,不是那么簡單的,針對更好的自動化方式正在成熟.同樣,無服務器還存在通過幾個賬戶實現(xiàn)基本預算控制,我們需要更容易控制每個團隊執(zhí)行能力限制,對于不同的環(huán)境有不同的執(zhí)行限制范圍.

好消息是通過加強權限控制工具,所有這些問題都有可能解決,我們會看到y(tǒng)預算分配模式上的進步,等等,因為無服務器工具在持續(xù)改進.事實上,我認為訪問自動化和成本控制將會變成新的shell腳本,換句話說,當團隊思考suanfa軟件的操作問題時,他們不會想要去開始/停止腳本、升級補丁以及磁盤使用率,反而他們會嚴謹?shù)厮伎妓麄冃枰鯓拥臄?shù)據(jù)訪問方式,以及需要怎樣的預算.因為團隊將會經(jīng)常需要思考這個問題,工程師們會用自動化取代這些問題,僅僅像我們之前做部署那樣.

鑒于這種能力和嚴謹性,未來即便是數(shù)據(jù)最敏感的企業(yè),也會有富有熱情的團隊會使用無服務器技術,使用它們?nèi)L試自己的想法,這種做法是之前在白板上從未做過的,最終他們會認識到這種做法真正意義上保護了他們的知識或者避免財務損失.

產(chǎn)品所有權

過去幾年時間里我們看到的另一個轉變是許多高效的工程團隊的聚焦正在從項目專項產(chǎn)品.這一轉變的感覺是對于項目規(guī)劃、迭代和燃盡圖等的關注在降低,轉而更加關注看板方式的進展、輕量級預估以及持續(xù)交付.比這一結構性改變更重要的是雖然角色和心態(tài)在轉變,轉變?yōu)楦嗟穆氊熭^差,同樣我們看到真正的DevOps.

舉個例子,現(xiàn)在很有可能產(chǎn)品經(jīng)理和開發(fā)人員將會密切地充實新思路,開發(fā)人員會做一些原型,產(chǎn)品經(jīng)理在最終產(chǎn)品設計方案明確之前,會深入進行一些技術上的數(shù)據(jù)分析.相似地,創(chuàng)新的火花,即新的想法或者概念也會進入某人的大腦,可能屬于團隊中的任何一個人.這個團隊的許多成員,不僅僅是一個,現(xiàn)在正在接觸到客戶喜歡的想法.

無服務器方法為這些團隊提供了一個關鍵好處,即接受整個團隊產(chǎn)品思維.當團隊中的任何一個人都可以想出一個點子,并且迅速地針對一種盡可能新的創(chuàng)新模式實現(xiàn)一個原型.現(xiàn)在精益啟動式試驗變成默認的思維方式,而不是由“黑客時代”保留的那樣,因為這樣做的成本和時間正在大幅縮減.

另一種看待這一問題的方法是,不接受整個團隊產(chǎn)品思維的團隊很有可能錯誤這一關鍵利益.如果團隊不鼓勵超越項目結構的思考方式,他們就很難盡可能多地使用無服務器所帶來的加速交付可能性.

結論

無服務器在軟件架構領域相對來說是一個新的概念,但是它也是一個可能和其他云計算創(chuàng)新一樣,具有巨大影響力的技術創(chuàng)新.隨著技術的發(fā)展、工具提升以及無服務器應用架構方面的心得交流,越來越多的工程團隊將會擁有提升開發(fā)速度的工具,甚至于可能轉變他們產(chǎn)品開發(fā)方式.適應無服務器,并且適應支撐該技術的文化,這類公司將會在未來領導我們前進.

致謝

感謝為此文貢獻知識的朋友們：John Chapin、Chris Stevenson、Badri Janakiraman、Ben Rady、Ben Kehoe, 以及Nat Pryce.

英文原文：The Future of Serverless Compute