作者： Rafal Gancarz

譯者：周元昊

本文要點

• 許多組織仍在努力接納 DevOps。
• 無伺服器架構並不只是簡單接納了 DevOps 文化，DevOps 已經成為該架構基因中的一部分。
• 無伺服器架構首要考慮的就是專案的可維護性，並將其融入到開發流程中。
• 將來許多 IT 專家會被具備廣泛技能的雲工程師所取代。
• 無伺服器架構會改變 IT 組織的內部文化，還會影響公司對雲端計算的使用方式。

無伺服器架構近在眼前

無伺服器計算正改變著軟體系統構建和運營的方式。儘管它是 IT 行業中一個相對較新的領域，但它可能會大大改變軟體行業業務價值的交付方式。它可以使用可用和可擴充套件的雲端負載來以較低的成本執行專案，這對許多產品型別和業務用例來說是一種理想的方式。

但無伺服器架構不僅僅只改變了軟體交付的方式，它還會改變軟體開發組織本身，相信這點對 IT 行業產生的影響將更加深遠。在本文中，我們將探討無伺服器架構如何改變那些用其釋出軟體的組織的文化，以及它是如何影響整個行業的未來的。

DevOps 目前的狀態

在過去幾年沒有太脫離業界環境的人，一定聽說過 DevOps。DevOps 運動將敏捷軟體開發融入並擴充套件到 IT 運營領域，旨在通過促進開發和運營團隊之間的強力協作並採用新穎的運營實踐來提供更高的業務敏捷性，尤其是在基礎設施配置、改進發布管理和運營工具方面。

事實上，DevOps 正在成為 IT 行業的新標準，並且已經被業界廣泛採納，常見於雲端計算和容器技術。同時，許多組織正盡力去理解 DevOps 的全貌，這主要受限於他們專業知識上的缺乏和各種組織結構上的挑戰。儘管面對這些挑戰，DevOps 正在成為一個主流運動，它正改變著 IT 組織釋出軟體的方式，這就像敏捷運動在過去十多年中所產生的影響。

但是，無伺服器架構是如何適應 DevOps 文化的？它將如何影響常規的 DevOps 實踐呢？

為什麼要選擇無伺服器架構？

為了瞭解無伺服器架構是怎樣影響那些使用它的組織的，讓我們首先來看看用它進行構建和執行軟體系統所具備的關鍵特性。

功能即服務（FaaS）提供了一個託管的執行時，用於執行任何已經上傳到服務上的程式碼。這可能看起來就像將可執行的專案部署到計算機例項或伺服器上，並在作業系統上執行它，但實際上這並不相同。FaaS 在保證功能在滿足當前需求規模下可用的同時，只以執行次數和執行時間收取費用。同時它會抽象出實際的執行時（如 Java 虛擬機器或 NodeJS）和作業系統本身的配置。在其背後，執行時程序、作業系統和計算例項還是在執行著的（不要被“無伺服器”這個名字矇騙了），但開發人員不再需要擔心這些因素了。

這正是無伺服器架構的優點，整個計算堆疊，包括執行功能程式碼的作業系統程序，完全由雲提供商管理。與傳統的基礎架構即服務（IaaS）模型相比，這種方式大大簡化了運算基礎架構的管理，並結合了按使用進行收費的計費模式，提供了非常靈活且經濟的運算選型。

快速開發

除了 FaaS 計算（如 AWS Lambda、Azure Functions 以及 Google Functions）之外，公共雲提供商還提供了一系列其他服務用於組合並建立無伺服器架構。從可伸縮的持久化儲存和訊息中介軟體，到 API 閘道器和內容分發網路，如今想要構建一個完整的系統完全不需要直接擺弄伺服器。

每個雲提供商的服務都可以通過其提供的軟體開發工具包（SDK）進行全方位的配置，可以用其快速地釋出產品來提供業務價值，前提是你要熟悉可用的服務及其配置選項。每個功能往往只負責處理簡單的事件或請求，因此通常它們不需要大量程式碼，小而集中的業務邏輯就足夠了。例如，一個功能可能只負責根據資料庫表中的觸發器，將變化資訊推送到使用者的電子郵件或相應的訊息佇列上，讓其他子系統可以使用這個通知來更新外部系統。

然後，許多這樣的功能用於實現業務邏輯及連線服務，從而提供了持久化、訊息、整合、內容分發、機器學習等基本功能。這些服務解決了許多複雜的專案問題，並可以用其來建立複雜的解決方案而不會碰到太多困難，進而可以快速進行原型設計並開發。

從一開始就考慮維護性

