Luca Mezzalira：你真的為Serverless X AI做好準備了嗎？

無服務器架構是當下云計算領域最熱門的趨勢之一。據統(tǒng)計，只有 35% 的技術人員還沒有使用無服務器平臺，越來越多的企業(yè)出于降低成本、簡化運維、加快產品上市速度等原因選擇轉向無服務器架構。那么，開發(fā)人員該如何轉變自己的開發(fā)方式以適應和充分利用無服務器架構？在業(yè)務快速變化的情況下如何采用無服務器架構加速應用開發(fā)進程？Serverless 架構如何與 AI 等應用場景進行高質量的結合？

亞馬遜云科技 TechTalk 特別版直播活動榮幸的邀請到了亞馬遜云科技首席無服務器專家 Luca Mezzalira，他結合親身經驗為開發(fā)者提供了無服務器架構下應用開發(fā)的實用建議。

無服務器架構的 核心價值和挑戰(zhàn)

InfoQ：無服務器架構的核心價值是什么？亞馬遜云科技的無服務器架構有哪些優(yōu)勢？

Luca Mezzalira：“無服務器”這一概念經過多年演變，如今我們稱其是一種策略。用戶采取無服務器策略時可以將同質化的繁重工作交給亞馬遜云科技，自己專注編寫開發(fā)新功能，滿足你的客戶需求。

無服務器架構有幾個優(yōu)勢：首先是業(yè)務敏捷性。無服務器架構的優(yōu)勢在于模塊化，我們能夠在基礎設施層面來將這一概念付諸實踐?；跓o服務器架構，客戶可以享受到亞馬遜云科技內置的各種通用模式。

無服務器的另一大優(yōu)勢就是我們擁有豐富的基礎設施管理經驗，客戶可以直接享用我們多年來學到的所有最佳實踐，而開發(fā)人員或整個企業(yè)就可以專注于自己的差異化競爭優(yōu)勢——也就是他們的軟件或他們正在開發(fā)的項目。

InfoQ：您提到了無服務器架構的這么多優(yōu)勢，但任何事物都有兩面性。那么在您看來，無服務器架構現(xiàn)在面臨著哪些挑戰(zhàn)？我們又該如何應對這些挑戰(zhàn)呢？

Luca Mezzarila：事物確實都有兩面性，特別是對于那些第一次接觸無服務器服務的人來說，想要上手確實得花點功夫。大家要在多個維度上轉變自己的思維，拋棄過去自己熟悉的傳統(tǒng)開發(fā)方式，轉而在代碼層面開始習慣模塊化表達，同時試著將更多權力下放給基礎設施。確實我們?yōu)榱松鲜忠c時間，但這并不是多難的事情。

InfoQ：在無服務器架構中，冷啟動延遲非常重要，也是一個常見的問題。Amazon Lambda SnapStart 可以將冷啟動時間降低 90%，這絕對是了不起的成就。你能分享一下這背后的故事嗎？

Luca Mezzarila：Amazon Lambda SnapStart 特別關注 Java 的應用場景，因為世界上有很多組織都高度依賴于 Java。將來的 Amazon Lambda SnapStart 也可能適用于其他環(huán)境，因為 Amazon Lambda 支持多種由亞馬遜云科技托管的運行時。

很多開發(fā)者都很擔心冷啟動問題。但根據我個人在行業(yè)內工作了 20 年的經驗，其實并不是所有 API 都必須擁有超低的啟動延遲。大家一直在努力讓自己的軟件達到最好的效果。但我們還是應該先弄清楚瓶頸究竟在哪里。

我們每年推出的版本中總有一些功能會幫助大家改善自己的工作體驗，而且開發(fā)者和公司完全不用改變自己的工作習慣。他們一早醒來，會突然發(fā)現(xiàn)軟件的延遲有所降低。這是種非常奇妙的體驗。

無服務器架構下 應用開發(fā)的實用建議

InfoQ：在開發(fā)無服務器應用時，有哪些好的實踐和策略可以提供更好的性能？

Luca Mezzarila：有幾個手段是我們可以重點關注的。我們可以從模式出發(fā)，以不同的視角看待問題。比如，當我們的解決方案其中有一部分是同步，而另一部分是異步時，同步的部分需要根據傳入的請求來擴展，方案的其余部分可以保持較低的擴展度，從而降低維護難度。傳統(tǒng)單體架構中，你往往需要優(yōu)化峰值流量、預先配置基礎設施等，但無服務器架構下這些資源都是開箱即用且可以按需擴展的。

我還特別推薦大家認真觀察并思考自己在做的工作，想想有什么可以優(yōu)化的地方。比如說有一些 SLA 或功能可以和產品團隊討論，只要一些簡單的調整就可以更加充分地利用它們，讓開發(fā)者的工作更輕松，同時給用戶帶來顯著影響。

