IBM Bluemix OpenWhisk Google Cloud Function Azure Functions Microservices AWS Lambda Kubernetes Serverless Container DevOps

Serverless部署上雲 革新開發方式與計價模式

2017-08-21
一種稱為Serverless(無伺服器)的新興技術,正在改變軟體系統的建構與運行模式,強調開發過程不再需要管理底層伺服器資源,近來幾乎已是公有雲服務供應商兵家必爭之地。包含亞馬遜旗下的AWS(Amazon Web Services)Lambda、IBM Bluemix OpenWhisk、Google Cloud Function測試版、微軟Azure Functions,四大主流公有雲服務供應商皆已備齊。

不僅開發人員應該掌握Serverless發展技術,IT管理者同樣必須跟上開發模式的演進,畢竟在DevOps趨勢推動下,維運與開發緊密地協同工作,才有能力讓企業提高業務的敏捷性,進而達到數位轉型的願景。

脫離底層束縛的執行模式

與從字面上看來不同,所謂的Serverless並非不再需要架構在伺服器主機之上。微軟專案技術經理陳建明指出,Serverless的重點,主要在於開發方式與計價模式的改變。

傳統內部開發完成應用系統之後,要部署到伺服器系統環境,首先必須確認硬體規格有足夠能力提供順暢運行,同時需建置高可用性、系統與網路安全等機制。儘管雲端平台可以簡化伺服器的維運,但程式碼無法避免仍舊需要底層資源的支持,例如決定應用程式執行的連接埠、路由方式等環節。如今,Serverless執行模式則改變過去的思維,只要把撰寫完成的程式碼發布到雲端平台即可,運行環境會確保具有足夠的擴充性以因應流量暴增,讓開發者專注在撰寫程式碼邏輯。

概念上來說,Serverless確實類似於目前主流的Microservices(微服務)精神,把傳統大型應用系統服務,依據業務功能或工作流程,分割成有能力自主執行的個體服務。但兩者不同之處,在於Serverless是專注在應用程式執行模式,主要部署於雲端平台之上;Microservices則較偏重於架構,可以運用任何技術來實現。

微軟技術傳教士李匡正補充,Microservices架構雖毋須留意底層實作方式,但是在真實世界,隨著Microservices數量增多,部署與管理仍舊無法避免影響實體運行效能與提高除錯複雜度;而Serverless執行模式則可完整脫離底層的束縛。

開發方式與計費模式的改變

前述提到,Serverless的重點之一在於改變了開發方式。以往開發人員撰寫應用系統會基於Framework(框架),或是MVC(Model-View-Controller)架構模式,但Serverless則僅需撰寫Function,關注Input資料、商業邏輯、Output結果即可,不須管理訊息路徑、掌握細節,只要部署Function程式碼後,即可透過圖形化介面定義觸發執行的規則。

陳建明舉例,通常社交網站、電子商務網站,會有圖片上傳的功能,經過縮圖後才得以符合網頁整體呈現,因此系統中必須撰寫程式偵測新圖片,或透過撈取方式觸發執行縮圖。改用Function來執行僅需設計邏輯,可定義Input資料來源指向Microsoft Azure Blob儲存體所存放的物件,取得圖片檔案經過壓縮後,再Output拋到另一個儲存位置。當Function上傳到雲端平台,只要Blob儲存體產生事件(Event),隨即呼叫Function執行,不論是單一事件或是同時產生大量事件,皆可立即觸發執行。同時,底層所需的運算等資源,會一併立即擴充,即便是瞬間湧入龐大執行量,也足以承載。


▲微軟Azure Functions可直接透過瀏覽器介面連線到雲端平台開發與測試,在相同畫面中可即時查看Log資訊。

至於計價模式,也是Serverless的另一項特點,亦即平時Function未被呼叫執行時不會產生費用,只有在觸發之後才開始計費。陳建明進一步說明,以往雲端平台設計的計價方式,一旦開機,不論有沒有實際運行服務都得支付費用,如今則可基於Function被呼叫執行來計算,包含呼叫後執行的時間、所耗用的資源總量。對於部署於雲端平台運行的應用服務而言,可藉此大幅降低支付的費用。

「技術發展持續演進,目標皆是為了讓開發者更專注於創新應用的實作,畢竟底層硬體資源的調配又是另一門學問,轉換為Serverless之後,複雜的底層資源調度,即可全數交由雲端平台負責。」陳建明說。

專屬運行於雲端平台 以事件驅動觸發執行

目前各家公有雲服務供應商已提供不同實作Serverless框架,李匡正觀察,透過事件驅動(Event-driven)程式已被列為常見的特徵,儘管也有把容器(Container)編排管理工具Kubernetes列在Serverless框架之中的看法,凸顯這類應用不見得只能經由事件來驅動,不過就目前來看,事件驅動的確是各家供應商實作的主要方式。

經由事件驅動Function執行的模式,讓Serverless不僅為獨立運行,亦可擴展出更多適用的情境,也就是結合現有的SaaS服務一起協同工作,例如將邏輯設計為檔案上傳到Dropbox、OneDrive等雲端服務平台,平時未被觸發執行不需收費,一旦事件發生才觸發執行。

物聯網的應用場景也相當適用Serverless。在初期規畫階段,可能難以預測成長規模,即可借助雲端平台處理擴充性的能力,每次呼叫Serverless才會出現Instance(執行個體),一旦使用量增長、前端裝置增加、事件觸發次數暴增,雲端平台皆可簡單地增添更多資源來支持應用規模的擴張。

