數年以前,物理服務器還是一項基礎技術,是每個數據中心跳動著的數字心臟。然而云計算出現了,并得到了實際運用。如今,隨著企業不斷地將越來越多的服務轉向云服務提供商,本地服務器似乎正在面臨著生存危機,成為了瀕臨消亡的產品。
無服務器計算正在加速本地服務器的淘汰進程。轉向云服務提供商以動態管理機器資源的分配,以及僅針對應用程序消耗的實際資源量向用戶收費的概念正越來越受到人們的歡迎。技術媒體與培訓公司O'Reilly在2019年末進行的調查顯示,40%的企業(調查對象廣泛分布于不同的地區和行業)已經采用了無服務器技術。
我們不要被它們的名字所誤導,盡管名字叫做無服務計算,但是無服務器計算仍然依賴于服務器。無服務器軟件開發商Volare Systems的老板Joe Wilson指出:“無服務器計算實際上是在服務器上運行的,只不過你的云提供商會根據需要配置服務,你不再擁有虛擬服務器或應用程序服務。”本質上,無服務器是一種應用程序部署架構,開發人員可以編寫代碼并按需執行。
無服務器不僅是一項技術,更是一種查看基礎IT運營的全新方式。Liberty Mutual Insurance的云平臺策略高級架構師Brent Austin說:“無服務器的主要好處是,它們將迫使你考慮以云原生方式設計系統。如果以無服務器優先的思維方式設計應用程序,那么你可能會擺脫系統內特定技術選擇的束縛,從而部署具有優秀費效比、可擴展性和高彈性的架構。”
無服務器計算的部署方式有許多種。埃森哲負責云戰略、架構和交付的常務董事Miha Kralj稱,許多用例將重點放在了相對簡單的需求上,例如目前通常用無服務器方式編寫的網頁應用程序。“由于無服務器平臺會在需要時自動擴展,因此可以快速地開發簡單的應用程序,同時不必擔心基礎設施的復雜性。”
無服務器擅長于不同應用程序系統的協調。Kralj指出:“無服務器計算非常適合檢測事件并通知另一個應用程序或系統。例如,數據庫中的更改何時觸發代碼更改或安全性審查。無服務器可能是在系統之間創建這類自動化工作流的最佳方法。”
無服務器還可以滿足一些“附加”需求。Kralj說:“當客戶擁有一個大型或復雜的解決方案,并且需要添加一些功能時,無服務器可能是理想的選擇。”例如,與打開大型應用程序插入簡單的函數(例如添加新來源中的客戶記錄)相比,用戶創建一個無服務器函數就可以捕獲新的輸入并調用應用程序的API。Kralj說:“這是一種快捷、方便且可靠的方法。”
從本質上講,無服務器計算架構往往比替代方法更具成本效益。Austin 建議:“無服務器的一項核心功能是,它可以向上擴展或向下收縮直到零,這樣一來,當不使用它們時,你就不必為之付費。”
咨詢公司SPR的移動與新興技術執行總監Kevin McMahon說,通過無服務器技術,客戶實現了只為消耗而不為容量付費。他將無服務器模式與擁有汽車和使用拼車服務進行了比較。他解釋說:“在拼車服務推出之前,如果你想從A點到達B點,那么你可能要擁有一輛汽車,并購買保險和維護它們。有了拼車服務后,你不再需要為汽車操心,只需在需要時支付從A到B的費用即可,也就是說你只需為需要完成的工作付費,而不需要為額外的基礎設施和維護付費。”
IT服務管理公司Aptum的云負責人Craig Tavares指出,無服務器計算還可以幫助采用者避開資源過度分配導致的相關成本,從而確保支出與實際消耗一致。此外,通過將應用程序分解為簡單的由目標驅動的函數,用戶可以在云端快速且低成本地部署和分發應用程序。Tavares補充說:“開發周期中速度的提高也加快了產品的上市速度,從而使公司能夠專注于持續改進和客戶滿意度。”
Medinas的首席技術官Tim Growney說,由于采用的定價方式為按次付費,因此沒有正常運行時間成本。“使用情況肯定會因用例而異,但是對于我的公司來說,我們基本上都能夠享受到AWS的免費套餐,這使我們的Web托管成本幾乎為零。”
無服務器會影響IT工作負載嗎?
無服務器計算可以通過多種方式減輕IT工作負載,尤其是可將員工從服務器性能、可靠性、維護和安全任務等例行性管理工作中解放出來。Austin稱:“實施健康檢查以確保應用程序正常運行,管理底層操作系統以打上最新的安全補丁,以及確保為底層基礎設施配備了足夠的能力以處理峰值工作負載等需求都可以通過無服務器平臺進行處理。”
無服務器還有效降低了開發人員的工作量。Austin 指出:“無服務器可以減少代碼的編寫量,特別是基礎設施代碼,這對基層IT人員很有吸引力。利用無服務器技術配置基礎設施配置,可讓更多的開發人員從事業務功能的部署工作,對于IT部門而言這是一項巨大的優勢。”
加快開發速度還可以使企業更加靈活,更具創新性。Kralj說,無服務器是將想法轉變為實用解決方案的最快方法。“該方法非常適合應用程序的快速開發,你只需幾行代碼就可以搞定。”
盡管不會抵消技術上的眾多優勢,但是無服務器有時也會導致工作量增加。災難恢復服務提供商Sungard Availability Services的資深架構師Greg Cox說:“創建功能以及將API融合在一起以完成業務需求會涉及更多的工作。”
糾錯也可能會增加工作負載。數字業務平臺開發商AHEAD的云首席顧問Bert Johnson警告說:“如果安全性、測試、監控和配置管理沒有實現標準化,那么無服務器的錯誤就會變得很隱蔽。” 他指出,錯誤會放大軟件開發過程中的缺陷,同時迫使開發人員放棄關鍵任務轉而加入搜索和修復任務。
盡管有著眾多的優點,但是無服務器計算也存在一些明顯的缺點。例如,該技術在支持長時間運行方面并不是特別好。McMahon說:“如果你運行的任務或流程需要花費很長時間進行計算,那么無服務器將不是最佳選擇。當前,Azure Functions和AWS Lambda分別最多只能運行10分鐘和15分鐘。”
冷啟動也會使一些無服務器采用者感到不便。McMahon解釋說:“冷啟動是一個時間段,通常只有幾十毫秒,需要喚醒一個函數才能執行。對于大多數用例來說,這個時間可以忽略不計,但是在某些用例中,這種延遲是不可接受的,并且無服務器計算可能也不是理想的選擇。”
潛在的采用者也可能因供應商鎖定的顧慮而放棄無服務器技術。Kralj警告稱:“IT和開發主管應該意識到,AWS Lambda、Azure Functions和Google Cloud Functions等主要的無服務器系統是不能互換的。”
從安全角度來看,無服務器也帶來了獨特的挑戰。安全軟件開發商Aqua Security的戰略副總裁Rani Osnat指出:“一方面,較短的運行時間和與底層主機操作系統的隔離降低了風險。另一方面,如果函數被賦予過多權限或有易受攻擊的組件,那么這可能導致無服務器函數會成為不法分子發起攻擊的跳板。”對此,Osnat建議應對無服務器計算進行安全配置,并監視其異常和濫用行為。
無服務器采用者在計算其容量需求時也應保持謹慎。Growney說:“傳統服務器在容量不足時會報錯,從而阻止了成本的攀升。無服務器則可以以相對不受限制的方式進行擴展,如果你沒有注意到這一點,那么可能會導致出現昂貴的賬單。”
最后,轉而采用無服務器技術的企業可能會看到他們的工資總額出現增長。從事IT招聘的公司Jefferson Frank的執行副總裁兼云負責人Patrick Navarro表示:“如果你的企業專注于技術,那么一個非常重要的支出是招聘開發人員。合格且熟練的開發人員的薪水可能不高,但是招聘和保留住他們的費用卻很高。”
隨著云提供商持續引入新服務,IT領導者面臨著一個挑戰,即所有內容都整合在一起以形成一個連貫的解決方案,并且這個解決方案還要能夠整合運行在云端或數據中心上的老舊應用程序。Kralj說,無服務器計算非常適合這些新的存在集成工作的挑戰。“無服務器具有響應式和事件驅動的特性,因此它們可以實現現代解決方案所需服務之間的各種實時連接。”
新部署者應當以評估所有顛覆性技術一樣的方式評估無服務器。IT咨詢公司Anexinet的云架構師John Kovolski建議:“在部署之前還是要花點時間學習和理解無服務器產品。至少,要有一個全面思考的過程。”為了深入了解潛在的運營優勢與成本優勢,Kovolski建議對當前系統的性能進行評估,然后再與計劃中要更換的無服務器進行比較。
Growney建議逐步采取無服務器技術。他解釋說:“無服務器并不是一項全能的技術。它們只是可以根據需要被使用。”
作者:John Edwards 為資深商業技術記者,曾在《紐約時報》《華盛頓郵報》以及CIO、Computerworld、Network World、CFO Magazine、IBM Data Management Magazine、RFID Journal和Electronic Design等眾多商業和技術刊物上發表過大量文章。