無服務器技術的高性能和穩(wěn)定性往往是由細節(jié)決定的?，F(xiàn)在你不用再操心在哪里使用 circuit breaker，在哪里存儲內存信息，而是直接借用成熟方案，而且不用自己去維護它們，這樣你就可以專注于那些真正重要的任務。

InfoQ：您說易于使用和易于維護是非常重要的，那么您能和我們分享一下如何將應用程序劃分為小型、獨立的功能模塊，并利用無服務器架構構建和部署這些模塊嗎？

Luca Mezzarila：當我們談到分布式系統(tǒng)時，主要的挑戰(zhàn)在于建模部分。有些公司先是針對細碎的服務做出一些非常小的模塊，然后再嘗試耦合；還有些公司則是先構建一些小體量或模塊式的單體架構，然后當他們對新技術有更深刻的理解時再進一步拆分它。我認為第二種模式效果最好，尤其是當你不太確定你是否想采用微服務時。

有一些實踐可以幫助你理解如何拆分應用。首先我推薦大家了解一些領域驅動設計的知識。研究這種技術的社區(qū)提供了很多極具啟發(fā)性的方案和一些能夠幫助你拆分應用的工具。例如事件風暴就是一個很好的起點。首先，業(yè)務部門和技術部門通過事件風暴會議攜手合作，并且只關注用戶的整個使用流程。大家在白板上羅列出用戶為了完成某一項或多項任務所必須經歷的所有事件，這樣就可以直觀展示使用應用或特定功能的整個流程，看到促成流程推進的關鍵事件。它們代表著不同任務之間的邊界，接下來我們就可以順利地將各部分工作分配給各個團隊。

這時團隊已經可以從業(yè)務的角度出發(fā)，對自己想要表達的內容有了比較清晰的認知，并且可以將其付諸代碼。然后團隊就可以輕松地把一個個環(huán)節(jié)映射到無服務器服務上。而如果沒有事件風暴這一環(huán)節(jié)，直接不管不顧開始寫代碼的話，你很可能會在代碼的構建、重構和刪除上浪費大量時間。

第二點，我們不應該過早開始預先設計，你不需要在開始寫代碼前幾個月就開始構思準備。你應該采用一個非常精簡的方法，在有限的時間內收集盡可能多的信息，然后根據掌握的信息做出決定。有時你很有可能要改變原本的設計方向，而無服務器是在基礎設施級別實現(xiàn)模塊化的，所以我們就可以直接刪除或丟棄一些代碼，然后沿著更適合我們軟件的新方向前進。

此外，事件風暴的另一大亮點是你可以看到各個團隊在與哪些人交流，以及服務中的各個部分在與哪些服務溝通。這樣架構師就可以輕松調整架構，改善團隊溝通機制，對整個系統(tǒng)的認識也會更加清晰。

無服務器 VS 微服務：無服務器架構 是微服務的一種表現(xiàn)形式

InfoQ：我們談了這么多關于無服務架構的內容，但我們知道在這個領域另一項非常重要的技術叫做微服務。那么您對這兩種架構之間的關系有何看法？您認為一項技術會取代另一項嗎？

Luca Mezzarila：微服務只是一個術語，表示一個特定的實體或工作單元，而且它是完全獨立的，可以由單一團隊管理。微服務要有一個強大的封裝。而這個強大的封裝可以是由各種方式設計的，可能是代碼，可能是某種基礎設施。我認為無服務器應該算是微服務的一種表現(xiàn)形式?，F(xiàn)實應用中并不存在它們之間的硬性分割，大家完全可以用容器、虛擬機或者無服務技術等各種方式來實現(xiàn)微服務。

真正重要的是我們到底想用模塊化微服務表達什么。很多 API 其實根本沒有那么高的要求，也許我們只想用它獲取數據和查詢數據庫，這時候無服務器也是個好選擇。但無服務器可能并不適合每一個負載，所以大家不必盯著一套方案到處使用，這反而會限制你做架構優(yōu)化的能力。

在設計系統(tǒng)時，我們需要考慮太多因素，包括成本、性能、可擴展性和可靠性等等。真正有意義的是先想清楚要不要用微服務，再思考要用哪種方法來實現(xiàn)，而無服務器只是實現(xiàn)方法之一。

InfoQ：哪些企業(yè)適合使用無服務架構，哪些又適合微服務架構？

Luca Mezzarila：首先，利用無服務器構建解決方案能幫初創(chuàng)企業(yè)快速部署生產環(huán)境。而大企業(yè)顯然面臨著更大的挑戰(zhàn)，因為他們有大量的舊代碼和舊邏輯需要處理，而當初編寫這些代碼、設計這些邏輯的人可能已經離職。因此他們需要先審視整個業(yè)務體系，然后思考該如何拆分這些代碼和邏輯，從而讓它們更容易被新人理解，下一步才是思考具體該使用哪種服務。所以有時候，采用混合架構也不錯，畢竟系統(tǒng)中的某些部分可能跟容器匹配得更好，而某些部分更適合無服務器架構。

