隨著雲端技術的發展，無伺服器架構日漸普及，有效整合各種受管服務成為提升應用程式效能的關鍵。利用 AWS 提供的 EventBridge、Step Functions 等服務，可以簡化事件處理、資料轉換和流程協調，減少對 Lambda 函式的依賴，實作更精簡、高效的無伺服器應用架構。此外，持續交付在無伺服器應用開發中扮演著至關重要的角色，透過及早建立自動化佈署管道，並將應用程式持續佈署至生產和非生產環境，能有效縮短交付週期、提高軟體品質和穩定性。值得一提的是，環境概念在雲端時代逐漸淡化，重點在於如何有效利用 AWS 帳戶來管理和佈署應用程式，而非拘泥於傳統的環境區分。
什麼是伺服器無法管理的基礎設施？
隨著雲端運算的出現，將伺服器視為「寵物」的觀念開始被視為過時和低效。企業現在可以在暫時的虛擬機器上執行軟體，工程師被鼓勵將這些按需伺服器視為「牛」，在大型同質化群體中默默地工作。
基礎設施即程式碼（IaC）的一個超能力是範本化應用程式的能力。這種方式，IaC 支援可丟棄的商品模型。應用程式被轉換為可以用來建立無數副本的範本（見圖 6-10）。此超能力的一個常見應用是預生產環境中的微服務組態。
圖 6-10 顯示了一個具有多個例項的單一應用程式，每個例項都標有不同的標籤。通常，階段對應於環境，例如生產、預生產或效能等。
玄貓如何看待基礎設施即程式碼？
玄貓認為，基礎設施即程式碼（IaC）是一種強大的工具，可以幫助工程師自動化基礎設施組態和管理。透過使用 IaC，工程師可以定義基礎設施的架構和組態，並使用程式碼來管理和維護它。
玄貓還指出，IaC 可以幫助工程師實作可重復性和一致性，減少人為錯誤的風險，並提高基礎設施的可靠性和安全性。
什麼是直接服務整合和委託給專家？
直接服務整合是指將多個服務整合到一起，以提供一個完整的解決方案。委託給專家是指將某些任務或功能委託給具有專業知識和技能的人員或團隊，以確保高品質的結果。
在雲端運算中，直接服務整合和委託給專家是兩個重要的概念。透過整合多個服務，企業可以建立一個完整的解決方案，以滿足其業務需求。同時，透過委託給專家，企業可以確保其基礎設施和應用程式得到正確的組態和管理。
什麼是受管理的服務？
受管理的服務是指由雲端運算提供商提供的一種服務，該服務封裝了事件消費、事件生產和度量發射。受管理的服務透過 API 對外暴露其內部邏輯，使用者可以透過 API 請求或 SDK 來存取和使用該服務。
受管理的服務提供了多個優點，包括：
- 預設度量：每個受管理的服務都會發射有關其使用和效能的度量，這些度量可以用來建立警示和儀錶板。
- 事件：受管理的服務通常會執行回應入站事件，並產生出站事件。這些事件可以透過 EventBridge 來消費。
- 共同責任：AWS 的產品和營運團隊負責設計、構建和營運每個受管理的服務的程式碼。這種責任分工減少了使用者需要進行的無差別重復工作，並影響了應用程式安全性、測試、營運和總擁有成本。
什麼是函式呼叫函式？
函式呼叫函式是指一個 Lambda 函式呼叫另一個 Lambda 函式。雖然這在技術上是可行的，但這種做法通常被視為反模式。
函式呼叫函式會緊密耦合業務邏輯的執行，使得處理失敗和重構變得困難。如果呼叫函式需要等待被呼叫函式的回應，這將違反無伺服器計算的按使用付費性質，因為您將為此空閒等待期付費。函式等待其他函式回應將違反無伺服器計算的按使用付費性質。
伺服器無法實作的應用：從函式到無函式的整合模式
在伺服器無法實作的應用中，管理服務不僅可以促進Lambda函式之間的整合，還可以在某些情況下完全取代Lambda函式。事實上，伺服器無法實作的工程師越來越多地遵循「無函式整合模式」，只在絕對必要時使用Lambda函式，否則則使用各種管理服務來委託工作給AWS。
編寫和佈署Lambda函式需要明顯的勞動成本。函式的程式碼必須進行測試、操作和維護，直到它不再使用。當然，總會有一些有效的使用案例需要在架構中使用Lambda函式，但是在考慮是否可以使用原生服務整合之前，必須仔細評估。
事件資料豐富化
當事件流經系統時，會不可避免地需要轉換和豐富事件payload中的欄位。管理服務如Step Functions（透過輸入和輸出處理）和EventBridge（透過輸入轉換）支援使用JSONPath進行靜態資料操作。JSONPath操作可以被視為靜態，因為它們只能使用提供的輸入資料，不能生成新的值，如時間戳或計算值。對於動態資料豐富化，可以使用Step Functions的內建函式或在事件處理管道中實作自定義業務邏輯的Lambda函式。
事件溝通和路由
使用Lambda函式傳輸資料通常是沒有必要的。在絕大多數情況下，應該依靠管理服務，如Amazon EventBridge、SNS、Kinesis或SQS，來在生產者和消費者之間傳輸訊息並觸發伺服器無法實作應用中的活動。正如Ajay Nair，AWS Lambda的總經理所說：「使用Lambda函式進行轉換，而不是傳輸。」
事件批次處理
許多管理服務支援某種形式的批次處理或緩衝，包括Amazon Kinesis和SQS。通常應該優先使用管理服務而不是實作自己的批次機制。
HTTP請求
當向第三方API傳送網路請求時，可以使用Step Functions的HTTP任務或EventBridge API目的地（如第5章所述），如果不需要處理回應。
集中式計算
當需要協調大規模平行資料處理時，可以使用Step Functions對映（最多40個平行執行）或分散式對映（最多10,000個平行執行）來平行呼叫單個Lambda函式，而不是在函式本身中管理對映。
圖表翻譯：
flowchart TD
A[事件資料] --> B[靜態資料操作]
B --> C[動態資料豐富化]
C --> D[事件溝通和路由]
D --> E[事件批次處理]
E --> F[HTTP請求]
F --> G[集中式計算]
內容解密：
上述流程圖描述了伺服器無法實作應用中資料處理和傳輸的過程。首先，事件資料經過靜態資料操作，然後進行動態資料豐富化。接著，事件被傳輸到目標位置，可能涉及批次處理和HTTP請求。最後，集中式計算被用於協調大規模平行資料處理。
生產只是個名稱
軟體工程中環境的概念已經存在很久了。軟體被佈署到各種預生產環境中進行測試，然後被提升到生產環境。然而，這種狀態開始出現裂痕，因為團隊在雲端工作的極限被推向極致。事實上，AWS不知道你的環境。帳戶只是帳戶，沒有什麼特殊的地方，只是你選擇將其暴露給使用者。下圖展示了生產和非生產帳戶，它們都佈署了相同的應用程式。
圖表翻譯：
flowchart TD
A[生產帳戶] --> B[應用程式]
C[非生產帳戶] --> B
內容解密：
上述流程圖描述了生產和非生產帳戶之間的關係。兩個帳戶都佈署了相同的應用程式，表明環境只是發展工作流程中的建構，沒有實際意義。
從鍵盤到生產
軟體交付是關於為應用程式使用者提供穩定的更新。最佳化軟體交付是關於移除障礙：幫助工程師以可持續的節奏工作，感受到生產力，並對程式碼變更感到興奮，而不是被嚇倒。
根據2022年加速DevOps報告，由玄貓的DevOps研究和評估（DORA）團隊進行，高效能工程團隊從程式碼提交到程式碼成功執行在生產環境中需要一天到一週的時間。
軟體交付生命週期從工程師的鍵盤開始，以生產環境為結束。軟體的穩定性取決於從鍵盤到生產環境的路徑最佳化。
連續伺服器無法實作交付的理由
可能看起來違反直覺，在應用程式或功能建成之前就將其交付到生產和非生產帳戶中。然而，在它們不存在之前交付東西其實更簡單，因為沒有可能缺失的許可權，沒有測試失敗，也沒有資源或環境需要啟動。
將管道和交付留到開發週期結束，不僅使得佈署更難以工作，也意味著錯失了使軟體交付成為習慣的機會。為了最大限度地發揮伺服器無法實作的優點，應該連續交付應用程式，而不是在大功能工作結束時交付。
圖表翻譯：
flowchart TD
A[鍵盤] --> B[程式碼提交]
B --> C[自動化管道]
C --> D[生產環境]
內容解密：
上述流程圖描述了軟體交付生命週期。從工程師的鍵盤開始，程式碼被提交到自動化管道中，然後佈署到生產環境中。這個過程需要被最佳化，以確保軟體的穩定性和可靠性。
隨著雲端原生應用和無伺服器架構的普及，基礎設施即程式碼(IaC)以及受管理服務的使用，正推動著軟體交付模式的革新。深入剖析伺服器無法管理的基礎設施概念，我們可以發現，它並非單純地將伺服器視為「牛」，更在於最大程度地利用雲端供應商提供的託管服務，從而減少開發團隊的維運負擔並加速交付流程。
技術限制深析顯示，雖然Lambda函式提供了強大的計算能力，但過度使用反而可能增加複雜度和成本。無函式整合模式的興起，提倡優先使用各種受管理服務，例如EventBridge、Step Functions、Kinesis等，來完成事件處理、資料轉換、路由等任務，僅在必要時才使用Lambda函式，有效降低了開發和維護成本，同時提升了系統的可靠性和可擴充套件性。此外，將生產環境與非生產環境視為同質化佈署目標，打破了傳統的環境區隔，簡化了佈署流程並促進了持續交付。
展望未來3-5年，預計無函式整合模式將進一步發展，更多受管理服務將湧現，並提供更豐富的功能和更精細的整合方案。同時，IaC工具也將持續演進，提供更簡潔、更自動化的基礎設施管理能力。隨著技術生態的日趨完善，我們預見應用開發的門檻將大幅降低，開發者將更專注於業務邏輯的實作，而非底層基礎設施的管理。玄貓認為，積極擁抱無伺服器架構和受管理服務，並將持續交付融入開發流程，將是企業在雲端時代保持競爭力的關鍵。
