未來屬于 Serverless

引言

用戶已經(jīng)云這個(gè)概念很多年了，但是最近，用戶可能已經(jīng)聽說了更多關(guān)于 Kubernetes 和 Docker 的信息，就是說，Serverless 正在成為一種極具意義的云架構(gòu)范式。

Serverless 代表了我們的云中構(gòu)建應(yīng)用程序的方式發(fā)生這巨大的改變，這種影響不僅體現(xiàn)在工程層面，也體現(xiàn)在業(yè)務(wù)層，Serverless 計(jì)算極大地改變了用戶管理云基礎(chǔ)架構(gòu)和構(gòu)建系統(tǒng)的方式。用戶無需一次構(gòu)建整個(gè)系統(tǒng)或微服務(wù)，可以一次只部署一些功能。用戶只需要關(guān)注代碼，并且知曉功能將隨著應(yīng)用一起擴(kuò)展，而無需管理基礎(chǔ)架構(gòu)。

我們首先將對(duì) Serverless 下一個(gè)定義，看一些使用場(chǎng)景，確定 Serverless 是否適合用戶的技術(shù)棧，以及如何大規(guī)模管理 Serverless，最后看一下此更改將如何影響未來的業(yè)務(wù)。

什么是 Serverless

那么到底什么是 Serverless？首先，它還是涉及到服務(wù)器的，Serverless 的本質(zhì)是盡管服務(wù)器依然存在，但是它們與用戶的應(yīng)用程序體系結(jié)構(gòu)無關(guān)，因此工程團(tuán)隊(duì)只需要關(guān)注應(yīng)用程序代碼。

Serverless 具體的定義還存在一些爭(zhēng)議，本文中，我們集中討論一些共同的特征。Serverless 是一種云架構(gòu)，通常遵循以下特征：

不需要管理服務(wù)器、虛擬機(jī)和容器
對(duì)托管服務(wù)的依賴：如云提供商或第三方服務(wù)
事件驅(qū)動(dòng)的架構(gòu)，應(yīng)用代碼僅在觸發(fā)時(shí)運(yùn)行
云提供商的計(jì)費(fèi)模式，只需為使用的應(yīng)用程序付費(fèi)

Serverless 計(jì)算改變了共享責(zé)任模型（shared responsibility model），現(xiàn)在 PaaS 服務(wù)提供商為用戶管理了操作系統(tǒng)和運(yùn)行時(shí)，這樣工程師可以專注于代碼。

這些是 Serverless 的一些共同特征，可以幫助我們更好地理解講解的內(nèi)容，現(xiàn)在讓我們深入往下。

FaaS

當(dāng)人們談?wù)?Serverless 時(shí)，通常會(huì)想到功能即服務(wù)，即 FaaS，這是因?yàn)?FaaS 是 Serverless 的核心。AWS 推廣 Lambda，Google 推廣 Cloud Functions，Microsoft 推廣 Azure Functions，這是大多數(shù)云供應(yīng)商 Serverless 產(chǎn)品中最引人注目的部分。

Serverless 方法并不是完整的應(yīng)用程序。將一個(gè)應(yīng)用程序，比如后端 REST API，將它們分解成細(xì)粒度的各部分，REST API 上的每個(gè)端點(diǎn)都變成獨(dú)立的功能，這些功能僅執(zhí)行特定的任務(wù)，并且僅在收到 Http 請(qǐng)求時(shí)才觸發(fā)這些功能。

用戶可以通過組裝各種方法，而不是通過單個(gè)應(yīng)用，在數(shù)據(jù)庫(kù)中增刪改查記錄，這樣用戶就能對(duì)方法彼此獨(dú)立地進(jìn)行更新和部署。通過解耦這些功能，可以降低因?yàn)樵谀硞€(gè)功能中引入一個(gè) Bug，而導(dǎo)致另一個(gè)功能無法執(zhí)行的風(fēng)險(xiǎn)。