一切工作的本質都在于整合，而無服務器架構恰好是實現(xiàn)整合的出色方案。無服務器架構能用隊列輕松消化掉流量，也可以用事件或使用 Amazon Lambda 函數來與其他系統(tǒng)同步。所以每當大家談到邊緣架構時，我想到的首選都肯定是無服務器架構。

另外我還發(fā)現(xiàn)，其實 API 并沒有大家想象中那么脆弱。我們完全可以用 CDN 將流量轉出源站，無服務器在這方面也有巨大優(yōu)勢，因為大家只需按實際用量付費。所以如果絕大多數流量都流經 CDN，那我們根本不用為所在區(qū)域的源站支付多少成本。

總之，想清楚自己的軟件要表達什么是很重要的，這會為日后省下很多不必要的麻煩。

InfoQ：如果沒有無服務器架構，編程工作會變得更復雜嗎？

Luca Mezzarila：通常情況下，對于公司所掌握的每項服務、每段代碼，我們天然希望它能對應一套連貫且統(tǒng)一的代碼庫。所以團隊就得一同定義設計路徑、確定所要使用的工具等等。但遺憾的是，這樣的一致性總會隨著時間的推移發(fā)生變化。對于開發(fā)人員來說，這就像是在戴著鐐銬跳舞。所以，我認為基礎設施的模塊化表達可以在這里派上用場，我們只需根據業(yè)務稍做調整，而不必每次都重新做一遍配置。另外，從應用程序的整體性出發(fā)，我們會看到相似的情況總比特殊情況要多，而無服務器架構可以將這些相似的工作集成在架構中，減輕開發(fā)者的負擔。

亞馬遜云科技 Serverless 化 全面改造的最新進展

InfoQ：亞馬遜云科技在推動向無服務器的全面轉型方面做了哪些努力？

Luca Mezzarila：我們在亞馬遜云科技建立了多個項目。我們面向的不只是開發(fā)者群體，同時也嘗試改變企業(yè)高管層的思維方式，讓他們了解包括無服務器在內，整個現(xiàn)代開發(fā)思維所帶來的好處。除此之外，我們也有面向架構師和開發(fā)人員的項目，與他們一起走向現(xiàn)代化，也幫助他們了解如何構建事件驅動架構和微服務架構。我們也會與擁有無服務器經驗的合作伙伴通力合作，甚至可以為客戶推薦能幫其達成目標的合作伙伴。

我們?yōu)榭蛻魷蕚淞撕芏喑錆M潛力的選項?？蛻糁恍枵f明自己想達成怎樣的目標，亞馬遜云科技就能夠提供相應的協(xié)助方案，而且大部分服務都是免費的。只要我們能在建模階段把工作做到位，并在網站上發(fā)布豐富的說明文檔、博文素材、應用實例，開發(fā)人員就能切實掌握值得借鑒的最佳實踐。并且我們的努力涵蓋各個領域，能幫助任何企業(yè)在云端取得成功。

InfoQ：亞馬遜云科技自己的無服務器實踐目前走到哪一步了？

Luca Mezzarila：無服務器技術在亞馬遜云科技的內、外部工具中正在迅速普及。Amazon Lambda 函數的調用總量已達到 1 萬億。通過無服務器技術，我們部署了大量開箱即用的最佳實踐，就連可用性保障都已經在函數部署過程中被默認內置，客戶用不著為這些麻煩事分心。我們也在亞馬遜云科技內部使用它支持客戶、支撐自己的服務。

當 Severless 遇上生成式 AI

InfoQ：無服務架構在機器學習領域的前景如何？

Luca Mezzarila：現(xiàn)在已經出現(xiàn)了不少使用無服務器架構的示例，特別是在粘合各種系統(tǒng)的場景下。在我看來，最重要的就是用無服務器架構充當粘合劑，實現(xiàn)這些信息的跨系統(tǒng)傳輸，讓開發(fā)者可以專注于真正重要的事情。

關于生成式 AI，我們在亞馬遜云科技中已經成功落地。在開發(fā)層面，我們推出了 Amazon CodeWhisperer 插件，可以根據提示生成代碼編寫建議。另一項生成式 AI 服務是 Amazon Bedrock。它允許用戶選擇自己想要使用的大語言模型。我們還開發(fā)了自己的大語言模型，也就是 Amazon Titan。隨著這些服務的推出，我堅信這種幫助客戶靈活選擇、定制大語言模型的方案一定能夠大放異彩。

InfoQ：您對 AI 和無服務器之間的關系有何看法？二者有什么聯(lián)系嗎？

