在每天發送超過15億條信息、每月與超過10億消費者互動的過程中，Braze公司使用了大量的云基礎設施。但是Braze的業務是不可預測的，因此對計算資源的需求可能會隨著必須轉換的數據量大幅波動，以支持客戶的個性化通信需求。

Braze公司DevOps和安全主管Sal Poliandro III說：“有時候我們可能有100臺服務器在運行，也有的時候可能有1000臺。” Braze曾經根據一系列指標來擴展其云基礎設施，而這些指標最終支持形成了有根據的最佳猜測。然后，Braze發現了亞馬遜的無服務器計算平臺Lambda。

現在，這個過程完全自動化了。算法確定他們需要多少容量，然后啟動一個功能，該功能可以觸及其基礎設施合作伙伴并立即進行擴展。“過去我們常常根據峰值負荷進行擴展。而有了無服務器技術，我們就不必擔心這一點了，” ”Poliandro說。對于一個典型的開發團隊，他估計該過程至少比手動配置服務器快了10倍。 

Braze只是越來越多追逐這個云領域、甚至是IT領域最熱門趨勢的公司之一。無服務器計算——下面包含功能即服務等子集——通過擺脫配置基礎設施、同時要大幅削減成本的這些苦差事，來吸引開發者和首席信息官的注意力。

有些人認為，無服務器將最終成為大多數軟件構建的一種方式。風險投資公司Mayfield Fund管理合伙人Navin Chaddha說：“這種底層技術將為重新定義完整的應用堆棧、軟件編寫方式、應用程序構建方式創造機會。”

狂熱者們可能會領先一步。畢竟，無服務器計算還沒有走出孵化階段。但令人興奮的是，早期采用者的反饋令人鼓舞。

Cloudability對1500個組織的云使用情況進行了分析，發現2017年第四季度無服務器平臺的使用量增長了7倍多，不過基數還比較小。RightScale報告稱，無服務器技術是2017年1000名受訪的IT專業人員認為增長最快的擴展云服務，采用率從12%增長到21%。

不僅是初創公司，還有大量網站。AWS Lambda及相關無服務器服務總經理Tim Wagner表示，Lambda增長最快的用戶群中包括CapitalOne、Hearst和Financial Industry Regulatory Authority等大型企業。

事實上，一些企業已經開始將無服務器技術推向主流甚至是前沿計算領域。例如，抵押貸款融資公司Federal National Mortgage Association(Fannie Mae)正在將其風險分析模擬從自己的服務器轉移到Lambda，創造了所謂的金融行業第一個無服務器高性能計算平臺。

那些尚未加入的軟件開發人員正在爭先恐后地追趕上來，那些瞄準下一代關鍵技術的大型科技公司也在關注這些熱門趨勢。例如下周在舊金山舉行的Google Cloud Next大會上，無服務器將成為19個分會場主題之一。

“無服務器計算不僅將從根本上改變后端計算的經濟性，也將成為分布式計算未來的核心，”微軟首席執行官Satya Nadella在去年的微軟Build大會上這樣表示。

為你免除煩惱

簡而言之，無服務器技術無需在每次運行程序時設置服務器和軟件。相反，各種功能會根據事件自動執行，無論是由人還是由程序觸發。

“無服務器”這個詞實際上有些用詞不當，因為仍然是需要服務器來執行功能的。但是，與設置虛擬服務器或使用軟件模擬的計算機所花費數小時或數天相比，該過程可以在幾毫秒內完成。因此，無服務器應用可以以非常低的成本幾乎無限擴展，因為客戶只在使用該功能時付費，而無需在服務器空間時間內付費。

相比之下，部署傳統集成應用的過程需要分配基礎設施，如CPU、內存和存儲，以及一套平臺軟件。即使應用僅偶爾使用，這些資源仍然必須保持隨時可用。過度配置會增加成本、浪費容量并導致“服務器無序擴張”——在這種情況下IT部門要為很少使用或者被遺忘了的云實例支付費用。

