【轉載】Serverless 系列之（4）： Serverless 的優點

前面（系列之3⃣️）我們就讨論過，雲計算的基礎設施外包帶來五大好處：

• 降低人工成本
• 降低風險
• 降低基礎設施成本
• 擴充性
• 傳遞時間

Serverless 同樣也有這 5 個優點， 前四個都或多或少是關于成本節約的，這就是Serverless最為人所知的：如何做你以前做過的同樣的事情，但更便宜。但是，對我們來說，節省成本并不是無伺服器最令人興奮的部分，我們得到最大的好處是，它減少了從新的想法到實施上線的時間，換句話說，它能夠讓你更快地創新。

降低人工成本

我們在之前說過，Serverless本質上不再需要關心自己的伺服器和程序 ，您隻需要關心應用程式的業務邏輯和狀态，所有其他不必要的工作都交給平台來處理。這裡的第一個明顯好處是運維工作量減少， 您不再管理作業系統，更新檔級别，資料庫版本更新等。如果您正在使用BaaS資料庫，消息總線或對象存儲，那麼祝賀你，這些基礎架構也都不要你來運維。

通過其他BaaS服務，對于節省人工成本是比較直覺的，您自己開發的邏輯更少了。 我們已經多次讨論過身份驗證的BaaS服務，其中最大的好處是您可以使用較少的代碼來定義，開發，測試，部署和操作，所有這些都減少了工程師時間成本，另一個例子是像Mailgun這樣的第三方郵件 BaaS 服務，它消除了處理電子郵件發送和接收的大部分複雜工作。

與傳統方法相比，FaaS還具有顯着的勞動力成本優勢。 使用FaaS進行軟體開發得以簡化，因為大部分基礎結構代碼已移至平台。 這裡的一個例子是HTTP API服務的開發 - 這裡所有的HTTP級請求和響應處理都是由API網關完成的。

使用FaaS進行部署更容易，因為我們隻是上傳打包成Zip格式(如果是 JS或者Python腳本語言)的基本代碼，或者如果是Java的話，則上傳普通的JAR檔案，沒有要管理的Puppet，Chef，Ansible或Docker配置。其他類型的操作活動也變得更加簡單，例如，由于我們不再關注“永遠線上”伺服器程序，是以我們可以将監控限制為更多面向應用程式的名額。 這些是統計資訊，例如執行持續時間和面向客戶的名額，而不是可用磁盤空間或CPU使用率。

降低風險

當我們考慮軟體應用風險時，我們經常考慮我們對故障和當機的敏感程度，我們的團隊負責管理的不同類型的系統或元件的數量越多，發生問題的風險就越大。我們可以不是自己管理這些系統，而是像我們之前描述的那樣，讓“外包”系統來解決這些問題。

雖然整體而言我們仍然面臨應用程式發生故障的風險，但我們選擇以不同的方式管理風險 - 我們現在依靠其他人的專業知識來解決其中的一些故障，而不是自己修複它們。這通常來說是一個好主意，因為應用的技術棧中，一些技術是平時很少發生變更的，當它們發生故障時，修複時間和難度都不确定。通過Serverless，我們可以顯着減少我們直接操作的技術棧的數量，那些我們仍在自己管理的技術，通常是我們非常熟悉并且頻繁變更的，是以我們更有能力在失敗時自信地處理失敗。

這裡的一個具體例子就是，管理分布式NoSQL資料庫。 一旦安裝了這樣的元件，節點發生中的故障可能相對罕見，但是當它發生故障時，會發生什麼？ 您的團隊是否具備快速有效地診斷，修複和恢複問題的專業知識？ 常常沒有。 相反，團隊可以選擇使用Serverless 的NoSQL資料庫服務，例如Amazon DynamoDB， 雖然DynamoDB中的中斷偶爾會發生，但由于亞馬遜擁有緻力于此特定服務的整個團隊，是以它們發生故障的次數更少，并且能夠更快的恢複。

是以，我們說當使用Serverless技術時，風險會降低，因為元件的預期當機時間會減少，并且修複它們的時間會更少。

降低資源投入成本

通常，當我們運作應用程式時，我們必須弄清楚它們将運作的底層主機類型和數量。 例如，我們的資料庫伺服器需要多少記憶體和CPU？ 我們需要多少個不同的執行個體來支援擴充？ 或者如何支援高可用性（HA）？

一旦我們規劃了我們需要的主機或資源，我們就可以進行配置設定我們的應用程式的哪些部分将在哪些資源上運作。 最後，一旦我們開始準備部署我們的應用程式，我們就需要實際獲得我們想要的主機，這是環境配置。

整個環境配置過程很複雜，我們很少提前知道我們的資源要求是什麼，是以我們高估了我們的計劃，這稱為過度配置，這實際上是正确的做法 - 擁有備用容量并保持我們的應用程式運作比在負載下降低更好。對于某些類型的元件（如資料庫），可能很難在以後擴充，是以我們可能希望通過過度配置，來承載未來預期的負載。