在 FaaS 平臺(tái)上運(yùn)行的功能非常短暫，這意味著它們最多運(yùn)行幾分鐘，有充足的的時(shí)間保證它們能夠完成有限的任務(wù)。臨時(shí)也意味著它們?cè)趦纱握{(diào)用之間不會(huì)保持應(yīng)用程序狀態(tài)，相反，應(yīng)使用外部數(shù)據(jù)存儲(chǔ)來管理應(yīng)用程序狀態(tài)。

公共和私有的托管 FaaS 平臺(tái)種類繁多，在共有云服務(wù)中，AWS、Google 和 Microsoft 提供 FaaS 服務(wù)和其他托管云服務(wù)以構(gòu)建 Serverless 應(yīng)用程序。

私有的 FaaS 平臺(tái)包括 Knative 和 Apache OpenWhish，Knative 強(qiáng)依賴 Kubernetes，OpenWhish 可以在包括 Kubernetes、Mesos 和 Docker Compose 在內(nèi)的云管理平臺(tái)上運(yùn)行。這些私有的 FaaS 平臺(tái)使用戶可以在現(xiàn)有的云管理基礎(chǔ)架構(gòu)上利用 Serverless 架構(gòu)。

Serverless1.png

其他類型的 Serverless

FaaS 應(yīng)用程序并不是唯一可視為 Serverless 的云應(yīng)用程序，還有許多其他 Serverless 計(jì)算服務(wù)可用，其中包括對(duì)象存儲(chǔ)、NoSQL 數(shù)據(jù)庫(kù)和通知服務(wù)。盡管每種 Serverless 計(jì)算產(chǎn)品都在基礎(chǔ)架構(gòu)上運(yùn)行，但作為使用服務(wù)的用戶，不必?fù)?dān)心管理基礎(chǔ)架構(gòu)，PaaS 提供商會(huì)提供管理。

此外，也可以使用 Serverless 來構(gòu)建靜態(tài)網(wǎng)站，考慮一個(gè)使用 HTML、CSS、客戶端 JS 腳本和圖像構(gòu)建構(gòu)建的靜態(tài)網(wǎng)站，根據(jù)一個(gè)月內(nèi)網(wǎng)站的請(qǐng)求數(shù)收費(fèi)。現(xiàn)在，將其與按小時(shí)收費(fèi)的主機(jī)上運(yùn)行的類似站點(diǎn)進(jìn)行比較，無論那個(gè)站點(diǎn)的訪問量多少，收費(fèi)都是固定的。放眼未來，隨著越來越多的開發(fā)人員轉(zhuǎn)向 GraphQL 服務(wù)，我們會(huì)看到 Serverless 動(dòng)態(tài) Web 應(yīng)用程序的增加。

Serverless2.png

為什么要 Serverless

用戶為什么要采用服務(wù)架構(gòu)？首先，它降低單個(gè)工程師操作云基礎(chǔ)架構(gòu)的復(fù)雜性，這樣，工程師花費(fèi)更少的時(shí)間在基礎(chǔ)架構(gòu)，可以花費(fèi)更多的時(shí)間在代碼和有望解決的問題上。此外，降低云復(fù)雜性意味著開發(fā)人員與運(yùn)維之間摩擦?xí)p少，這樣可以加快功能開發(fā)速度，加快產(chǎn)品交付速度。

成本問題是采用 Serverless 的另一個(gè)原因，用戶為什么要為了不是那么經(jīng)常使用的云服務(wù)付費(fèi)？通過僅支付活躍使用的云資源費(fèi)用，組織可以削減成本。這就是將環(huán)境中不經(jīng)常使用的應(yīng)用程序改建為 Serverless 的原因。但是，并非所有程序都是平等創(chuàng)建的。某些應(yīng)用程序比其他應(yīng)用程序具有更好的成本效益。