在無服務器的場景中，開發人員將應用構建為小塊代碼(或者功能)的集合，這些代碼或功能以協調的方式即時調配。這意味著沒有浪費、低開銷、快速可擴展來滿足容量需求。

移動計算最近推動著人們對無服務器領域的關注，因為許多移動應用非常適合無服務器設計。例如一位智能手機用戶查找當地天氣預報，或者某個足球場的方向，這些查詢可以封裝并保存在云中，以便在必要時進行調用。程序只是將參數(例如人的位置和目的地)傳遞給服務器，服務器返回單個目標結果。

無服務器技術還在一些更為日常的場景發揮著作用。例如，當用戶使用新照片更新在線個人資料時，無服務器功能可以自動將照片復制到其他地方。或者，將Excel文件上載到數據庫的用戶可以觸發無服務器功能，將文件轉換為JavaScript Object Notation格式，以便存儲在數據湖中。

無服務器減輕了Braze等公司在規劃不可預測的使用場景時經常遇到的麻煩。這使得無服務器成為新聞組織的一個很好的模式，因為他們看到，當有重要賽事或者有球隊進入季后賽時球迷活動激增導致流量峰值的出現，很多新聞組織只會簡單地分配資源來應對高峰期，為那些未被使用的資源支付費用。

十年變遷

無服務器這一概念并不新鮮。谷歌的App Engine在2008年就具有了計量收費的功能。但直到2014年亞馬遜推出Lambda，這一概念才開始流行起來。其他云服務提供商紛紛效仿，包括擁有Cloud Functions的谷歌、有Azure云功能的微軟、以及有OpenWhisk的IBM。在此期間，商業和開源的產品及服務這一龐大生態系統已經蓬勃發展起來，其中也包括內部部署的選項。

無服務器應用的分布式特性是最有趣的特點之一。無服務器代碼不一定比傳統代碼運行得更快，但它可以分布在網絡上以便并行執行。例如，谷歌的BigQuery分析數據倉庫將查詢分成幾個部分，并在服務器可用的任何地方處理這些查詢。

這意味著相比單線程引擎處理來說，這么做的處理速度要快上幾個數量。分布式引擎在使用資源的方式上也可以更加靈活和具有可擴展性，因為它可以在任何地方觸發功能。水平擴展是自動的、彈性的并且由提供者管理的。

Google Cloud開發人員Kelsey Hightower表示：“計算機的最終目標就像計算器：我希望能夠擁有一個非常簡單的界面，計算機應該給我一個答案。我們會一直做下去，直到最終的體驗變成‘這是我的應用，為我運行的應用。’”

那為什么這項技術還沒有風靡世界呢?嗯，首先，它仍然處于早期階段。“大多數客戶都將無服務器技術用于非常具體的解決方案中，例如事件處理和數據采集，大規模部署還沒有真正開始，”New Relic公司戰略架構高級主管Lee Atchison說道。

另一個原因是無服務器模型的結構是有局限性的，目前是限制于一組有限的應用中。“我認為很少有公司會把賭注全部壓在無服務器上，你的IT部門可以采取混搭的方式，” Red Hat產品管理高級總監Rich Sharples這樣表示。無服務器是一種很好的快速執行簡單任務的方式，但缺乏統一化的、微服務平臺提供的一些關鍵控制功能。

Gartner技術和服務提供商集團研究主管Craig Lowery更為樂觀一些。“人們不理解無服務器技術，所以將其歸類成一個利基市場。”Gartner研究了五家公司，這五家公司都在沿著無服務器學習曲線向上攀升，并發現一旦他們放棄了開發軟件的傳統規范，所有公司都會成為顛覆者。“一旦他們放下以前那些期望，他們就能夠實現這些好處。”

AWS首席執行官Andy Jassy去年表示，假如今年創建亞馬遜公司的話，那么就會建立在無服務器平臺上——他們對這項技術的快速采用感到驚訝，即使在大型企業中也是如此。

