嘉賓｜肖雨濃
2014 年，Serverless 架構進入大眾視線，當時業界普遍認為，Serverless 化可大幅降低 IT 成本，將雲的費用減少 10%-90%，同時還能提高服務部署效率。
InfoQ：能否為大家介紹一下您目前的工作內容和職責是什麼？
肖雨濃：我目前在 Netflix 帶領 FaaS 和 API 平臺團隊，Netflix API 是一個 tier-1 服務，通過這個服務，來自 Netflix 所有客戶的每一個單個需求都可以平滑經過。基於這個 API 服務，我們還可以將後端的上百個微服務整合進一個連貫的服務裡，便與用戶訪問。我們當前正在構建一個 FaaS 平臺來幫助工程師們快速開發，測試並維護這些 API 服務，通常情況下，這個平臺會被定製到每一個設備裡。
InfoQ：實踐 Serverless 過程中給 Netflix 帶來哪些方面的優化？在您看來 Serverless 架構適合哪些業務場景，不適合哪些場景？（Serverless 模式能給 Netflix 降低多少成本？）
Netflix 的產品在設計上就已經被賦予了創新的基因，除了不間斷的 A/B 測試之外，每週都會發布很多新功能。為了確保這樣高強度的工作成果，我們需要一個 API 服務平臺來助理客戶端工程師快速而有效的將更改的需求部署到服務層。FaaS 通過把那些與服務相關的所有平臺組件抽象為業務邏輯本身來實現這一目標的，這樣可以使工程師能夠更專注於開發優異的新功能，而不是編寫那些冗餘而又不得不寫的代碼。
此外，即使對於經驗豐富的服務器工程師而言，運行服務的可用性超過四個 9 也是很困難的。 因此，我們集中操作的 Serverless 模式能夠為我們提供一個平臺，即使沒有服務器和運營經驗的工程師也可以開發高可用的服務。
InfoQ：能否進一步詳細介紹 API Platform 的架構？目前 API Platform 是如何落地 Serverless 的？
在更高層面上，API 平臺由 FaaS 平臺組成，該平臺允許工程師將用戶業務邏輯的功能部署為高可用的生產服務。
InfoQ：Serverless 架構是否是微服務的極致？您團隊接下來的優化重點是什麼？
無服務器在實踐場景裡是可以考慮權衡點的。 通過採用 FaaS 模式，本質上是對交易速度和可能性的定製化。有些應用程序的 FaaS 服務表現得很好——Netflix API 的情況就是如此，我們運行的是相對統一的微服務，只需要訪問和改變下游服務的數據。 然而，如果服務需要定製化，例如需要改變服務平臺的各個組成部分，像 RPC，數據訪問，緩存，認證等，那麼 FaaS 模式可能無法為這些服務提供足夠的靈活性。
我們目前的重點是完成將舊版 API 服務遷移到新堆棧。之後，我們的重點可能會包括很多方面，例如性能，既要降低成本，又要改善客戶體驗，以及基礎架構和平臺改進等其他領域。
InfoQ：能否結合實例談談 Serverless 中，怎樣的函數依賴關係是合理的，從業務邏輯上如何評估哪些關鍵路徑需要報警，哪些允許失敗？（如何防止錯誤地消耗大量資源進而增加大量費用？）
就依賴性而言，我們允許用戶隨意導入第三方庫，當然，這意味著工程師需要對安全性和性能等方面進行判斷。
InfoQ：如何決策或對比使用公有云 FaaS 服務或私有云自建 FaaS 服務？
這歸結為典型的“自建 or 購買”問題。我認為面對這個決定時應該務實。當我們首次設計 FaaS 平臺時，我們考慮了諸如 Lambda 和 App Engine 等公共選項。如果符合我們的場景，我們當然很樂意使用現成的解決方案。
事實證明，我們需要一個能與現有 Netflix 服務平臺組件（如度量，警報，服務發現等）集成的平臺，而且這種與高級 FaaS 平臺的集成將是一個很困難的過程。
另外，我們需要全面瞭解是什麼樣的服務在使用 FaaS 平臺。自建意味著可以完全控制操作系統，需要給運維人員提供調試服務和可視化工具。
顯然，自建 FaaS 平臺需要花費大量的精力、時間和成本，所以我們不會輕易做這樣的決定。然而，當時我們找不到滿足要求的開源方案或公開的 FaaS 選項。
這並不意味著大家都要模仿 Netflix 的腳步。如果符合需求的開源或公開 FaaS 選項存在，那麼絕對要去使用。機會成本也是一個重要指標。技術只是達到目的的手段 - 我們當然應該使用最好的工具來完成這項工作，通常這意味著購買成熟的方案而不是自建。
InfoQ：對於 CI/CD 與 FaaS 的結合，有什麼樣比較好的建議？
提供強大的一流測試框架非常重要。我們在設計 FaaS 平臺的時候考慮到了測試，創建了一個測試框架，其中包含一流的模擬功能以及與開發人員工具緊密集成的特性，使工程師可以非常方便地使用 FaaS 平臺編寫單元，集成和端到端測試。
我們的測試框架主要優點之一，是允許在本地或在 Jenkins 上單獨測試其功能，而無需將代碼部署到雲中。這種易用性使我們的客戶能夠編寫測試，而這有助於提高服務的可靠性。
InfoQ：目前業界全面落地 Serverless 尚且遙遠，且沒有統一的構建標準，如何確保你們的實踐方向是正確的？能否分享歷年過程中你們的經驗教訓？
目前大多數 Serverless 解決方案都適用於批量和事件驅動的任務，這些任務對延遲不敏感。然而我們認為 Serverless 也應該被考慮用於生產服務，因為它能通過抽象化平臺和基礎設施來減少操作和代碼複雜性。
對於我們來說，Netflix API 組織中有明確的需求，需要 FaaS 模式來支持服務型工作負載。我們相信通過與其他公司的交流，大家對服務型 FaaS 平臺會有濃厚的興趣，大多數團隊服務都只是為達到目的一種手段，沒人激勵他們，也沒人關心服務是如何部署的，只需要它們可靠的執行業務邏輯。
我認為 FaaS 是一種自然演變，許多年前，大多數服務使用定製軟件在整個堆棧中運行，並在每個公司內部數據中心運行。現在，我們正朝著一種模式邁進，在這個模型中，我們將組件進一步商品化，並進一步向前推進。我們開始使用 IaaS 商業化硬件和數據中心（例如 AWS EC2），然後轉向將平臺與 PaaS 的某些部分商業化（例如 Heroku 或 Google Cloud Platform）。這種自然演變促使 FaaS 出現，一切都由平臺提供，而只有業務邏輯是函數本身的。
InfoQ：隨著容器和 Kubernetes 技術的興起，當前有很多基於這兩種技術構建的 Serverless 架構，比如 Fn、Kubeless、OpenFaaS、IronFunctions 等，您如何看待容器技術尤其是 Kubernetes 為 Serverless 架構帶來的機遇？
如此多 FaaS 平臺構建於 K8s 之上的原因之一，是 K8s 將基礎架構和平臺抽象為在容器上構建可擴展和可靠的服務所需的事實。這是非常強大的，因為它意味著 FaaS 框架可以專注於函數運行時。
這一塊將繼續演變，我希望看到更多的 FaaS 框架出現，尤其是能夠滿足大規模服務風格工作負載需求的那些（能夠考慮到豐富的指標，自動調整，性能優化）。 我相信 K8s 將以更大規模運行的能力發展，這將使它更適合超過 5000 個物理節點的使用情況。
InfoQ：在涉及整體架構的重構中，您認為應當採用漸進的方式逐步替換還是完全重寫？如何防止技術人陷入下一個酷技術的陷阱？
工程師應該務實，對體系結構進行漸進式改變。立即改變一切只會增加項目的複雜性，風險和時間成本。漸進式改變意味著我們可以縮短反饋週期，為業務更快實現收益，並通過一次只更改少數組件來降低風險。
我們應該權衡每個決定的利害關係，尋求公司內部的廣泛一致，並尋求異議。在採用新技術時要謹慎，捫心自問，“為什麼選擇這項技術？”如果你不能以滿足團隊或組織的方式來回答這個問題，那麼你應該三思而後行。仔細考慮採用新技術的意義是什麼，擁有更廣泛的用戶和支持基礎？提供了一套好的工具來進行運維和調試？文檔是否明確？維護週期有多長？採用新技術對整個組織的影響是什麼？平臺團隊現在需要在整個組織中支持這項新技術嗎？
例如，我們 FaaS 平臺採用了容器技術，原因很特殊。它可以確保工程師隨時隨地運行服務，併為我們提供不可變的構建組建。這個決定會對團隊有一些影響，需要在 Netflix 內部創建一個新團隊，負責構建一個容器編排系統。決定使用一項新技術經常會給整個公司帶來不確定的後果。
InfoQ：在 FaaS 服務的開發過程中，工程師最關注點的是什麼？
對於開發體驗，我們專注於 FaaS 平臺的人體工程學。這是工程師使用 FaaS 平臺的最大反饋。 因此，我們專注於構建開發者工具，使工程師能夠在其開發機器上本地開發和調試其功能，包括尾部日誌和附加調試程序的功能。
InfoQ：將越來越多的核心功能部署雲上的時代，您認為工程師應該將精力更多地放在哪些方面？
工程師應該將重點放在與團隊有關的事情上，大多數情況下，這不再意味著基礎架構或服務平臺。對於使用 FaaS 平臺的工程師來說，這能讓他們更專注於產品創新，為 Netflix 超過 1.25 億的會員提高用戶體驗。
受訪嘉賓簡介
肖雨濃，目前是 Netflix 位於美國加利福尼亞州洛斯蓋多斯 (鎮) 的首席軟件工程師，帶領 Netflix API 平臺設計和架構團隊。在此前，他任職於 AWS 和 Joyent，主要方向是分佈式系統，並幫助規劃和構建了多款雲計算產品，例如 AWS IAM 和 Manta。與此同時，他也在維護開源項目 Node.JS 框架的校正。Yunong 獲得了滑鐵盧大學計算機工程榮譽學位。
閱讀更多 InfoQ 的文章