最后，最重要的是，組織可以專注于其核心能力?，F(xiàn)在，每家公司都是技術(shù)公司，每個(gè)公司都需要大量的技術(shù)投資來保持其組織的運(yùn)轉(zhuǎn)。使用 Serverless 使組織可以在操作應(yīng)用程序上花費(fèi)更少的時(shí)間和資源，節(jié)省下來的時(shí)間和資源可以重定向到為客戶創(chuàng)造價(jià)值。企業(yè)組織的獨(dú)特之處不是它使用的云基礎(chǔ)架構(gòu)，而是它提供給用戶的功能和價(jià)值。

優(yōu)點(diǎn)、缺點(diǎn)

與所有技術(shù)一樣，它也有優(yōu)點(diǎn)和缺點(diǎn)。在采用 Serverless 解決方案之前，應(yīng)注意以下幾點(diǎn)：

優(yōu)點(diǎn)

高可擴(kuò)展性：Serverless 的第一個(gè)優(yōu)點(diǎn)是其可擴(kuò)展性，Serverless 平臺(tái)負(fù)責(zé)分配和管理功能實(shí)例以滿足需求。與傳統(tǒng)服務(wù)器體系結(jié)構(gòu)上的微服務(wù)相比，用戶需要在垂直或水平方向上擴(kuò)展主機(jī)以滿足需求，這可能需要手動(dòng)干預(yù)，自動(dòng)縮放規(guī)則執(zhí)行起來很慢。
減少云運(yùn)維的工作量：盡管 Serverless 不能完全消除這一點(diǎn)，但它減少了云基礎(chǔ)架構(gòu)操作的問題。開發(fā)人員需要花多少時(shí)間等待主機(jī)部署新代碼？借助 Serverless，同時(shí)部署應(yīng)用程序代碼和支持基礎(chǔ)架構(gòu)僅需幾分鐘，云基礎(chǔ)架構(gòu)幾乎不會(huì)出錯(cuò)，影響應(yīng)用程序代碼。之前有多少次因?yàn)?CPU、內(nèi)存或磁盤問題導(dǎo)致應(yīng)用程序報(bào)錯(cuò)，這些之后都不再是問題。
敏捷性和專注：最后，Serverless 使應(yīng)用程序開發(fā)人員可以專注于其代碼嘗試解決的問題，而不會(huì)被云基礎(chǔ)架構(gòu)所打擾。此外，快速部署的能力意味著團(tuán)隊(duì)可以交付更多成功的功能。采用 Serverless 的團(tuán)隊(duì)?wèi)?yīng)該能夠交付更多的功能，并準(zhǔn)確衡量他們是否已提供正確的功能。

缺點(diǎn)

供應(yīng)商綁定：如果用戶的組織與供應(yīng)商綁定在一起，那么 Serverless 不是用戶正確的選擇。對(duì)云提供商的服務(wù)使用越深入，就可以從中獲取更多的價(jià)值。如果用戶擔(dān)心過于依賴云供應(yīng)商，并希望靈活地更換供應(yīng)商，那么 Serverless 不是用戶的最佳選擇。
工程實(shí)踐仍在涌現(xiàn)：Serverless 工程仍在涌現(xiàn)，這意味著開發(fā)模式、流程和工具仍在開發(fā)中。此外，要找到成熟掌握 Serverless 功能技術(shù)的人并不容易，用戶需要花一些時(shí)間來開發(fā)組織的最佳實(shí)踐和培訓(xùn)資源。
不適合所有負(fù)載：Serverless 不適用于所有工作負(fù)載，尤其是長(zhǎng)期運(yùn)行的工作負(fù)載。Serverless 被設(shè)計(jì)用于短期運(yùn)行的臨時(shí)任務(wù)。如果用戶的任務(wù)需要大量的執(zhí)行時(shí)間，或者需要在兩次執(zhí)行之間跟蹤磁盤上的狀態(tài)，那么 Serverless 是不合適的，但是，重構(gòu)可能或多或少會(huì)解決這個(gè)問題。