“我們有很多企業客戶，我們原本認為他們不會是第一批采用Lambda的企業客戶，”AWS首席信息安全官辦公室主任Mark Ryland上周在紐約舉行的AWS峰會上表示。“但是因為他們正在做重大的應用重建，他們說，‘我為什么要選擇容器?我可以構建一個功能正常的應用。’”

無狀態和事件驅動

無服務器計算有兩個顯著特征，既有強大的吸引力，又面臨著更廣泛采用的障礙。

首先，無服務器功能是無狀態的，這意味著沒有用于交互的上下文。它們不存儲歷史記錄，因此僅使用隨附的信息處理每個請求。“每次都像一塊白板，但非常高效，因為你不需要應對重重的復雜應用邏輯，” Wikibon分析師James Kobielus說。

另一個顯著特征是無服務器是事件驅動的，意味著會對用戶或程序生成的動作做出響應，事件可能包括查詢明尼阿波利斯當前溫度的請求、搜索引擎查詢或數據庫記錄更新。

事件驅動的應用是非常高效的，因為在不使用的時候不會消耗資源。這種應用編程簡單，易于擴展。“你可以設置應用，這樣如果有事件進來，那么功能運行起來。如果有一百萬個時間進來，你就可以應對一百萬個，”Lowery說。但是，并非每個應用都可以被提煉為一系列無狀態事件。

綜合起來，這些讓無服務器計算成為某些請求的理想平臺，例如查看美國明尼阿波利斯的熱或冷。然而，對于其他例如管理購物車或制作賬單來說，并不是那么好用。

Kobelius說：“有人點擊‘購買’，整套數據庫和運行時功能做定價，最終確定訂單，并發送確認。所有必須以嚴格的方式發生，帶有狀態和事務流”，這使得它無法與無服務器執行相匹配。

目前尚不清楚是否會有新的工具和擴展程序讓無服務器技術在更為傳統的應用中變得可行。無狀態應用可以擴展或改進以展示有狀態的行為，就像容器一樣，輕量級虛擬機可以抽象消除底層基礎架構的差異。容器也是無狀態的，但商業和開源擴展讓容器可以用于上下文敏感的應用中。

微軟的目標是消除功能即服務和平臺即服務之間的界限，讓開發人員能夠混合搭配各種不同的平臺。特別是，微軟強調所謂的“虛擬Kubelets”，這個在12月推出的技術能夠使容器運行各種功能或完整的應用，但有了微計費和自動基礎設施配置，無服務器提供了很多企業客戶想要的靈活性。AWS在11月底推出了Fargate，可以在不管理服務器或服務器集群的情況下運行容器。

微軟Azure容器項目管理負責人Gabe Monroy在去年12月的KubeCon + CloudNativeCon北美會議上表示：“這實際是最好的無服務器，如果基礎設施消失，我們將在基礎設施領域開展工作。”

Wikibon的Kobielus甚至認為，區塊鏈這種去中心化的數字記賬技術對數據庫密集型場景中的無狀態來說是一種補充。他說：“你可以隨時回滾一個完整敘述，關于誰在什么樣的聯合框架中調用了什么。”

因此，無服務器的擁護者認為，這項技術有廣闊的前景，特別是對于那些有著“提升和轉變”心態的企業，他們試圖將舊應用轉移到一種新模式上，并積極擁抱構建和運行這些應用的新方法。

例如就在幾年前，房利美(Fannie Mae)公司運行蒙特卡洛(Monte Carlo)模擬分析其抵押貸款組合的風險。現在，他們正在運行所謂的第一個在金融行業中使用無服務器的高性能計算平臺。在大約2000萬抵押貸款的模擬中，該系統的工作速度比以前快了4倍多。

“我們認為沒有任何固有的技術限制可以阻止任何主要工作負載在Lambda上的使用，”AWS的Gilbert表示，他有趣地稱Fannie Mae將無服務器當做“云中的超級計算機”。他說：“無服務器將是最簡單、最簡單的，對許多客戶來說是主流計算的首選方式。”