使用了無伺服器架構，就不可能在不考慮程式碼執行方式以及其他所需資源的情況下開始編寫程式碼，至少這樣做毫無意義。畢竟，為了瞭解程式碼如何與 API 閘道器、資料儲存或訊息中介軟體互動，首先必須部署程式碼，還要配置所有相關資源。雖然，可以使用模擬，而不通過真實的部署來執行程式碼，但這隻提供了有限程度的驗證，況且，這樣不會執行該功能所需的整個基礎架構堆疊。

無伺服器架構需要配置好雲資源這點可以說有利也有弊。那些習慣於使用自己機器，在本地開發模式下執行應用程式和系統的使用者，很可能會因為較長的反饋週期而損失部分生產力。基礎設施配置和程式碼部署確實需要更多的時間，但並不會像 IaaS 一樣多，後者還要算上按需啟動計算例項的時間。

從一開始就強制關注基礎設施堆疊的主要好處是，能早在編寫程式碼的時候，就考慮基礎架構設定和配置機制。這與現在仍常見的傳統方法不同，常常開發人員編寫程式碼，並藉助於持續整合工具進行打包，然後將其轉交給運營團隊進行部署，在這個過程中會假設不用考慮網路基礎設施的問題。

DevOps 運動促進了開發和運營團隊之間的合作，而在無伺服器架構中，他們就根本不可能被分開。

在無伺服器架構中，即使部署一個簡單的功能，也需要對一些運營和財務方面的關鍵問題作出決定。兩個最基本的配置選項就是可用記憶體和超時時間（即功能呼叫的預估時間）。這兩個設定都會影響呼叫所需的花費，因為它是按照記憶體消耗和執行時間來收費的。此外，分配的記憶體通常與功能執行的計算例項相關聯，更多的記憶體就意味著更多的處理能力。

由於需要這麼多次對功能的配置調優，根據可用的預算及期望和觀察到的效能特性對設定進行快速地調整就極為重要了。這些特性可以通過雲提供商收集並公開的指標進行確定，AWS CloudWatch 就是一個監控服務的例子。實際上，在構建無伺服器架構時擁有豐富的 FaaS 和其他服務的指標對於是否可以運營這個架構至關重要。由於在配置資源後立即可以得到這些指標，所以在開發階段就可以，也應該考慮架構的許多運營問題，如效能優化、容量規劃、監控和記錄。

安全性是軟體交付方面另一個很好的例子，通常它是被放在專案後期來解決的，或被委派給專門的安全團隊來處理，在部署到生產環境之前由他們對所有軟體元件進行評估和簽發。在無伺服器架構中，在常規開發活動部署的一開始，就必須考慮安全性。至少每個功能必須有與之相關聯的安全策略。由於一個功能可以被同賬戶下的任何其他資源所訪問到，所以花費一些時間來確定並配置正確的基於任務的功能安全策略很有必要。理想情況下，按照最小許可權的原則，一個功能應該被賦予它所需的最小許可權集。例如，需要查詢資料庫表的功能只能具有查詢相關表的許可權。

顯然，無伺服器架構應該使可維護性（包括安全性）成為正常開發週期的一部分，而不是將這些要素推遲到運營團隊參與後再進行，不然就會失去解決問題的最佳時機。

當談到無伺服器架構時，DevOps 的思想並不是用來被逐步接受的（通常這樣會代來巨大的痛苦），而是需要刻在其底層的基因上。

按使用收費

與 IaaS 計算模型相比，無伺服器架構帶來了另一個革命性的變化，即對單個功能呼叫進行收費的定價模型，而不必為保持伺服器執行進行付費。

使用公共雲的組織更習慣於將雲基礎設施成本看作運營支出（OPEX）而不是資本支出（CAPEX），但是在 IaaS 架構中，他們最終往往會進行大量前期投資以降低總成本，例如預留計算例項或購買其他雲服務的預留容量。而在無伺服器架構中，這就不必要也不經濟了，因為只對功能呼叫進行支付比保持伺服器持續執行會便宜許多。

由於用於構建無伺服器架構的大部分服務都是按使用進行計費的，這樣就可以執行多個環境以支援軟體交付涉及的開發、測試和操作活動。畢竟，如果不進行呼叫，就不會產生很多花費，甚至根本不需要支出。無伺服器架構在成本上的影響正在消除 DevOps 在許多公司實踐過程中的諸多障礙。

能夠擁有儘可能多的環境來滿足各種團隊或業務利益相關者的需求，會帶來一些新的巨大的可能性。例如，每個開發人員可以在雲上擁有個人的開發環境，或者正在開發的每個功能都可以部署到專用環境中，從而可以獨立於其他任何任務進行演示。這樣的獨立環境甚至可以在單獨的提供者帳戶上託管，以提供終極的隔離。

持續部署將成為新常態

