《無服務器架構成云計算未來趨勢，將DevOps帶入新層次》要點：
本文介紹了無服務器架構成云計算未來趨勢，將DevOps帶入新層次，希望對您有用。如果有疑問，可以聯系我們。

作者： 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 平臺上的無服務器技術開發大型項目,并擁有使用無服務器堆棧構建企業級分布式系統的第一手經驗.

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4104.html