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

現在是2017年，距離兩年前無伺服器計算革新只取得了少許進展（你聽見人們在唱歌嗎？）。這次變革並不是像Docker那樣突飛猛進地前進，而是採用了相對平穩的發展節奏。Amazon新發布了Web Services的Lambda特性，產品保持了一個有規律的釋出節奏，另一個重要的第三方（微軟）正在一個接一個地釋出生產環境版本，也有一些新的開源專案頻繁地加入這場盛宴。

當我們接近早期階段的末尾時，來做一個有趣的遊戲，讓我們戴上預測護目鏡（開個玩笑），深入思考下一步會走向哪裡，如何走到那一步，以及我們的組織需要去做什麼來支援這一步的到來。所以，加入我們，讓我們看看無伺服器計算未來可能發生什麼。

讓讀者瞭解真實的未來！你可以通過閱讀這篇文章開始瞭解細節。我們離無伺服器還有多遠？2020年怎麼樣？請寄一張明信片給我！

無伺服器能力展望

計算

過去十年我們目睹了雲端計算的出現，然後它迅速地異軍突起。9年以前，虛擬公有云伺服器還只是手上的玩具而已，但是在相當短的時間裡，當我們考慮任何新的部署架構方案時，它變成了大多數行業的首選平臺。

無伺服器計算，或者Functions-as-a-Service（Faas），當我們考慮“IT”如何變化時，它會是這次重大變化的最新出現部分。這次變革是一次我們一直以來所期待的自然過程，從我們如何交付應用程式給客戶開始，到希望能夠刪除所有的部件和基礎設施。

我們開發的相當一部分應用程式，是由許多小的元件所組成的。每個這樣的元件包含了一個小的輸入集和上下文資訊，需要消耗10毫秒或100毫秒完成元件的一些內部工作，最終可能反饋一個結果，也可能更新相關內容。這類場景最適合無伺服器計算。

我們預測未來由於FaaS在部署上的方便、快速、廉價，會有越來越多的團隊基於FaaS開發，這樣便於管理和擴充套件基礎設施。我們對FaaS可以有很多種使用方式，包括：

• 由大量的順序訊息處理器所組成的完整的後端資料管道
• 通過HTTP API呼叫的同步服務
• 通過獨立的膠水程式碼提供針對部署、監控的自定義操作邏輯
• 對於計算密集任務，由實體伺服器直接呼叫平臺縮放功能組成的混合動力系統

使用FaaS的企業相較沒有使用的企業具有競爭優勢，包括價格、投向市場時間等。

管理應用程式狀態

廣泛採用FaaS的一個先決條件是針對快速而簡單的狀態管理方法的解決方案，或者一系列解決方案。無伺服器計算是一種無狀態模式。我們不能假定任何有用的狀態存在，即不存在即時執行環境內不同的執行時呼叫之間的有用狀態。一些應用程式在這種限制下依然適用。例如，單純進行資料轉換的訊息驅動元件不需要訪問外部狀態，擁有無限制響應時間需求的Web Service元件，其每一次呼叫時需要連線到一臺遠端資料庫，這種做法也是可以接受的。但是對於其他應用程式來說，這種限制就顯得有些不足了。

解決這類不足的一種方案是混合動力系統，即在不同型別的元件裡管理狀態，而不是執行我們的FaaS程式碼。比較流行的混合動力方案是通過雲端基礎設施提供其他服務的前端FaaS功能。我們已經見到了這種類似於API網管的特定上下文邏輯的元件，它們提供了HTTP路由、授權，以及我們經常在典型的Web Service裡看到的節流邏輯，採用定義替換配置方式實現。Amazon最近也在管理狀態的通用方式上露了一手，使用他們的Step Functions服務，允許團隊基於可配置的狀態機器定義應用程式。Step Funcations服務本身可能沒什麼過人之處，但是通常情況下這種無碼解決方案是很受歡迎的。

當供應商服務不充足時，對於混合動力系統來說，一種改變方式是團隊堅持開發追蹤狀態的長生命週期元件。這些元件可能被部署在CaaS（容器即元件，Containers-as-a-Service）或者PaaS（平臺即元件，Platform-as-a-Service）環境，和FaaS功能協同工作。