過度供應意味着我們總是為滿足處理峰值預期負載所需的容量付費，即使我們的應用程式沒有遇到負載也是如此。最極端的情況是，我們的應用程式處于空閑狀态時，在那個時間點，我們正在為我們的伺服器付費，而事實上它們并沒有做任何有用的事情。但即使我們的應用程式處于活動狀态，我們也不希望我們的主機得到充分利用。相反，我們希望留下一些空間，以應對意外的負載峰值。

無伺服器給這個領域帶來的巨大好處是我們不需要計劃，配置設定或配置資源，我們讓服務精确地提供我們在任何時間點所需的容量，如果我們沒有任何負載，那麼我們不需要任何計算資源，我們也不會支付任何費用。 如果我們隻有1 GB的資料，我們不需要容量來存儲100 GB。 我們相信，當我們需要時，服務将按需擴充，并且這同樣适用于FaaS和BaaS服務。

除了消除資源配置設定帶來的問題之外，無伺服器還使我們的成本更加高效。 對于負載不一樣的各種應用程式，我們将通過使用無伺服器來節省資源成本。 例如，如果我們的應用程式每小時隻運作5分鐘，我們隻需支付每小時5分鐘，而不是整個60分鐘。 此外，良好的無伺服器産品将具有非常精确的使用增量; 例如，AWS Lambda按100毫秒的使用時間收費，比EC2的每小時計費精确36,000倍。

在現代非 Serverless 應用程式中，我們通過自動伸縮等技術獲得了一些收益，但是，這些方法通常不如無伺服器産品那麼精确，并且通常無法自動擴充資料庫。

提高擴充性

所有這些資源成本優勢都來自于這樣一個事實，即Serverless服務可以精确地滿足我們的需求。 那麼我們如何才能真正實作這種擴充呢？ 我們需要設定自動縮放組嗎？ 監控流程？ 沒有！ 事實上，縮放是自動完成的，不費力氣。

我們以AWS Lambda為例。 當平台收到第一個觸發函數的事件時，它會啟動一個容器來運作你的代碼，如果在收到另一個事件時仍在處理此事件，則平台将啟動代碼的第二個執行個體以處理第二個事件。 這種自動，零管理，水準擴充将持續到Lambda有足夠的代碼執行個體來處理負載。

一個特别好的方面是AWS仍然隻會根據你代碼執行的時間收取費用，無論它有多少個容器要啟動。 例如，假設所有事件的總執行時間相同，在一個容器中按順序調用Lambda 100的成本與在100個不同容器中同時調用Lambda 100次的成本完全相同。

減少傳遞周期

上面的四個優勢，是考慮采用Serverless的非常好的理由，通過采用Serverless技術，可以帶來顯著的成本節省。

但是，我們想向您展示康卡斯特有線電視公司首席技術官Sree Kotay在2016年8月舉行的AWS峰會上的一句話：他不是在談論Serverless，他在談論康卡斯特如何從各種其他基礎設施外包中獲益匪淺，從“本地”轉向雲計算，他的原話如下：

經曆了雲和靈活的這一旅程，過去五年我們已經實作了收益，而且這些收益都是圍繞成本和規模進行的，它們是關鍵且重要的，但有趣的是它們并不是最引人注目的，最關鍵部分是這真的改變了你的創新周期，它從根本上改變了你對産品開發的看法。

- Sot Kotay

我們要提出的一點是，一家大公司的首席技術官說，成本和規模對他來說并不是最重要的事情，最重要的是創新。 那麼Serverless如何在這方面提供幫助呢？

Adrian Cockcroft（AWS的雲架構戰略副總裁，以及Netflix的前雲架構師），談論Serverless的時候，說到：

我們開始看到開發應用程式的時間越來越短，小型開發團隊在短短幾天内從頭開始建構生産就緒的應用程式。 他們使用簡短的功能和事件将強大的API驅動的資料存儲和服務粘合在一起。 已完成的應用程式已具有高可用性和可擴充性，高使用率，低成本和快速部署。

-Adrian Cockcroft

在過去幾年中，我們看到通過持續傳遞和自動化測試以及Docker等技術改進開發的增量周期時間取得了很大進展。 這些技術很棒，但隻有在設定和穩定後才能實作。 對于真正蓬勃發展的創新而言，縮短周期時間是不夠的，您還需要更短的傳遞周期 - 從新産品或功能的概念化到以最小的可行方式部署到生産環境的時間。

由于Serverless消除了在生産中大規模建構，部署和運作應用程式的大量附帶複雜性，是以它為我們提供了巨大的杠杆作用，以至于我們的軟體傳遞方式可以颠倒過來。通過正确的組織支援，創新和“精益創業”風格，實驗可以成為所有企業的預設工作方式，而不僅僅是為初創公司或“黑客日”保留的東西。

這不僅僅是一種理論。 除了Adrian的的觀點之外，我們看到相對缺乏經驗的工程師完成項目通常需要幾個月的時間，并需要更多資深工程師的幫助。 相反，使用Serverless，他們能夠在幾天内基本上無需幫助地實施項目。

這就是為什麼我們對Serverless感到非常興奮：除了節省所有成本之外，還可以釋放他們的能力，讓他們專注于讓産品與衆不同的地方。

原文連結： Serverless 系列之（4）： Serverless 的優點 - 知乎