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

不僅開發人員應該掌握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所需的自動化協作平台。