開發者的愛

無服務器模型有一個優點，不容易被提煉為投資回報指標：開發人員喜歡這項技術。無服務器架構使他們擺脫了基礎架構部署的負擔，他們只需要編寫代碼就行了。

Braze的Poliandro說“無服務器技術讓我們的應用和運營工程師能夠以對他們更有意義的方式思考他們的責任。他們可以更快地部署，不必擔心周圍的基礎設施。”

但是，在無服務器平臺上構建應用，需要對開發人員如何考慮執行任何的方式進行重大改變。“選擇Lambda意味著要為代碼進行重寫，”Ryland坦言。

無服務器架構的粉絲說，這種局限性不在于技術，而在于開發集成應用已有60年的歷史。 Gartner的Lowery說：“無服務器技術挑戰了軟件應該如何開發的一些假設和已有的模式。客戶看到其中有很多價值，但他們不得不學習一種全新的編程方式。”

針對無狀態、以事件驅動的環境進行開發，并不一定比開發單一程序更容易。無服務器架構“將復雜性從應用轉移到連接中，”Atchison說。“這不是萬能的解決方案，也有自身的問題，也要解決這些問題。”

微軟建議，開發人員要熟悉基于事件的異步模式的編程，并學習使用功能協調器(如Durable Functions編程模型和Logic Apps連接器)，創建長時間運行的操作和狀態管理。

但是倡導者們說，這些好處值得陡峭的學習曲線，所需要的不僅僅是更多工具，還有更具創造性的軟件開發方法。

“大多數應用所做的，絕大多數都可以呈現為無服務器功能，”Kobielus說。容器有助于將功能封裝并作為服務提供給用戶，它們可以獨立擴展。”

傳統應用仍然可以通過修改以利用某些無服務器功能。本質上由事件驅動的各種功能是可以與主應用分開封裝的。

例如，“隨時在數據庫或文件系統中創建數據，這是一個事件，”Lowery說。“這意味著你可以將其設置為獨立于主程序執行其他操作。這樣做讓應用生命周期更長，”因為應用可以通過使用應用程序編程接口進行擴展，或者掛接到其他應用中。

企業組織可以調整各個組成部分以便受益于無服務器執行，并分階段遷移，而不是從頭開始重寫現有應用。“將新的應用功能作為微服務，將用戶界面組件從業務邏輯和數據訪問層拆分，并將現有的微服務轉換并拆分為無服務器功能，”Simform技術顧問Rohit Akiwatkar這樣說道，Simform是一家移動和物聯網服務公司，已經圍繞服務器做了廣泛發布。“隨著時間的推移，功能的數量將會增加，開發團隊的敏捷性和速度將會提高。”

最佳時機

現在是CIO加入無服務器陣營的時候了嗎? Lowery認為是的。“我告訴CIO們，這項技術不會消失，這不是一種流行時尚。企業應該開始讓員工熟悉這項技術。”

Simform的Akiwatkar建議采取三個步驟：了解使用無服務器架構的最佳實踐;確定高ROI的應用;在低風險環境中嘗試無服務器功能。

所有這些讓現在成為開發者采用無服務器技術的最佳時機。從容器、微服務到現在的無服務器計算，過去五年在應用的構建和部署方面引入的創新數量比過去20年的總和還多。

在一個極度缺乏人才的經濟體中，對下一個重要事件保持謙遜可能是吸引最優秀人才的唯一途徑。 “你必須有一個長期采用這項技術的計劃，否則你將無法獲得所需的人才。開發人員會對這項技術充滿期待，”Lowery說。

對于那些仍在努力應對如DevOps等無窮無盡創新(例如云、容器和微服務)的組織來說，無服務器計算似乎又是一個令人頭痛的問題。 但在這個所有公司都想成為軟件公司的商業世界中，沒有跟上這個最新趨勢可能會讓你犯下存在感減少的錯誤。