以團隊為優先：使用 Laravel 與 Bref 進行無伺服器工程

錄影

https://www.youtube.com/watch?v=41JNqwdVmfk

平台工程方法下的無伺服器開發

• CNCF 定義：無須管理伺服器即可建置及執行應用程式。
• 優點：
• [ 1 ] 降低營運負擔。
• [ 2 ] 降低成本。
• [ 3 ] 加快開發速度。
• [ 4 ] 免除佈建伺服器的工作。

導入目標與規則

• [ 1 ] 目標：
• 解決客戶的實際問題。
• [ 2 ] 規則：
• 創造真正的價值。
• 符合 PHP 團隊的工作方式。
• 整個團隊都能維護，而非僅有一人能負責。

案例研究與經驗

• [ 1 ] 處理合作夥伴資料的簡易 API：
• 使用 API Gateway 與 Lambda 將資料儲存至 S3。
• 流量成長 200 倍，卻未發生效能問題，可謂相當成功。
• 隱藏的問題：只有一個人能夠維護。
• 經驗：問題不在程式語言（Python），而是與團隊文化衝突，且團隊不熟悉所用工具。
• [ 2 ] 機器學習無伺服器平台：
• 既節省成本，也深受資料科學家喜愛。
• 問題：一般開發團隊無法使用。
• 經驗：需要的是適合主要開發者群體的解決方案，而非僅服務專家。
• [ 3 ] AWS Amplify：
• AWS Amplify 實驗的細節未完整收錄，但推測這也是一次嘗試，目的是為更廣泛的團隊尋找可長期維持的無伺服器解決方案。

主要心得

• [ 1 ] 共同承擔：
• 真正的成功需要共同承擔責任，並尊重團隊文化。
• [ 2 ] 適合團隊：
• 解決方案必須符合團隊的工作方式，且整個團隊都能維護。

結論

• 要有效導入無伺服器技術，必須理解並尊重團隊文化、確保可維護性，並為所有利害關係人創造真正的價值。

新原型面臨的挑戰

• [ 1 ] 初步反應：
• 新的無伺服器原型偏離實驗室團隊使用熟悉工具所建立的「肌肉記憶」，因而遭到抗拒。
• [ 2 ] 學到的經驗：
• 在引入重大變革前，團隊對熟悉工具的信任與自在感至關重要。

團隊經驗對比

• [ 1 ] Ruby 團隊：
• 成功導入無伺服器技術。
• [ 2 ] PHP 團隊：
• 因認知負荷過高而陷入困境。
• [ 3 ] 體悟：
• 成功與否的差異，取決於認知負荷以及對工具的熟悉程度。

轉向平台工程的新策略

• 朝平台工程發展，讓整個團隊都能使用並維護無伺服器技術。

重新評估目標

• 舊目標：只求交付無伺服器專案。
• 新目標：交付整個團隊都能操作的無伺服器專案。
• 成功指標：團隊的信心，而非函式數量。

讓無伺服器技術適用於 PHP 團隊

• 需要熟悉的工具：
• PHP 開發者需要自己用得自在的工具。
• 自訂 Runtime：
• 早在 2018 年便開始於 Lambda 使用 PHP 自訂 Runtime。

解決方案：Laravel 與 Bref

• [ 1 ] Laravel：
• 開發者已熟悉且信任 Laravel。
• [ 2 ] Bref：
• 處理在 Lambda 上執行 PHP 的複雜細節。
• [ 3 ] 組合式解決方案：
• 團隊可以維持現有工作負載，同時進行測試並享有無伺服器技術的優點。

第一個正式環境應用程式

• [ 1 ] 應用：
• 處理大型 CSV 檔案。
• [ 2 ] 技術堆疊：
• 使用 Amazon S3 Select 在 Lambda 中篩選資料，確保效能可預期。
• [ 3 ] 結果：
• 處理速度快，並免除伺服器管理工作。

團隊導入與成功

• [ 1 ] 初階開發者：
• 只要按照文件，即可開發並部署無伺服器應用程式。
• [ 2 ] 角色轉變：
• 他的角色從瓶頸轉變為教練。
• [ 3 ] 可重複性：
• 這套方法變得可重複運用，不再依賴單一專家。