這種混合動力系統組合了長期執行的元件邏輯和每一次FaaS功能請求邏輯。另一類做法是完全地聚焦於FaaS功能，讓這些FaaS功能超越它們當前執行的環境，極其快速地獲取和持久化狀態。一種可能的實施方式是確保一個特定的FaaS功能，或者一系列FaaS功能，確保它們擁有類似於Redis這樣的外部快取機制，起到低延時訪問作用。通過啟動類似於Amazon的same-zone plancement groups（置放組群）這樣的特性可以做到這一點。雖然這種解決方案較記憶體/本地磁碟狀態方案來說有些延遲，但是很多應用程式會認同這種解決方案。

混合方法的好處是經常被訪問的狀態可以和邏輯一起儲存在環境當中，那樣並不複雜，但是可能有點貴，必須要有邏輯網路選址和外部狀態。另一方面，一個單純的FaaS方式的有點是更加一致性的程式設計模型，外加無伺服器帶來的更為寬廣的伸縮使用和可操作性優勢。當前的發展勢頭顯示最終混合方式會勝出，但是我們也應該對其他方式開放，比如類似於啟用置放群組Lambdas。

無伺服器協作服務

超越業務管理和狀態管理，我們可以預見到其他元件的服務化和商業化，即使在雲端環境，傳統意義上我們希望開發，或者至少自己管理這些服務。例如我們可以停止執行在EC2機器上面的Mysql資料庫伺服器，轉而使用Amazon的RDS伺服器，我們可以使用Kinesis替換我們自管理的Kafka訊息匯流排安裝程式。其他的基礎設施服務包括檔案系統和資料倉庫，而更多的面向應用示例包括認證和語音分析。

這種趨勢還會繼續，我們需要進一步地減少建立或者維護產品所帶來的工作量。我們可以設想更多的預安裝的訊息邏輯（把Apache Camel想象成服務，構建到Amazon Kinesis或者SQS裡面），並且進一步開發通用機器學習服務。

這裡比較有意思的一個想法是FaaS功能，由於它們輕量級的應用模式，可以將自己緊緊地繫結一個服務，使得FaaS呼叫服務功能的生態環境時可以呼叫其他的FaaS功能，諸如此類等等。這會導致“有趣的”級聯錯誤問題，對於這種錯誤我們需要更強大的監控工具，會在本文稍後介紹。

站在資料中心後面

目前來看，絕大多數的無伺服器計算是執行在供應商資料中心平臺上的。這就給出了一個替代方案，即如何執行你的程式碼，而不是在哪裡執行程式碼。Amazon釋出了一個有趣的新特性，即是允許它們的客戶在不同的地點執行Lambda函式，例如，和[email protected]一起執行在CDN內，甚至在無伺服器地點，例如，和Greengrass一起執行的物聯網（IoT）裝置。這樣做的原因是，Lamdba是一個極端輕量級的程式設計模型，本質上的事件驅動的，並且非常容易適配相同的知識理念、新地點的程式碼風格。[email protected]是一個特別有趣的例子，因為它提供了在一個地點進行程式定製的可選項，這在以前是沒有出現過的情況。

當然，這種做法的缺點是和供應商深度繫結！對於那些不想使用第三方平臺，但是又想利用無伺服器計算優勢的廠商來說，有一種可以接受的解決方案，類似於Cloud Foundry已經推出的PaaS。來自Kubernetes的Galactic Fog、IronFunctions以及Fission，是這種方案的早期作品。

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

正如我之前描述的，這裡有一個明顯的減速，使用無伺服器方式時存在條件限制、價效比權衡。天下沒有免費的午餐。對於已經過了早期適應階段的無伺服器使用者來說，我們需要解決或者緩解這些問題。所幸，這方面目前發展勢頭良好。

部署工具

使用AWS的標準工具向Lambda部署函式挺複雜的，也比較容易出錯。向API閘道器中新增Lambda函式，以響應HTTP請求，你更多要做的工作是安裝和配置。無伺服器和ClaudiaJS開源專案專案已經推動部署改進措施達一年之久，AWSSAM（AWS無伺服器應用模型）也在2016年加入到了這一行動。所有這些專案通過在AWS標準工具的頂層增加大量自動化程式，簡單化了無伺服器應用程式的建立、配置和部署。但是我們還有很多工作要做。未來將會有兩個關鍵動作實現完全自動化：

