雲計算將來趨勢：無服務器架構

本文要點

許多組織仍在努力接納 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 文化和實踐的組織也不例外。

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

本文地址：http://www.linuxprobe.com/cloud-computing-new-trend.html