Luca Mezzarila：就目前來講，我覺得只能算是有松散的聯(lián)系。我們還需要進一步探索，畢竟大語言模型對內存容量有著極高的要求。盡管無服務器技術擁有自己的優(yōu)勢，但正如我之前提到的，它最大的優(yōu)勢應該是把不同的系統(tǒng)粘合起來，確保技術人員能專注于真正重要的工作。比如在 AI 語境下，你就可以專注于思考如何訓練你的模型等等。同時，我很確定會有一些通過無服務器技術實現(xiàn)的有趣應用。社區(qū)那邊就發(fā)布過不少方法，以新穎的生成式 AI 方法嘗試簡化開發(fā)者的工作體驗。我有種感覺，其實很多工作正在幕后悄悄推進，只是我們還沒看到。

面向未來，無服務器架構 將為開發(fā)者帶來怎樣的機遇？

InfoQ：您如何看待無服務器架構的未來發(fā)展趨勢？

Luca Mezzarila：我覺得最重要的還是研究客戶用例。過去幾年間出現(xiàn)了大量關于無服務器的需求。亞馬遜云科技推出的絕大多數功能都是應客戶的要求而生。未來幾年的重點應該是為無服務器重新找準定位，因為現(xiàn)在我們將其視作一種策略，而不只是簡單的 Lambda 函數。

我們有些客戶一直立足前沿，正在做一些我們從未預料的瘋狂嘗試。但同時也有很多客戶要么對服務不完全信任，要么持明確的懷疑態(tài)度，還有一些客戶并不太了解這項技術。所以我一直在努力為大家答疑解惑。我們建立了一套心智模型來幫助客戶方的開發(fā)人員、架構師和平臺團隊把自己的軟件以科學的方式映射到無服務器架構。這樣，無服務器的負載就能快速增長，因為我們以往的觀察已經證明無服務器架構具有諸多優(yōu)勢，令許多客戶從中受益。

InfoQ：對于開發(fā)者來說，無服務器架構未來有哪些潛在的機會？

Luca Mezzarila：開發(fā)人員面前的機會有很多。他們可以編寫出免維護的代碼、建立更快的反饋循環(huán)，并開始研究如何幫助業(yè)務和產品所有者一同重塑業(yè)務。還有一個挑戰(zhàn)是思維方式的轉變。企業(yè)中仍然流行一種非常集中制的思維模式，單純由組織頂層人員、或者說技術領導層來決定一切，而開發(fā)人員只是螺絲釘。他們沒有機會與產品團隊溝通，共同塑造成功的軟件。產品和技術團隊永遠在彼此指責和爭吵，我覺得必須要避免這種爭執(zhí)，讓雙方更好地合作，這才能給軟件帶來益處，進而惠及整個組織。

InfoQ：時代車輪滾滾向前，過去開發(fā)者可能更關注學習哪種語言、哪種新技術，但現(xiàn)在，特別是在疫情過去之后，企業(yè)開始更多關注利潤。他們苦苦掙扎，要在糟糕的經濟環(huán)境下生存下去。在這樣的背景下，開發(fā)人員應該掌握哪些軟技能呢？如何面對這樣的大環(huán)境變化？

Luca Mezzarila：在組織中，“軟技能”已經成為了核心技能。如果我們沒有能力開展有效溝通、做出權衡，并代表企業(yè)的利益發(fā)言，即使你可以成為世界上最了不起的開發(fā)者，你也沒法把握成功的脈搏。因為當今的現(xiàn)實是，我們寫的每一行代碼都不是為了娛樂自己而寫，而是為我們的客戶創(chuàng)造價值。

另外，開發(fā)人員現(xiàn)在需要身兼數職，他們工作中的開發(fā)占比越來越低，而需要對事物的發(fā)展變化具備更敏銳的感知。我建議大家不要局限于特定的框架或語言，而是著眼于更廣泛的問題，包括架構、安全性、平臺、基礎設施等。這些會讓我們成為更全面的開發(fā)者、更優(yōu)秀的人才。還有一點要著重強調，當你以開發(fā)者身份做出一個超出自己能力的決定時，必須意識到這不只是一項技術決策，它也一定會在架構和組織層面產生相應的影響。

我發(fā)現(xiàn)很多開發(fā)者對分布式系統(tǒng)特別興奮，或者每一種新語言都想去試試。但每一個框架都有自己的哲學、思維方式和合作生態(tài)。我覺得我們永遠都要保持開放思維。你掌握了一種編程語言或框架，這當然是好事。但與此同時你需要看看你的周圍，通過團隊內不同成員的協(xié)同，我們才能構建真正有效的功能單元，在特定場景下大放光彩。我們要做 T 型人才，涉獵廣泛的領域，并在特定的領域精通鉆研下去，同時也有具備相應的軟技能，從而在職業(yè)生涯中不斷成長前進。