• 初始化一個應用程式或者環境的建立（例如，初始化生產環境，以及初始化臨時測試環境）
• 持續多部件應用程式的交付/部署

第一條很重要，我們也已經開始認識到，以便更廣泛地推廣“生產提前期概念”。部署一個全新的無伺服器應用程式應該是像建立一個新的Github倉庫一樣容易，填充少量欄位，然後按下按鈕，通過這種一鍵部署方式讓系統自動建立你所需要的所有東西。

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

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

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

總之，我們需要開發人員在開發他們的Webtask產品時，做到UX和Auth0都很好，就像AWS一樣的寬廣而有價值的生態系統。

監控、日誌和除錯

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

除錯也是挺重要的。程式設計師很少在第一次程式碼執行通過之前不犯錯誤，我們也別寄希望於這種情況會有所改變。我們依賴於監控，在FaaS功能的開發階段評估問題，但是這種除錯方式是石器時代的工具。

當我們除錯傳統的應用程式時，我們從IDE工具那裡可以得到很大的支援，通過設定斷點、單步除錯程式碼，等等。使用現代化的基於Java的IDE工具，你可以繫結一個正在執行的遠端程序，並且遠端執行除錯工作。因為我們更加傾向於使用雲端部署的FaaS功能完成大量的部署工作，希望未來你的IDE工具也可以具有類似的功能，可以連線到一臺正在執行的無伺服器平臺，查詢每個功能的執行情況。這需要工具和平臺開發商之間的協作，如果想要讓無伺服器被廣泛採用，這些措施都是必要的。這些想法對於雲端計算來說有一定開發工作量，也有大量的測試工作量。

測試

我到目前為止所討論的所有關於無伺服器工具的話題，我認為最落後的是測試工具。值得關注的是，無伺服器方案較傳統解決方案來說有著相當大的測試優勢，主要是兩點，（a）.無伺服器計算的各個功能的單元測試很成熟，（b）.無伺服器服務寫的程式碼更少，並且至少在單元測試層面，只需要做簡單的測試。

但是這並沒有解決跨元件功能/整合/驗收/業務流程等測試問題。無伺服器計算時我們的邏輯是分散在幾個函式和服務內的，因此，更高級別的測試甚至比使用接近單一方法的元件更重要。當我們如此依賴於在雲端基礎設施上執行時，我們應該怎麼做呢？

對於我們來說，測試可能是最沒有看清楚的。我猜測未來基於雲端的測試會變得很普遍。這一部分會變得更加容易部署、監控，以及除錯我們的無伺服器apps，甚至於比我現在描述的這些原因更加豐富。

換句話說，為了執行更高級別的測試，我們將會部署整個生態系統的一部分到雲端，並且對部署在那裡的元件執行測試用例，而不是針對部署在我們自己開發機器上的系統執行測試用例。這種做法有一定的優勢：

• 執行部署在雲端的元件的真實度較本地模擬來說更高。
• 我們較過去，更有可能可以執行高負載/高豐富度資料測試。
• 生產環境資料來源的測試元件（例如，一個釋出訂閱模式的訊息匯流排，或者一個數據庫）會更加容易，雖然顯而易見我們需要關注能力/安全問題。

但是這種解決方案也有弱點。首先，執行測試的週期時間很有可能由於部署和網路延遲而相應增加。其次，當網路連線中斷以後，我們就不可以繼續執行測試用例了（例如，在飛機上）。最後，因為生產環境和測試環境最終部署方案很相近，我們也需要格外小心，當我們打算改變測試用例時，不要發生不小心改變了生產環境的事故。如果我們使用AWS，我們可能需要通過類似於IAM角色這樣的工具安全地部署，或者對於不同型別的環境使用完全不同的賬號進行部署。

測試並不僅僅是一個二進位制程式執行成功或者失敗，我們也想要去弄清楚測試是如何失敗的。我們應該可以除錯本地執行測試和正在執行的遠端元件，包括可以單步除錯一個執行在AWS上的Lambda函式，因為它可以相應測試。所以所有的遠端除錯，例如，我前面章節提到的工具也需要測試，而不是僅僅互動式開發。

請注意，我並不是基於這些暗示我們的開發工具需要執行在雲端，也不是測試本身需要執行在雲端，雖然兩者將來都會或多或少地走到這一步。我只是表示正在測試的系統僅執行在雲端，而不是一個非雲端環境。

