隨著雲端技術的發展，伺服器無法化架構已成為企業數位轉型的重要趨勢。然而，企業在匯入伺服器無法化時，除了考量技術層面的調整，也需關注團隊的技能提升與組織文化的變革。在技術方面，需評估現有應用程式與伺服器無法化架構的相容性，例如資料負載、程式碼套件大小、併發限制等。此外，將單體式應用程式重構為微服務架構，更有利於伺服器無法化的實施。同時，評估工作負載的特性，選擇合適的遷移策略，並充分了解遷移風險，才能確保轉型過程的順暢。除了技術準備，人才培養也是關鍵。避免僅仰賴外部顧問，而忽略內部團隊的技能提升，才能建立永續的伺服器無法化知識基礎，並提升團隊的自主性和 ownership。
企業級伺服器無法化的準備
當企業考慮將現有的應用程式遷移到伺服器無法化（Serverless）架構時，需要考慮多個因素，以確保順暢過渡。以下是企業級伺服器無法化的準備工作。
資料負載大小限制
雲端服務的資料負載大小限制各不相同，不僅僅是API請求和回應的負載，也包括事件和訊息推播到佇列的大小限制。
程式碼套件和容器映像大小限制
目前，最大佈署套件大小為50 MB的.zip檔案和250 MB的未壓縮檔案，容器映像佈署套件大小限制為10 GB。
併發限制
Lambda有預設的併發執行限制（每個帳戶），您可以要求AWS提高此限制，前提是您有合理的使用案例。瞭解受管理服務的限制在遷移之前是非常重要的，以避免節流和失敗。
單體式應用程式和大泥球
將單體式應用程式直接遷移到伺服器無法化架構可能不是理想的選擇，因為它可能會變成一個伺服器無法化的大泥球。這種情況下，應該考慮將應用程式重構為事件驅動和鬆散耦合的微服務，以支援未來的擴充套件和商業增長。
一次性服務重寫
使用伺服器無法化原生方法開發的應用程式可以充分利用受管理服務的潛力。例如，如果您的傳統應用程式將二進位制大物件（BLOB）儲存在關聯式資料函式庫中，您可以在遷移到伺服器無法化時使用Amazon S3作為更好的儲存選擇。
工作負載適合度
一次性服務重寫是一種有用的遷移策略，幾乎適用於任何工作負載，除了少數特殊情況。伺服器無法化技術適合大多數現代應用程式，以下是一些使用案例：
- 高容量事件接收和處理
- 排程和啟用大量任務
- 高度可擴充套件的後端應用程式
- 大資料和資料湖
遷移風險
在選擇一次性遷移之前，需要了解以下風險因素：
- 對伺服器無法化技術的誤解
- 沒有充分理解伺服器無法化技術的結構和原理
圖表翻譯：
graph LR
A[企業級伺服器無法化] --> B[資料負載大小限制]
B --> C[程式碼套件和容器映像大小限制]
C --> D[併發限制]
D --> E[單體式應用程式和大泥球]
E --> F[一次性服務重寫]
F --> G[工作負載適合度]
G --> H[遷移風險]
內容解密：
以上內容介紹了企業級伺服器無法化的準備工作，包括資料負載大小限制、程式碼套件和容器映像大小限制、併發限制、單體式應用程式和大泥球、一次性服務重寫、工作負載適合度和遷移風險。瞭解這些因素可以幫助企業順暢地遷移到伺服器無法化架構。
企業級Serverless採用準備
在深入探討Serverless技術之前，瞭解其特性和評估工作負載的適合度是至關重要的。沒有充分的規劃和準備，就可能導致Serverless採用的失敗。
不充分的規劃
試圖在沒有充分理解Serverless技術和其適合度的情況下快速開始Serverless採用，是建造在沙上的行為。這樣做會導致無法擴充套件解決方案以新增服務和功能。因此，花時間打下成功Serverless採用的基礎是非常重要的，需要考慮第一原則和其他因素。
時間和成本
使用Serverless技術重構和重寫傳統應用程式將會帶來挑戰，並可能耗費大量時間和成本。當面臨超出團隊能力的局面時，應盡早尋求AWS和Serverless專家的幫助，以避免浪費昂貴的工程時間。
遺留系統的影響
在轉向Serverless開發時，過去的經驗會自然地被帶入，但重要的是不要重蹈覆轍或陷入相同的陷阱。重寫遺留系統需要新鮮的思維和心態轉變。讓一切都變新，包括你的思維方式。
分階段遷移
對於具有多個子域和應用程式、使用不同技術且跨多個團隊的組織，全面的服務重寫是不實際的。分階段遷移可以提供更好的控制和進度可視性，每個階段的持續時間取決於域複雜度、關鍵性、工程專業知識的可用性和商業優先順序。
如果您的企業完全是Serverless新手，請從非關鍵業務領域開始您的第一階段。例如，假設總公司執行多個每晚資料整合作業以生成可下載的每日報告供內部團隊使用。這是一個非導向客戶且非業務關鍵領域，相對較低的影響力，是啟動Serverless採用的理想使用案例。一旦您成功完成第一個Serverless遷移，您就可以展示您的成功，以建立進一步的動力，推動後續的使用案例。
組織適合度
與全面的服務重寫一樣，分階段遷移幾乎適用於任何工作負載。然而，某些組織原則對於這種方法的成功至關重要：
- 明確的願景：以階段遷移應用程式到Serverless，就像在棋盤上進行戰略移動。它需要一個具有清晰目的高層次商業願景。商業利益相關者、工程負責人和架構師應該合作，規劃每個階段及其之間的相互依賴關係。
- 長期成長計劃：對於以成功為導向的組織，Serverless採用不僅是一種成本文約措施，也是一種成長策略。遷移適合的應用程式到Serverless，就像在雲端蛋糕上加上一層糖霜！成功啟動Serverless的企業會看到開發速度和產品發布週期的增加。Serverless作為未來成長策略的催化劑。
- 持續改進：現代開發團隊遵循嚴格的增量和迭代產品交付週期。如第1章所述，作為一種技術，Serverless非常適合此類別開發實踐。與傳統的瀑布模型及其維護階段不同，現代敏捷團隊從事持續重構和改進。這是Serverless所需的特質，因為該技術正在迅速演變。具有正確態度的團隊可以從分階段遷移中受益，不斷改進，並從一個階段餵養到下一個階段。（在第11章中，您將學習如何跟上Serverless演化的步伐。）
遷移考量
除了全面的服務重寫策略所描述的風險因素外，以下是分階段遷移需要注意的事項：
內容解密：
以上內容強調了企業級Serverless採用的重要性，包括充分的規劃、時間和成本考量、遺留系統的影響、分階段遷移以及組織適合度等因素。這些因素對於確保Serverless採用的成功至關重要。
圖表翻譯：
此圖示展示了企業級Serverless採用的流程，包括評估工作負載、規劃遷移路線、執行分階段遷移以及持續改進等步驟。這個流程圖有助於企業瞭解如何成功採用Serverless技術。
flowchart TD
A[評估工作負載] --> B[規劃遷移路線]
B --> C[執行分階段遷移]
C --> D[持續改進]
圖表翻譯：
此圖表展示了企業級Serverless採用的關鍵因素，包括明確的願景、長期成長計劃以及持續改進等。這些因素對於確保Serverless採用的成功至關重要。
flowchart TD
A[明確的願景] --> B[長期成長計劃]
B --> C[持續改進]
企業在無伺服器環境下的成熟度
當企業從傳統的內部佈署環境遷移到無伺服器環境時，會不可避免地面臨混合的雲端和傳統技術堆積疊。管理這些堆積疊之間的相依性可能會引發技術問題。使用API進行不同堆積疊中的應用程式之間的通訊可以降低複雜性，但並非所有情況下都能夠預期到這些API的可用性。
因意外複雜性而受阻
軟體工程中常見的意外技術挑戰，也適用於無伺服器遷移。一個階段的延遲可能會導致其他相依階段的延遲，從而引起團隊之間的緊張，並可能導致責怪技術本身。
服務中斷和不滿客戶
使用分階段遷移策略時，由於不同堆積疊上的服務不相容（API協定、資料格式、程式語言、同步與非同步操作等），可能會出現不愉快的情況。此外，兩邊的服務限制也可能不同，找到服務之間的共同點以減少對客戶的影響至關重要。
比較遷移策略
根據完成時間和風險水平，比較三種策略，如圖2-12和圖2-13所示。 圖2-12. 根據完成時間的無伺服器遷移策略 圖2-13. 根據風險水平和偏好的無伺服器遷移策略
培養無伺服器人才
著名作者羅賓·夏瑪（Robin Sharma）曾說過，“公司成長最快的方式是讓員工成長。”員工是每個組織中最有價值的資產，照顧和培養這些資產至關重要。除了技術進步外，工程師的成長還取決於他們的軟技能、幸福感、自尊心、態度和歸屬感等。然而，這些改善並不是一夜之間就能實作的，而是需要時間和足夠的支援。
成長與建造
為什麼我們要談論“成長”無伺服器人才？成長是一個有機的過程，而建造是一個組裝和拼湊元件的問題。要建造一些東西，你需要來源元件和原料，僱用勞動力，並制定藍圖或等效物。企業通常會使用快速建造原則來快速製造產品，進行團隊搭建，並將其投入工作。
快速建造公式的負面影響
快速開發的口號在軟體行業中很常見。這種方法包括以下階段： 聘用顧問 團隊組建 產品開發
這種方法可能會產生預期的結果，但它不一定能夠提升工程師的技能或促進團隊凝聚力和歸屬感。由玄貓驅動的長官者忽視了從顧問到內部工程師的知識分配，這是一個團隊反覆犯的錯誤。內部無伺服器知識基礎不足可能對組織產生長期的毀滅性影響，導致缺乏對應用程式（或服務和功能）的承諾和所有權。
圖表翻譯：
graph LR
A[企業成長] --> B[員工成長]
B --> C[團隊成長]
C --> D[組織成長]
D --> E[無伺服器成長]
圖表展示了企業成長、員工成長、團隊成長、組織成長和無伺服器成長之間的關係。
內容解密：
上述內容強調了培養無伺服器人才和團隊在企業中的重要性。透過有機成長和培養員工的軟技能和技術技能，可以實作企業的長期成長和成功。快速建造公式可能會產生短期結果，但它不一定能夠提升工程師的技能或促進團隊凝聚力和歸屬感。因此，企業應該注重培養無伺服器人才和團隊，以實作長期的成功。
無伺服器技術的快速發展對企業IT架構變革提出了新的挑戰和機遇。深入分析企業級無伺服器落地過程中的幾個關鍵環節，可以發現，資料負載限制、程式碼套件大小、併發限制等技術細節固然重要，但更關鍵的是組織和團隊的準備度。技術架構的遷移只是第一步，更重要的是思維模式的轉變，從傳統的單體式應用架構轉向事件驅動、鬆散耦合的微服務架構。此外，無伺服器人才的培養也不容忽視，快速建造團隊雖然能短期見效，但忽視內部知識積累和團隊有機成長將帶來長遠的負面影響。玄貓認為，企業應重視長期策略，將無伺服器技術視為持續成長的催化劑，而非單純的成本文約手段。在技術選型上，務必根據自身業務特性和團隊能力，選擇合適的遷移策略，並做好風險評估和管理。未來幾年，隨著無伺服器生態的持續完善，相關工具和最佳實踐將更加成熟，應用門檻也將進一步降低，這將進一步推動無伺服器技術的普及和應用。