持續交付是使 DevOps 可行的關鍵功能之一，但對許多公司來說，尤其是在企業領域，這點仍然相當難以實現。雖然持續交付提供了許多好處，並實現了更高的業務敏捷性，但它沒能瞭解到組織的全部潛力。

無伺服器架構可以用來實現業務靈活性的最高境界，即持續部署。持續部署讓任何合併到主幹中的程式碼更改都自動升級到包括生產在內的所有環境。為了讓這種方式在不影響使用者的情況下工作，持續部署的系統顯然需要從不同的角度進行嚴格的質量檢查。

鑑於諸如基礎架構配置和安全性等運營問題可以也應該在功能程式碼的開發階段解決，基礎設施堆疊就可以從一開始就配置好，或根據原始碼倉庫中包含的程式碼和配置進行更新。這些堆疊可以由提供商提供的原生工具（如 AWS 的 Cloud Formation），或其他通用工具（如 Hashicorp Terraform）進行管理。

通過全自動化的基礎設施堆疊的配置和程式碼部署，就可以對任何環境進行應用或取消（回滾）變更，當然這其中也包括生產環境這一環節。為了保證萬無一失，在部署或整個流程結束後需要自動在各個相關環境執行那些確保系統質量的測試案例，包括功能性和非功能性的測試。

每個人都是雲工程師

無伺服器架構模糊了軟體交付過程中常涉及的各類技術角色之間的界限。傳統的架構師、開發人員、測試人員、資料庫管理員、運營和安全工程師將共同合作來發布系統並維護生產環境，在無伺服器架構的世界中，這些角色都會被合併為雲工程師。

正如許多傳統開發過程已被移除或被大大簡化一樣，如今已經不再需要在專案中引入諸多專家。相反，具有廣泛技能且熟悉雲提供商平臺的工程師就可以完成這些工作，甚至更多，同時也可以做得更快。許多開發和運營過程可以被合併到同一個週期內，並且可以完全消除昂貴的交接或從外部借用資源的成本。

但這並不意味著團隊中不再擁有專門從事特定領域的人員，畢竟每個人會自然而然地更偏重於軟體交付的某些方面，但理想情況下，團隊中的每個成員都應該能夠參與到釋出一個功能的所有流程中，包括在生產環境中進行運營。這是激勵所有工程師能在一開始就構建一個可維護的高質量軟體的最佳方法。

實際上，與那些談論著要拉近開發和運營距離的團隊不同，使用無伺服器的團隊天生就有著 DevOps 的文化，即軟體在開始構建階段就準備著執行在生產環境中。

適者生存

無伺服器架構可以用來實現終極的業務敏捷性。然而，這完全取決於組織理解無伺服器架構全貌的能力。雖然許多組織仍在努力建立某種形式的 DevOps 文化和實踐，無伺服器架構提供了一種全新的方式來建立快速業務價值交付和穩定運營的文化，同時最大限度地降低成本。

並沒有多少組織可以接受無伺服器架構這個新領域所帶來的挑戰，因為整個領域仍然非常年輕並且還不成熟，所以要接納它真的需要很大的勇氣，因此需要大量額外的工作來彌補目前初級階段所帶來的差距及挑戰。很多健全且願意採納無伺服器架構的組織，可能會發現自己還在試圖套用他們現有的流程和組織結構，並且失去他們已有的敏捷性，或更糟糕的是，還在建立和執行無伺服器架構上花費了大量的精力。

那些希望能夠充分利用無伺服器架構來獲得在市場中競爭優勢的公司，可能不僅需要調整他們提供軟體的方式，還需要改變其產品的建立和銷售方式。

結論

無伺服器架構不僅補充了 DevOps 的理念，更改進了當前 IT 組織實現更高業務敏捷性的觀念。它致力於快速交付商業價值並持續改進和學習，這極有可能會帶來文化上大範圍的改變，甚至對那些已採用了 DevOps 文化和實踐的組織也不例外。

使用無伺服器架構不僅可以使組織更快更省地提供新產品和功能。它還將改變整個流程中的內在文化。

檢視英文原文：Serverless Takes DevOps to the Next Level

作者介紹

Rafal Gancarz，OpenCredo 的首席顧問，OpenCredo 是一家位於倫敦的諮詢公司，專門幫助客戶構建並部署新興技術以實現客戶的業務價值。Rafal 是一位經驗豐富的架構和大規模分散式系統釋出方面的專家。他也是一位經驗豐富的敏捷實踐者和認證敏捷專家（Certified Scrum Master），他對改進專案交付抱有極大興趣。在過去的 18 個月中 Rafal 使用 AWS 平臺上的無伺服器技術開發大型專案，並擁有使用無伺服器堆疊構建企業級分散式系統的第一手經驗。

文章來自微信公眾號：細說雲端計算