使用無伺服器作為測試驅動環境可以收穫有用的結果。一個例子被稱為“無伺服器火炮”，這是一種負載測試工具，由執行著的許多並行的AWS Lamdbas組成，執行即時、廉價、易於擴充套件效能測試規模的負載測試用例。

值得指出的是，在某種程度上，我們避免了一些失誤。由於技術進步，傳統的高層及測試實際上正在變得不那麼重要，例如（a）生產環境測試/使用監控驅動開發，（b）平均解決時間（MTTR）的顯著降低，（c）基於持續部署。對於許多的無伺服器apps應用廣泛的單元測試，度量業務水平的生產環境監控&預警，以及一個專用於減少MTTR和基於持續開發的方法，都將會是有效的程式碼驗證策略。

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

系統架構較好的無伺服器應用程式是怎樣的？是如何演變的？

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

重要的是，在做出統一意見之前，這些書著眼於基礎工具幾年的使用經驗。無伺服器技術存在時間太短，還不足以需要編寫一本書進行描述，但是這一時刻正在逼近，一年內我們會看到一些有用的實踐案例出現（當無伺服器架構需要出一本高調的書時，大家一般會選用“最佳實踐”這樣的術語描述）。

系統架構之後（即無伺服器應用程式是如何被構建的），我們需要思考部署系統架構（無伺服器應用程式如何部署）。我已經談了一些部署工具，但是我們可以如何使用這些工具呢？例如：

• 環境這樣的術語在世界上意味著什麼？“生產”看上去較過去有點不明確。
• 什麼是一個軟體棧的side-by-side部署？看上去像是從一組功能/服務版本緩慢地移動業務到另一組功能/服務版本（滾動部署）？
• 世界上有麼有類似於“藍-綠”這樣的部署方式？
• 現在的回滾方式是怎樣的？
• 我們如何管理資料庫的升級/回滾，當我們可能有多個不同的程式碼生產版本，並且這些版本在同一個功能內執行，這類有狀態元件應該如何管理？
• 當使用第三方服務時，如果你不能夠完全下線服務或者重新完整地部署，那麼一臺phoenix-server看起來更像什麼？

最後，當我們從一種系統架構樣式遷移到其他架構，什麼遷移模式是比較有效的？或者是否包括無伺服器元件？我們的架構以怎樣的方式進化？

許多這些尚未定義的模式（反模式）都不是很明顯的，通過我們幼稚的想法明顯表現出來的是，如何最好地管理無伺服器系統內的狀態。毫無疑問，有一些神奇的模式出現了。

我們的組織將會如何變化

成本效益是無伺服器前進的一項驅動，最有意思的優勢是“生產提前期概念”的降低。通過提供“超級能力”方式，無伺服器為大多數既不是系統管理專家，也不是分散式系統開發專家的美國工程師提供了進入無伺服器領域的可行性。這些只有一點點技術的應用程式開發工程師，不再需要編寫一行Shell指令碼，即可完成整套MVP（即Minimum Viable Product，最小可行性產品）的部署，擴充套件平臺能力，或者配置一個nginx伺服器。前文中我提到了配置工具還在開發當中，我們現在還沒有這類“簡單的MVP”解決方案，能夠解決所有型別的應用程式問題。但是，我們確實看到了相對於簡單的Web Services服務，甚至為其他型別的應用程式部署一些Lambda函式，也比管理作業系統程序或者容器來得更容易。

除了MVP以外，我們也看到了重新部署應用程式的週期時間正在縮短，不再需要關心指令碼維護、系統補丁級別，等等。

無伺服器為我們提供了技術手段去實現這些需求，但是還不足以真正實現對於一個組織的改進。為了實現這些目標，公司需要去克服、適應以下這些變化。

真正的DevOps

DevOps已經在很多領域都變得很重要了。在開發工作上，額外技術的技術操作越來越常見。我所看見的是系統管理內部的自動化增加和自動化測試，這只是Patrick Debois在創造DevOps概念時所想到的很小一部分。

真正的DevOps是我們思維方式上的變化，以及文化上的變化。讓我們假設有這麼一個團隊，這個團隊需要緊密合作、開發和維護一個產品。這就意味著寫作，而不是基於協商的工作序列方式。也意味著開發人員需要提供技術支援。而意味著開發工程師需要參與應用系統架構。換句話說，意味著技能與責任的融合。