當然,在雲端應用普及之後,企業也可能評估在本地端打造類似的協同工作環境,但實際上難度不低。甚至對於仍著重於開發自家網站或應用程式的企業,可能根本無須發展Serverless的基礎架構。畢竟底層硬體的管理還是很複雜,對雲端服務供應商來說,仍舊需要建置IT資源自動擴建、高可用性等伺服器應用環境所需要的機制。如此龐大規模的平台,不大可能由企業投資自建。但是對於雲端服務供應商而言,底層實體架構是基本必備的建置,自然能發揮應有的效益。

實際應用Serverless案例 降低過半支出

才推出市場不久的微軟Azure Functions,在今年已經擁有實際應用案例。李匡正指出,Azure Functions是Azure平台上提供的Serverless解決方案之一,也最具代表性。在今年四月,合作夥伴鼎新電腦推出的A1商務雲,已成功採用Azure Functions來達到協同工作 「A1商務雲是鼎新電腦推出的SaaS。原本的需求是,每當新用戶註冊會員之後,可透過SendGrid來發送感謝郵件,並且串接Slack通知內部相關人員有新用戶註冊,同時這些註冊名單也會彙整到內部資料庫保存。」李匡正說明。這一連串的動作,過去作法通常必須先建置伺服器,之後再利用程式碼定時探詢。

「但微軟的想法是必須建置兩台虛擬主機互為備援,才有服務層級協議(SLA)。畢竟新會員註冊加入關乎商業收益,絕不能出差錯。即便這件事對企業而言很重要,但實際上產生的數量並不多,因為服務再受歡迎也不可能分秒都有新會員加入,但是為了支援新應用,鼎新電腦還是準備了A2(2個運算核心、4GB記憶體)等級的執行個體,一個月要花費二百多美元。」李匡正說。

如今Azure Functions改變了計價模式,客戶的應用成本正可藉此大幅降低。於是鼎新電腦調整工作流程,把訂單系統產生的JSON檔案,透過Web API拋送到Azure Storage Queue之後,才觸發Function執行以SendGrid發送郵件、Slack通知後台人員等一連串的工作流程。其中,只有觸發Function執行的那段期間才會收費。「整體系統建置完成後,相同的功能採用Azure Function實作,一個月的費用不到一百美元,大約只是原本的三分之一。」李匡正強調。此外,針對應用情境提供的Serverless Framework,勢必會搭配相關管理機制,例如Azure Functions會詳加記錄每次來自Queue所觸發的工作流程,日後還可藉此達到稽核管理。

整合Application Insights建立失敗追蹤與處理

長期以來,開發工具可說是微軟的強項之一,即便進入雲端世代同樣如此。陳建明說明,Azure Functions可直接透過瀏覽器介面連線到雲端平台開發與測試,在相同畫面中可即時查看Log資訊。整體操作介面設計也相當友善,例如在開發畫面中選擇Integrate,可發現內建Trigger、Input、Output方法的樣本,藉此協助開發者快速上手,而且不需要特殊的開發工具,只要懂得JavaScript、C#語言,立即可開始實作。

對於開發者或團隊來說,當應用服務愈來愈大,開發環境勢必變複雜,但Serverless本身為輕量型程式,開發與運行環境都在雲端平台,可較以往更便於採用。「由於Serverless運行的Function必須部署到雲端平台,亦可藉此達到自動化持續整合與持續交付(CI/CD)。例如可以在Azure Functions中,指定程式碼放在GitHub網站中的Repository,也就是指定分支(Branch)版本名稱,當GitHub的Repository有變動,就自動更新Azure Functions的程式碼。開發者撰寫程式碼後,點選提交(Commit)隨即更新。」陳建明說。

當然還有更多的應用模式,由於主流開發方式是以不同分支版本為基礎,亦可藉此實作A/B測試,只要開兩個Azure Functions,目標指向不同分支版本,再執行Switch,透過操作介面點選即可完成。Azure Functions執行後需要計費的細節,可透過呼叫記錄查看,像是次數、運行時間,都可以清楚條列;同時亦有助於除錯,在呼叫記錄介面中可查看執行細節。

不過,若能夠進一步整合Azure Application Insights,程式碼中不需要特別設計,即可達到即時監控串流,查看Azure Functions執行狀況,並且以圖形化方式呈現,例如即時Request狀態、伺服器擴充數量、運算資源使用量等細節。

除了即時監控串流,統計數據還可進一步分析,也是整合Azure Application Insights來提供,開發者可直接修改範本,透過SQL-Like邏輯的Query語法來分析歷史資料,例如查看Azure Functions被觸發最多次的期間等更多圖表資訊。其中也包含開發者相當在意的失敗追蹤(Tracking Failures)機制,若程式碼撰寫錯誤,產生了許多例外記錄,Azure Application Insights可依照內建40種不同類別區分例外狀況,以便讓開發者點選類別後,指出是由哪一段程式碼所引發的錯誤。

追蹤到失敗原因後,亦可發出Ticket請求修復。陳建明解釋,在Azure Application Insights操作畫面上設計「New Work Item」,點選後可選擇失敗追蹤系統,目前可支援微軟自家的VSTS以及開放陣營的GitHub,皆可新增Ticket交由工程師來處理問題,待程式碼更正後再透過自動部署更新。

他強調,Azure雲端服務已經把DevOps的各個階段串接完成,從開發、部署、監控,再到發現執行失敗後的追蹤、事件處理工作項目指派,最後又回到開發人員,正可成為實踐DevOps所需的自動化協作平台。


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!