中立

成本：幾個(gè)因素會(huì)影響 Serverless 服務(wù)的成本，包括工作量、使用的服務(wù)類型和平臺(tái)定價(jià)模型。并非所有 Serverless 工作負(fù)載都是相同的成本，這意味著某些服務(wù)在傳統(tǒng)的服務(wù)器上運(yùn)行成本更低，有些在 Serverless 架構(gòu)上運(yùn)行成本更低。

什么場(chǎng)景應(yīng)該使用 Serverless

什么時(shí)候使用 Serverless 解決方案？更具體地說，什么時(shí)候應(yīng)該使用 Serverless 功能？某些 Serverless 服務(wù)（例如 S3 和 dynamoDB）沒有持續(xù)時(shí)間和使用限制，這意味著用戶可以在 S3 桶中存儲(chǔ)任意數(shù)量的數(shù)據(jù)。

當(dāng)用戶需要處理計(jì)算負(fù)載時(shí)，Amazon Lambda 之類的 Serverless 功能會(huì)提出一些限制，例如：

用戶上傳的 AWS Lambda 的軟件包的最大大小為 50M；
Lambda 函數(shù)使用的內(nèi)存最大限制位3GB；
用戶持續(xù)的功能需要在15分鐘內(nèi)完成。

這些限制決定了哪些用例最適合 Serverless功能，每當(dāng)用戶需要執(zhí)行短暫的功能時(shí)，可以使用 Serverless 功能。在下面這些用例中，使用 Serverless 功能是不錯(cuò)的選擇：

數(shù)據(jù)處理 - 管理實(shí)時(shí)數(shù)據(jù)分析（而不是ETL作業(yè)）
聊天機(jī)器人 - 通過 Serverless 功能為聊天機(jī)器人賦能
啟用語音的應(yīng)用程序 - 與 Alexa 類似，使用 Lambda 函數(shù)為語音 UI 賦能
自動(dòng)化 - 使用 Serverless 功能管理云基礎(chǔ)架構(gòu)，實(shí)施策略等
物聯(lián)網(wǎng) - 將 Serverless 功能用于物聯(lián)網(wǎng)的服務(wù)端處理，物聯(lián)網(wǎng)設(shè)備的大型網(wǎng)絡(luò)可以產(chǎn)生大量數(shù)據(jù)

我們會(huì)更詳細(xì)地研究下列用例，以更好的理解，以下是幾個(gè) Serverless 功能的典型使用場(chǎng)景：

用例一：將數(shù)據(jù)上傳到云存儲(chǔ)后進(jìn)行處理

當(dāng)用戶將數(shù)據(jù)上傳到對(duì)象存儲(chǔ)器后（例如 S3、Cloud Storage 或 Azure Storage），可以觸發(fā) Serverless 功能以立即處理數(shù)據(jù)。例如：在一個(gè)費(fèi)用跟蹤 App 中，用戶為收據(jù)拍照時(shí)，需要將圖像存儲(chǔ)到對(duì)象存儲(chǔ)器中，然后對(duì)其進(jìn)行處理，對(duì)于 Serverless 功能，這是一個(gè)很好的應(yīng)用場(chǎng)景。

為了實(shí)現(xiàn)此解決方案，需要配置對(duì)象存儲(chǔ)器，使得在 S3 中創(chuàng)建對(duì)象時(shí)可以觸發(fā)事件調(diào)用特定的 Serverless 功能。場(chǎng)景不僅限于使用對(duì)象存儲(chǔ)器，用戶也可以在自己的方法中使用 Serverless 計(jì)算服務(wù)。示例中，我們可以處理圖像，將圖像存儲(chǔ)在其他對(duì)象存儲(chǔ)桶中，然后在 Serverless 數(shù)據(jù)庫(kù)表中更新一行。

用例二：客戶端App訪問數(shù)據(jù)庫(kù)

