無伺服器架構的採用日益普及，但要成功匯入，技術團隊需要有效地與商業利益相關者溝通。許多企業擔憂商業中斷和成本增加，因此，技術團隊必須使用淺顯易懂的語言解釋無伺服器架構的優勢，避免使用專業術語，並以商業角度闡述其價值，例如提升客戶服務能力、降低儲存成本和加快產品上市速度。參與團隊展示和產品演示會議，讓利益相關者瞭解無伺服器架構的實際應用和效益。分享業界成功案例，並邀請專家講解，能增強說服力。除了成本效益，還需強調無伺服器架構的便捷性、安全性以及應對市場快速變化的能力。最後，選擇合適的遷移策略，例如 Lift-and-Shift、All-at-once Service Rewrite 或 Phased Migration，並仔細評估技術限制，才能確保遷移過程順利進行。
企業為無伺服器架構做準備
說服產品團隊和商業利益相關者採用新技術的必要性是一項艱鉅的任務。儘管他們可能不直接影響技術選擇，但在許多企業中，他們負責最終的批准。令人驚訝的是，在這種情況下，利益相關者拒絕新技術的主要原因往往是對變革的恐懼，而這種恐懼主要集中在商業中斷和營運成本兩個方面。
商業中斷不僅僅意味著服務不可用或停機時間。利益相關者可能會因為技術變革而對服務品質惡化、客戶反彈、效能下降、商業洞察力減少、開發人員速度變化等風險而感到恐懼。此外，許多企業仍然執行在孤立的團隊結構中，商業利益相關者並不總是被告知即將到來的技術變革，往往只在事情出錯或透過同事和八卦時才得知，這對於任何組織來說都是不健康的。
無伺服器架構的採用為利益相關者增加了額外的神秘感，因為它並不總是被很好地理解。如果工程師們發現無伺服器架構的心態難以掌握，那麼對於其他人來說就更難了。因此，保持利益相關者瞭解情況並盡早與他們進行溝通至關重要。
使用共同語言，避免無伺服器架構特定術語
無伺服器架構是否有一種語言？至少在向利益相關者推銷無伺服器架構的早期階段，嘗試避免使用特定的服務名稱，如Lambda、DynamoDB和S3，或者可能不熟悉的短語，如管理服務、FaaS、SaaS等。你不應該期望每個人都知道這些是什麼。相反，使用通用術語，如雲、程式、函式、資料函式庫、表格和檔案，以及可理解的流程，如“當使用者輸入資料時呼叫一個函式”、“資料儲存在表格中”、“當客戶帳戶建立時傳送通知”等。
在工作於解決方案設計時，包含高階別上下文和流程圖，以基本符號使每個人都能夠理解問題域。將雲和無伺服器架構服務圖示和技術繪圖限定於工程師的詳細設計部分。
邀請利益相關者參加團隊展示
如果你的團隊定期進行衝刺評審或展示，以展示包括無伺服器架構實驗或概念驗證在內的工作，那麼這些是邀請商業利益相關者參加的理想機會。即使這些展示是技術密集的，它們仍然可以為觀察者提供無伺服器架構的實用性的線索。例如，“無伺服器架構在這種情況下效果很好”、“我們能夠快速開發這個功能”、“這個原型可以輕鬆地使用無伺服器架構服務進一步擴充套件”等短語，是能夠觸發好奇心和進一步對話的訊號。
如果由於團隊結構或文化原因，這在你的組織中不可行，則安排與相關利益相關者團隊的特殊產品演示會議是一種實際的方法。這種方法將每個人聚集在一起，並適合問題和答案格式，可以鼓勵非技術人員參與對話。
當工程團隊與利益相關者密切互動時，他們應該記住使用共同語言。他們也可以使用簡單的邏輯模型圖，如圖2-8所示，以確保每個人都能夠理解上下文，解釋方法，並強調商業上的好處。
圖表翻譯：
圖2-8是一個簡單的邏輯流程圖，展示了使用者、訂單應用程式和支付系統之間的互動作用。
將技術理由對映到商業收益
作為一名工程師，你可能會對商業利益相關者拒絕或忽略你提出的改善系統某些技術方面的提議感到沮喪。雖然你善於深入研究你的建議的技術細節，但你可能需要更好地將其與非技術同事可以理解的商業收益相關聯。以下是一些將技術改進轉換為可識別商業收益的例子：
-
技術理由： 無伺服器架構提供了許多優勢，允許你在實作中使用管理服務。Amazon Simple Queue Service（SQS）是一種高度可擴充套件且廣泛使用的訊息佇列服務。它是事件驅動架構中使用的一個核心服務，能夠處理數十萬條訊息。它允許下游服務（如Lambda函式）一次或批次處理訊息，使前端應用程式能夠接收大量請求。 利益相關者翻譯： 無伺服器架構佇列服務允許我們服務更多客戶。它可以輕鬆地處理客戶需求的波動，並始終提供快速回應。
-
技術理由： DynamoDB是一種高效能的NoSQL資料函式庫。其中一個功能是TTL（過期時間），允許你設定一個過期時間。透過使用DynamoDB，你可以確保一旦過期時間到達，專案就會自動從表中刪除。這使你能夠最佳化儲存需求，並確保舊專案被刪除或敏感資料在處理後盡快刪除，以符合法規要求。 利益相關者翻譯： 自動刪除資料後，保留所需時間長度後，即可降低儲存成本。
工程團隊與商業利益相關者的互動不是一次性的，而是一種持續的合作。在初步介紹無伺服器架構之後，邀請他們參與每次迭代的進展展示。目標應該是盡可能地提供新技術的可見性，並展示它如何加速商業發展。
突出無伺服器架構成本效益
正如第1章所示，按使用付費是無伺服器架構採用的基本驅動力，並且引起了很多興趣。強調可能透過無伺服器架構實作的雲端支出節約至關重要。為了使資訊更容易被接受，保持在高層次上而不陷入細節中是必要的。例如，如果你正在討論執行幾個Lambda函式來執行一些業務邏輯，請保持在每月呼叫次數和預期總成本的層次上，而不要分解為呼叫成本、計算成本等。
無伺服器架構的一個重要方面是減少管理基礎設施所花費的時間。這一獨特優勢應該在與利益相關者的對話中被提及，並以可理解的方式解釋。雖然使用無伺服器架構構建的應用程式仍需要營運活動，但無伺服器架構使工程師免於基礎設施和平臺上的繁重工作，從而節省了大量工程時間。
討論無伺服器架構的便捷性
雖然降低雲端成本是無伺服器架構的一個關鍵驅動力，但你也必須向商業利益相關者闡述其其他優點。為現代消費者世界設計的解決方案有很多需求。例如：
- 應用程式預計具有高度安全性，可以抵禦激烈的網路攻擊。
- 公司面臨壓力，需要遵守法規政策以保護個人可識別資訊（PII）和其他敏感資料。
- 客戶需求不斷波動；保持客戶參與度並更快地服務他們至關重要。
隨著技術的演進，它拉動了整個行業向前發展，每次迭代都更快。組織經常陷入這個漩渦中，反應時間很短。因此：
- 商業公司正在尋找執行工作負載最簡單的方式。
- 利益相關者正在尋找發布功能最快的方式。
- 工程師正在尋找處理資料最安全的方式。
- 客戶正在尋找購買產品最簡單的方式。
2020年的COVID-19大流行震撼了我們世界的每個角落。雖然許多企業經歷了艱難時期，但有些企業甚至在那些黑暗日子裡蓬勃發展，因為它們迅速適應了世界變化中的需求，每天幾乎都在進行課程糾正。對於其中許多企業來說，是無伺服器架構的便捷性和靈活性使其有所不同。根據BBC的一項調查，如圖2-9所示，在COVID-19封鎖期間，英國實際上出現了新公司註冊增加的情況。
圖表翻譯：
圖2-9顯示了COVID-19封鎖期間新公司註冊增加的情況。
遠端工作的工程師們利用雲端和無伺服器架構的能力，在客戶家中推出新產品和服務，並迅速將其交付給消費者。無伺服器架構使任何人都能夠從任何地方構建和營運全球級別的應用程式。除了其成本效益之外，你還必須向商業利益相關者展示使用無伺服器架構交付解決方案更快的便捷性。
談論無伺服器架構成功案例
找出行業中無伺服器架構採用的成功案例，並邀請那些組織的人員與利益相關者分享他們的經驗。這些資訊對於工程團隊和商業團隊都很有關係，但要確保內容平衡並適合兩個受眾。在建立清晰議程並提前與團隊分享之前，要確保這些合作是有效的。盡量聽取來自與你所在業務領域類別似的組織的人們分享無伺服器架構成功案例，這樣可以幫助利益相關者快速理解無伺服器架構的適用性。
以下是一些你可能想要在成功案例中涵蓋的要點：
- 與傳統技術相關的業務痛點或限制
- 遷移至無伺服器架構背後的動機
- 業務和技術團隊對無伺服器架構的認同
- 開發方法，包括團隊結構和溝通
- 遷移至無伺服器架構後獲得的好處
- 學到的教訓和需要注意的事項
你也可能想要找出並邀請無伺服器架構專家——獨立顧問、AWS解決方案建築師和無伺服器架構培訓提供商——分享他們的經驗。
企業為了實作無伺服器架構的轉型，需要考慮哪些因素？
企業在實作無伺服器架構的轉型過程中，需要考慮多個因素，包括組織文化、技術選型、團隊心態、雲端服務提供商的選擇等。首先，企業需要建立一個鼓勵創新、勇於嘗試和不怕失敗的組織文化，以便於實作無伺服器架構的轉型。其次，企業需要選擇合適的技術和雲端服務提供商，以滿足其業務需求。同時，企業也需要考慮團隊的心態和技術能力，確保團隊能夠順暢地適應新的技術和架構。
無伺服器架構的轉型需要哪些條件？
無伺服器架構的轉型需要以下幾個條件：
- 組織文化：企業需要建立一個鼓勵創新、勇於嘗試和不怕失敗的組織文化。
- 技術選型：企業需要選擇合適的技術和雲端服務提供商，以滿足其業務需求。
- 團隊心態：企業需要考慮團隊的心態和技術能力，確保團隊能夠順暢地適應新的技術和架構。
- 雲端服務提供商：企業需要選擇合適的雲端服務提供商，以滿足其業務需求。
如何避免雲端服務提供商的鎖定？
避免雲端服務提供商的鎖定需要以下幾個步驟：
- 選擇開放標準：選擇開放標準的技術和服務，以便於之間的切換。
- 使用開源軟體：使用開源軟體，以減少對特定雲端服務提供商的依賴。
- 設計可移植的架構：設計可移植的架構，以便於之間的切換。
- 評估雲端服務提供商：評估雲端服務提供商的服務和價格，以選擇最合適的提供商。
雲端服務提供商如何與企業合作？
雲端服務提供商可以與企業合作，提供以下幾個方面的支援：
- 技術支援：提供技術支援，以幫助企業解決技術問題。
- 業務支援：提供業務支援，以幫助企業提高業務效率。
- 戰略合作：與企業進行戰略合作，以幫助企業實作業務目標。
- 培訓和教育：提供培訓和教育，以幫助企業提高團隊的技術能力。
企業級別的無伺服器應用遷移策略
當企業考慮採用無伺服器架構時，往往會遇到許多策略性的問題。早在2010年，Gartner就提出了5Rs模型（Rehost、Refactor、Revise、Rebuild、Replace）作為遷移至雲端的框架。後來，Stephen Orban又提出了6Rs策略（Rehost、Replatform、Repurchase、Refactor、Retire、Retain）。雖然這些策略主要針對雲端遷移，但也適用於無伺服器架構的採用。
每次技術遷移都會面臨挑戰，尤其是企業級別的遷移。企業需要考慮多個因素，包括工程團隊的經驗和技能、業務利益相關者的理解和支援、對客戶的影響評估等。另外，企業還需要向執行團隊和董事會提出說服力的案例，並可能需要向股東保證投資的效益和價值。
對於24×7營運的企業，客戶影響通常是首要考慮的問題。在競爭激烈的商業世界中，任何小小的中斷都可能導致別人獲得顯著的收益。
中斷和停機
每次技術遷移都會引發兩個常見的問題：服務停機和中斷。停機是指應用程式或其部分對終端使用者不可用的情況，可以是計劃內或計劃外的。根據系統的架構和設計，停機期間的中斷可以是嚴重、輕微或不存在的。
與計劃停機不同，意外中斷需要問題調查和緩解。根據根本原因的性質，中斷可以是輕微或嚴重的。在雲端和現代架構模式下，消費者期望服務100%可用，即使幾毫秒的停機時間在競爭激烈的消費市場中也可能造成巨大的損失。因此，無伺服器遷移任務需要被仔細協調和執行。
說服業務和利益相關者接受無伺服器架構的優點只是過程的一部分，因為接下來你會面臨諸如以下問題：
- 我們如何處理組織內廣泛分佈的技術？
- 如何決定哪些應用程式適合無伺服器堆積疊？
- 我們可以多快將所有內容遷移到無伺服器？
軟體業界標準答案是：視情況而定！雖然適合的策略確實取決於你的領域、現有應用程式的狀態、複雜性等，但你必須能夠提供正確的指導。
遷移方法
以下是三種最常見的無伺服器遷移方法：
- Lift-and-Shift：這種遷移策略也稱為重新託管，即將應用程式從當前平臺提升並託管在雲端。雖然Lift-and-Shift曾經是最常見的雲遷移策略，但其受歡迎程度正在逐漸下降。正如本文前面所述，無伺服器具有獨特的特性，要真正受益於無伺服器，你必須構建利用受管理服務優勢並採用現代開發實踐的應用程式。Lift-and-Shift方法並不做到這一點，因此它被認為是無伺服器中最不受青睞的方法。
- All-at-once Service Rewrite：這種方法涉及一次性重寫整個服務，以便充分利用無伺服器架構的優點。
- Phased Migration：這種方法涉及分階段遷移應用程式，不同元件可以在不同時間遷移，以減少風險並確保平滑過渡。
適合性
使用Lift-and-Shift方法遷移到無伺服器架構的應用程式主要來自兩個領域：
- 自管理的本地設定
- 雲端託管容器堆積疊
以下是一些示例，展示了哪些應用程式可以使用Lift-and-Shift方法輕鬆遷移到無伺服器架構：
- 使用最新技術和現代開發實踐開發的應用程式
- 以玄貓支援的語言編寫且具有模組化設計的應用程式
- 自包含的微服務，不帶有深層依賴關係且佈署檔案大小在合理範圍內
- 可以封裝為容器映像並作為Lambda函式執行的容器化應用程式
- 資源需求在Lambda限制範圍內的批處理任務
遷移考慮因素
在繼續進行Lift-and-Shift遷移之前，需要考慮一些重要特性：
- 超時限制：作為一種FaaS，Lambda具有超時限制（撰寫時為15分鐘）。如果重新建立REST API在Amazon API Gateway上，它有29秒的超時限制。
- 記憶體限制：Lambda函式可以分配最多10 GB RAM（撰寫時）。
內容解密：
無伺服器遷移是一個複雜且多面的過程，需要仔細考慮各種因素，包括技術、業務和客戶影響。瞭解不同的遷移方法，例如Lift-and-Shift、All-at-once Service Rewrite和Phased Migration，並根據具體情況選擇最適合的方法至關重要。此外，考慮如超時限制和記憶體限制等特性對於確保無伺服器應用程式順暢執行也是非常重要的。
圖表翻譯：
graph LR
A[Lift-and-Shift] -->|重新託管|> B[雲端]
B --> C[無伺服器架構]
C --> D[All-at-once Service Rewrite]
D --> E[Phased Migration]
E --> F[最終目標: 無伺服器應用]
此圖表展示了從傳統應用程式到無伺服器架構的遷移過程，其中包括Lift-and-Shift、All-at-once Service Rewrite和Phased Migration三種方法，每種方法都有其優缺點和適用場景。
從商業價值視角來看，企業匯入無伺服器架構的關鍵在於有效溝通其優勢，並妥善管理轉型過程。深入分析本文提出的策略，可以發現，技術團隊若能以淺顯易懂的語言闡述無伺服器架構的商業效益，例如降低營運成本、提升客戶體驗和加快產品上市速度，便能有效降低利益相關者的疑慮，並獲得更多支援。此外，技術限制的深析也至關重要，例如Lambda 的超時與記憶體限制，都需在遷移規劃階段納入考量，並選擇合適的遷移策略，才能避免不必要的風險。展望未來，隨著無伺服器技術的持續發展和成熟，預期更多企業將採用混合雲策略，整合無伺服器架構與現有系統，以最大化商業價值。玄貓認為，企業應及早規劃無伺服器架構的匯入策略，並注重團隊培訓和技術能力的提升，才能在未來的競爭中取得先機。