結論

• 要成功導入無伺服器技術，必須理解團隊動態、善用熟悉的工具，並營造讓整個團隊都有信心操作無伺服器應用程式的環境。

無伺服器技術的新挑戰

• 無伺服器特有問題：
• 冷啟動、逾時及記憶體限制。
• 在單一 Lambda 中執行完整的 Laravel 應用程式（Lambda Lift），會帶來套件過大與權限複雜等挑戰。

實用解決方案

• [ 1 ] 緩解措施：
• 使用 Lambda Layers，並為敏感函式設定獨立的 IAM Role。
• 為計時器採用 Provisioned Concurrency，並使用事件驅動方法處理冷啟動。
• [ 2 ] 驗證：
• 經過討論及備受敬重的工程師驗證後，確認在 Lambda 上執行單體式應用程式是可行的做法。

學到的經驗

• [ 1 ] 微服務與單體式架構：
• 不一定非得追求完美的微服務架構。
• 對這些團隊而言，Lambda Lift 是務實的選擇，既可共同承擔責任，也能快速推出功能。
• [ 2 ] 團隊信心：
• 比採用哪種特定架構更重要。

擴展解決方案

• 可重複使用的範本與標準指令：
• 建立可重複使用的範本與標準指令，確保新團隊不必從零開始。
• 減輕平台團隊的支援負擔。

平台工程

• [ 1 ] 定義：
• 建置共用服務，協助開發團隊以更低的認知負荷，更快交付功能。
• [ 2 ] 指導原則：
• 遵循業界最佳實務，例如 CNCF 平台白皮書。
• [ 3 ] Team Topologies 模型：
• 目標是讓未來的團隊專注於功能，而平台團隊則針對常見問題提供標準解決方案，以降低他們的認知負荷。

平台設計

• [ 1 ] 配合現有團隊：
• 平台設計符合現有團隊結構與文化。
• [ 2 ] 降低認知負荷：
• 避免採用會讓團隊望而生畏的複雜無伺服器架構。
• 使用負載平衡器，將流量路由至適當的運算目標（例如 PHP 團隊熟悉的 Lambda）。
• [ 3 ] 資料庫選擇：
• 選擇與 MySQL 相容的 TiDB 服務，讓開發者只需進行最少變更，就能繼續使用熟悉的 SQL 指令。

本機開發體驗

• 工具：
• 使用 Docker 與 LocalStack，讓開發者能以相同的 PHP 指令，在自己的筆記型電腦上執行完整應用程式。
• 大幅降低導入阻力。

轉型成果

• [ 1 ] 角色轉變：
• 他的角色從瓶頸轉變為推動者。
• [ 2 ] 規模化成功：
• 將這套模式擴展至多個團隊。
• 新團隊導入無伺服器專案的速度大幅加快。

結論

• 平台工程方法著重降低認知負荷、善用熟悉的工具，並提供可重複使用的範本與標準解決方案，徹底改變團隊導入無伺服器技術並擴大其規模的能力。

平台的主要特性

• [ 1 ] 自助式系統
• 指令與自動化 CI/CD 管線。
• 不再需要提交支援請求，讓開發者能專注於自己的工作。
• [ 2 ] 防護機制
• 結構化日誌及具備警示功能的 Sentry 等工具。
• 包含 Lambda 函式，以及如何解決問題的指引。

平台的演進

• 初始階段：密切合作。
• 目前階段：朝「X as a Service」模式發展，讓平台成為自助式產品。
• 目標：讓自助服務自然融入文化。

持續進行的工作

• 流程整合：
• 將無伺服器模式納入 Sprint 規劃、程式碼審查及回顧會議。
• 確保整個團隊對使用此系統都有信心。

三階段路線圖

• [ 1 ] 適應：
• 從範本與指導開始。
• [ 2 ] 標準化：
• 將測試及部署自動化，直到成為標準作法。
• [ 3 ] 擴展：
• 將此模式擴展至更多產品，並持續改善。
• [ 4 ] 成果：
• 這個簡單的循環能提升團隊生產力，並做好迎接未來的準備。