構(gòu)建具有豐富客戶端功能的應(yīng)用程序變的越來越普遍，例如基于 React 等框架構(gòu)建的 App 或單頁 Web 應(yīng)用程序。出于安全原因，它們?nèi)狈?duì)數(shù)據(jù)庫(kù)的直接訪問權(quán)限，通常用戶希望通過 Web 服務(wù)隊(duì)輸入進(jìn)行身份驗(yàn)證。

例如，已登錄的用戶希望查看其個(gè)人資料被查看了多少次，以及被誰查看。當(dāng)用戶單擊其個(gè)人資料時(shí)，我們要顯示其最新的個(gè)人資料統(tǒng)計(jì)信息。Web 應(yīng)用程序向 Rest API 網(wǎng)關(guān)發(fā)出 Get 請(qǐng)求，而 Rest API 網(wǎng)關(guān)又調(diào)用 Serverless 功能，Serverless 功能會(huì)調(diào)用數(shù)據(jù)庫(kù)獲取用戶配置文件數(shù)據(jù)，匯總數(shù)據(jù)并返回結(jié)果，然后 Web 應(yīng)用程序顯示數(shù)據(jù)。這是短暫的操作，不需要運(yùn)行專門的服務(wù)器。

用例三：數(shù)據(jù)流處理

Serverless 功能非常適合處理定期更新的數(shù)據(jù)流。例如，可以將一個(gè)方法與 Apache Kafka 或 Amazon Kinesis 一起使用以聚合數(shù)據(jù)并將其存儲(chǔ)在數(shù)據(jù)庫(kù)中。在此用例中，Kafka 將存儲(chǔ)數(shù)據(jù)流，然后 Lambda 方法將輪詢 Kafka，以50個(gè)項(xiàng)目為一組，消費(fèi)其中的數(shù)據(jù)并存儲(chǔ)在數(shù)據(jù)庫(kù)中。

用例四：突發(fā)事件

如果用戶的應(yīng)用程序收到突發(fā)的活動(dòng)，維護(hù)額外的服務(wù)器容量可能會(huì)非常昂貴，自動(dòng)伸縮規(guī)則執(zhí)行的速度也會(huì)很慢。

例如，用戶的后端服務(wù)同時(shí)支持 PC 和移動(dòng)端應(yīng)用程序。今天是您的幸運(yùn)日，您的應(yīng)用程序在 AppStore 的首頁上顯示，然后在 Hasker News 上進(jìn)行推廣。這樣的成功帶來了意想不到的活動(dòng)熱潮。

在后端使用 Serverless 設(shè)計(jì)，用戶永遠(yuǎn)不會(huì)知道您是否期待他們。Serverless 基礎(chǔ)架構(gòu)可以擴(kuò)展以滿足需求，而不會(huì)因?yàn)橄到y(tǒng)無法處理負(fù)載而導(dǎo)致系統(tǒng)故障。諸如金融業(yè)監(jiān)管局（FINRA）之類的公司每天可以處理多達(dá)5萬億個(gè) Serverless 功能調(diào)用。用戶系統(tǒng)收到的所有負(fù)載（無論是計(jì)劃內(nèi)的還是計(jì)劃外的）都將由 Serverless 架構(gòu)妥善處理。

什么場(chǎng)景不應(yīng)該使用 Serverless

使用 Serverless 架構(gòu)不能控制所有計(jì)算類型實(shí)例，根據(jù)系統(tǒng)需要，Serverless 不適用于某些執(zhí)行環(huán)境，以下是 Serverless 功能不適用的場(chǎng)景：

長(zhǎng)期運(yùn)行的代碼

