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

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

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

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

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

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

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

不僅是初創(chuàng)公司，還有大量網(wǎng)站。AWS Lambda及相關(guān)無服務器服務總經(jīng)理Tim Wagner表示，Lambda增長最快的用戶群中包括CapitalOne、Hearst和Financial Industry Regulatory Authority等大型企業(yè)。

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

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

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

為你免除煩惱

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

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

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

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

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

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

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

十年變遷

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

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

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

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

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

另一個原因是無服務器模型的結(jié)構(gòu)是有局限性的，目前是限制于一組有限的應用中?！拔艺J為很少有公司會把賭注全部壓在無服務器上，你的IT部門可以采取混搭的方式，” Red Hat產(chǎn)品管理高級總監(jiān)Rich Sharples這樣表示。無服務器是一種很好的快速執(zhí)行簡單任務的方式，但缺乏統(tǒng)一化的、微服務平臺提供的一些關(guān)鍵控制功能。

Gartner技術(shù)和服務提供商集團研究主管Craig Lowery更為樂觀一些。“人們不理解無服務器技術(shù)，所以將其歸類成一個利基市場?！盙artner研究了五家公司，這五家公司都在沿著無服務器學習曲線向上攀升，并發(fā)現(xiàn)一旦他們放棄了開發(fā)軟件的傳統(tǒng)規(guī)范，所有公司都會成為顛覆者。“一旦他們放下以前那些期望，他們就能夠?qū)崿F(xiàn)這些好處?！?/span>

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

“我們有很多企業(yè)客戶，我們原本認為他們不會是第一批采用Lambda的企業(yè)客戶，”AWS首席信息安全官辦公室主任Mark Ryland上周在紐約舉行的AWS峰會上表示?！暗且驗樗麄冋谧鲋卮蟮膽弥亟?，他們說，‘我為什么要選擇容器？我可以構(gòu)建一個功能正常的應用?！?/span>

無狀態(tài)和事件驅(qū)動

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

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

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

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

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

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

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

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

微軟Azure容器項目管理負責人Gabe Monroy在去年12月的KubeCon ＋ CloudNativeCon北美會議上表示：“這實際是最好的無服務器，如果基礎(chǔ)設施消失，我們將在基礎(chǔ)設施領(lǐng)域開展工作?！?/span>

Wikibon的Kobielus甚至認為，區(qū)塊鏈這種去中心化的數(shù)字記賬技術(shù)對數(shù)據(jù)庫密集型場景中的無狀態(tài)來說是一種補充。他說：“你可以隨時回滾一個完整敘述，關(guān)于誰在什么樣的聯(lián)合框架中調(diào)用了什么?！?/span>

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

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

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

開發(fā)者的愛

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

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

但是，在無服務器平臺上構(gòu)建應用，需要對開發(fā)人員如何考慮執(zhí)行任何的方式進行重大改變?！斑x擇Lambda意味著要為代碼進行重寫，”Ryland坦言。

無服務器架構(gòu)的粉絲說，這種局限性不在于技術(shù)，而在于開發(fā)集成應用已有60年的歷史。 Gartner的Lowery說：“無服務器技術(shù)挑戰(zhàn)了軟件應該如何開發(fā)的一些假設和已有的模式?？蛻艨吹狡渲杏泻芏鄡r值，但他們不得不學習一種全新的編程方式?！?/span>

針對無狀態(tài)、以事件驅(qū)動的環(huán)境進行開發(fā)，并不一定比開發(fā)單一程序更容易。無服務器架構(gòu)“將復雜性從應用轉(zhuǎn)移到連接中，”Atchison說?！斑@不是萬能的解決方案，也有自身的問題，也要解決這些問題?！?/span>

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

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

“大多數(shù)應用所做的，絕大多數(shù)都可以呈現(xiàn)為無服務器功能，”Kobielus說。容器有助于將功能封裝并作為服務提供給用戶，它們可以獨立擴展?！?/span>

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

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

企業(yè)組織可以調(diào)整各個組成部分以便受益于無服務器執(zhí)行，并分階段遷移，而不是從頭開始重寫現(xiàn)有應用?！皩⑿碌膽霉δ茏鳛槲⒎?，將用戶界面組件從業(yè)務邏輯和數(shù)據(jù)訪問層拆分，并將現(xiàn)有的微服務轉(zhuǎn)換并拆分為無服務器功能，”Simform技術(shù)顧問Rohit Akiwatkar這樣說道，Simform是一家移動和物聯(lián)網(wǎng)服務公司，已經(jīng)圍繞服務器做了廣泛發(fā)布?！半S著時間的推移，功能的數(shù)量將會增加，開發(fā)團隊的敏捷性和速度將會提高?！?/span>

最佳時機

現(xiàn)在是CIO加入無服務器陣營的時候了嗎？ Lowery認為是的?！拔腋嬖VCIO們，這項技術(shù)不會消失，這不是一種流行時尚。企業(yè)應該開始讓員工熟悉這項技術(shù)。”

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

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

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

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