如果一個公司分離了開發團隊和運維團隊，即將“DevOps”團隊分離，那麼他們不會在無伺服器領域有任何收穫。如果一個開發人員僅僅只是對應用程式進行編碼，而部署工作又交給另一個外部團隊負責，那就會沒有真正意義上的系統部署情況反饋。如果一個業務工程師不會到應用程式的部署環節，那麼他們也不可能適應生產環境的部署模型。

換句話說，未來會從無伺服器領域收穫實際收益的公司，必然是真正使用DevOps的公司。

政策/訪問控制的變化

即便一個組一個組地嘗試改變文化，也是做得不夠的。很多時候，一個大公司裡的一個很有工作熱情的團隊，往往面對的是冷冰冰的公司政策。這可能意味著在缺乏外部批准的情況下，缺少部署新系統的能力。很有可能是由於對於所有現有應用程式的資料訪問限制。也可能是因為超級嚴格的支出控制。

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

通過我之前提到過的IAM規則和多個AWS賬戶的使用，訪問控制工具正在逐漸完善。然而，不是那麼簡單的，針對更好的自動化方式正在成熟。同樣，無伺服器還存在通過幾個賬戶實現基本預算控制，我們需要更容易控制每個團隊執行能力限制，對於不同的環境有不同的執行限制範圍。

好訊息是通過加強許可權控制工具，所有這些問題都有可能解決，我們會看到y預算分配模式上的進步，等等，因為無伺服器工具在持續改進。事實上，我認為訪問自動化和成本控制將會變成新的shell指令碼，換句話說，當團隊思考suanfa軟體的操作問題時，他們不會想要去開始/停止指令碼、升級補丁以及磁碟使用率，反而他們會嚴謹地思考他們需要怎樣的資料訪問方式，以及需要怎樣的預算。因為團隊將會經常需要思考這個問題，工程師們會用自動化取代這些問題，僅僅像我們之前做部署那樣。

鑑於這種能力和嚴謹性，未來即便是資料最敏感的企業，也會有富有熱情的團隊會使用無伺服器技術，使用它們去嘗試自己的想法，這種做法是之前在白板上從未做過的，最終他們會認識到這種做法真正意義上保護了他們的知識或者避免財務損失。

產品所有權

過去幾年時間裡我們看到的另一個轉變是許多高效的工程團隊的聚焦正在從專案專項產品。這一轉變的感覺是對於專案規劃、迭代和燃盡圖等的關注在降低，轉而更加關注看板方式的進展、輕量級預估以及持續交付。比這一結構性改變更重要的是雖然角色和心態在轉變，轉變為更多的職責較差，同樣我們看到真正的DevOps。

舉個例子，現在很有可能產品經理和開發人員將會密切地充實新思路，開發人員會做一些原型，產品經理在最終產品設計方案明確之前，會深入進行一些技術上的資料分析。相似地，創新的火花，即新的想法或者概念也會進入某人的大腦，可能屬於團隊中的任何一個人。這個團隊的許多成員，不僅僅是一個，現在正在接觸到客戶喜歡的想法。

無伺服器方法為這些團隊提供了一個關鍵好處，即接受整個團隊產品思維。當團隊中的任何一個人都可以想出一個點子，並且迅速地針對一種儘可能新的創新模式實現一個原型。現在精益啟動式試驗變成預設的思維方式，而不是由“黑客時代”保留的那樣，因為這樣做的成本和時間正在大幅縮減。

另一種看待這一問題的方法是，不接受整個團隊產品思維的團隊很有可能錯誤這一關鍵利益。如果團隊不鼓勵超越專案結構的思考方式，他們就很難儘可能多地使用無伺服器所帶來的加速交付可能性。

結論

無伺服器在軟體架構領域相對來說是一個新的概念，但是它也是一個可能和其他雲端計算創新一樣，具有巨大影響力的技術創新。隨著技術的發展、工具提升以及無伺服器應用架構方面的心得交流，越來越多的工程團隊將會擁有提升開發速度的工具，甚至於可能轉變他們產品開發方式。適應無伺服器，並且適應支撐該技術的文化，這類公司將會在未來領導我們前進。

致謝

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

英文原文：The Future of Serverless Compute