Serverless 功能通常有最長(zhǎng)執(zhí)行時(shí)間的限制，因此，如果用戶的代碼需要連續(xù)執(zhí)行，或者需要執(zhí)行較長(zhǎng)的計(jì)算，則它們不是理想的選擇。例如，用戶的應(yīng)用程序具有一種調(diào)度算法，可將數(shù)千名學(xué)生和班級(jí)與老師進(jìn)行匹配，匹配算法大約需要一個(gè)小時(shí)才能完成。此代碼無法作為 Serverless 功能成功運(yùn)行。由于用戶無法更改 Serverless 功能的執(zhí)行時(shí)間限制，因此用戶需要更改實(shí)現(xiàn)或?qū)?yīng)用程序部署到服務(wù)器上。

進(jìn)程間通信

由于 Serverless 功能在隔離的環(huán)境中運(yùn)行，因此無法在兩個(gè)功能之間共享內(nèi)存。這種情況最有可能來自多線程實(shí)現(xiàn)，其中每個(gè)線程使用共享內(nèi)存區(qū)域來回傳遞數(shù)據(jù)。也就是說，用戶可以使用單獨(dú)的緩存來存儲(chǔ)數(shù)據(jù)，可以在方法和方法之間共享此緩存。

遺留系統(tǒng)

如果用戶將現(xiàn)有系統(tǒng)遷移到 PaaS 平臺(tái)，不多數(shù)不是為了短暫的活動(dòng)運(yùn)行而設(shè)計(jì)的，因此，它不適合 Serverless 功能。由于大多數(shù)企業(yè)系統(tǒng)被設(shè)計(jì)為一旦啟動(dòng)永久運(yùn)行，知道它們停止運(yùn)行或崩潰，所以升降機(jī)方法可能不適合 Serverless 計(jì)算模型。但是，一旦系統(tǒng)遷移到云中，就可以將應(yīng)用程序的部分遷移到 Serverless 架構(gòu)。

管理 Serverless 服務(wù)

在考慮過濾到 Serverless 功能時(shí)，用戶還需要研究如何有效地管理它們。由于采用 Serverless 可減少運(yùn)營(yíng)和管理的開銷，用戶需要適當(dāng)?shù)墓ぞ叽_保功能可靠、安全且經(jīng)濟(jì)地運(yùn)行。

身份驗(yàn)證和授權(quán)

應(yīng)用程序身份驗(yàn)證和授權(quán)可以采用云供應(yīng)商的服務(wù)（如 AWS Cognito）、第三方 SaaS 服務(wù)（例如 Auth0），或者采用自定義的授權(quán)功能方法。組織通常依賴某種令牌或 API 密鑰功能來控制公共訪問，合規(guī)性要求需要保證員工在有限的基礎(chǔ)上訪問敏感數(shù)據(jù)。依靠 IP 白名單或 VPC 連接可能無法提供大型組織中所需的細(xì)粒度控制。

限流

Serverless 內(nèi)置的可擴(kuò)展性可能使用戶產(chǎn)生錯(cuò)覺，不需要限流功能，但事實(shí)并非如此。大多數(shù)平臺(tái)都提供基于使用情況的支付模型，因此，使用量激增可能導(dǎo)致大筆賬單，無論是否有意為之。

對(duì)于每個(gè)傳入的 API 請(qǐng)求，云供應(yīng)商都負(fù)責(zé)分配功能示例來處理該請(qǐng)求。隨著 Serverless 的可伸縮性和滿足需求的重?fù)?dān)轉(zhuǎn)移到了云供應(yīng)商，為什么還要對(duì) API 限流呢？因?yàn)閺膶?shí)際運(yùn)行的角度來說，云供應(yīng)商會(huì)對(duì)服務(wù)施加限制和配額，而且，這些限制通常涉及范圍很廣，這意味著，過度使用某個(gè) API 會(huì)影響其他 API 成功運(yùn)行。幸運(yùn)的是，云供應(yīng)商可以評(píng)估 API 服務(wù)的速率或限制函數(shù)調(diào)用的并發(fā)性。對(duì)于更智能的限流邏輯，用戶可能需要考慮使用自己的 API 網(wǎng)關(guān)（例如 Kong）進(jìn)行限流。

可觀察性：度量、監(jiān)控、記錄和追蹤

我們之前提過，Serverless 會(huì)減少但不是不需要云運(yùn)維工作。Serverless 及其事件驅(qū)動(dòng)的體系結(jié)構(gòu)會(huì)導(dǎo)致一定程度的應(yīng)用程序復(fù)雜性。當(dāng)出現(xiàn)問題時(shí)，需要知道是執(zhí)行鏈中的哪一環(huán)出錯(cuò)了。保證 Serverless 應(yīng)用程序運(yùn)行意味著需要增加整個(gè)應(yīng)用程序堆棧的可觀察性，但這并沒有增加整體負(fù)載。在管理主機(jī)上節(jié)省時(shí)間意味著有更更多時(shí)間主動(dòng)確保應(yīng)用程序的可靠性。

安全

Serverless 安全隱患類似于當(dāng)今的虛擬化或容器化的服務(wù)。應(yīng)用程序代碼和應(yīng)用程序依賴的安全性都非常重要，而且相同的做法也可以延續(xù)到 Serverless。沒有了服務(wù)器后，無需花費(fèi)時(shí)間在主機(jī)級(jí)別的安全問題上，例如軟件補(bǔ)丁和訪問控制。相反，應(yīng)將注意力轉(zhuǎn)向保護(hù)云基礎(chǔ)架構(gòu)和功能代碼，以防止諸如遠(yuǎn)程執(zhí)行代碼或 SQL 注入之類的攻擊。

使用 API 網(wǎng)關(guān)

像 Kong 這樣的 API 網(wǎng)關(guān)可以使用戶更輕松地管理 Serverless 功能。Kong 無需在每個(gè)功能中實(shí)現(xiàn)所有這些管理功能，而可以將它們放在集中且易于管理的位置。它充當(dāng)代理并接受來自客戶端的調(diào)用，然后將其傳遞給 Serverless 方法。添加身份驗(yàn)證、安全性、可觀察性等功能就如同從 Kong Hub 中添加插件一樣容易。此外，與云供應(yīng)商分開的 API 網(wǎng)關(guān)允許用戶管理多個(gè)云環(huán)境中的方法。

這進(jìn)一步減少了發(fā)布新功能所需的開發(fā)工作量，不必?fù)?dān)心服務(wù)器基礎(chǔ)結(jié)構(gòu)或服務(wù)管理，意味著開發(fā)人員可以專注于業(yè)務(wù)邏輯并加快產(chǎn)品的上市時(shí)間。

Serverless 如何改變業(yè)務(wù)

改變組織流程和結(jié)構(gòu)的技術(shù)并不新鮮，看下共有云的采用和其產(chǎn)生的影響即可知。對(duì)于 Serverless，同樣會(huì)再次發(fā)生。競(jìng)爭(zhēng)優(yōu)勢(shì)將屬于優(yōu)先采用這些做法的公司，這是當(dāng)前世界已經(jīng)發(fā)生變革的一些方式。

DevOps 的興起

首先，Serverless 將開發(fā)人員和運(yùn)營(yíng)人員轉(zhuǎn)向 DevOps 角色，使得他們工作更加緊密。通過將基礎(chǔ)架構(gòu)和代碼結(jié)合在一起，軟件開發(fā)人員將不需要運(yùn)維工程師將其代碼投入生產(chǎn)。一些組織將看到傳統(tǒng)的運(yùn)維工程師重新培養(yǎng)新技能并成為開發(fā)團(tuán)隊(duì)的一部分，他們將在這個(gè)新職位上處理團(tuán)隊(duì)服務(wù)的運(yùn)營(yíng)需求。這是 DevOps 的夢(mèng)想：一個(gè)完整的跨職能團(tuán)隊(duì)，涉及軟件開發(fā)和運(yùn)維生命周期的所有成員。

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

未來屬于 Serverless