Cloud 2.0：代碼再也不爲王，Serverless 當道！

最近幾個月，我已經中止寫關於Serverless的博客了。這有不少緣由，但不少緣由都是由於我感受已經沒有太多的東西來增長討論了。不是由於我沒有什麼新鮮事要說，而是由於我已經在之前的博客帖子、Twitter帖子或錄音談話中說了不少。過了一陣子，這些談話和要點對我來說並不新鮮了，一遍又一遍地說一樣的話，對我來講真的很難，也有點毫無心義。

但我已經清楚的是，對於使用Serverless做爲術語的我的，以及正在構建服務並稱之爲Serverless的供應商，仍然有一些基本方面須要澄清。

因此，讓我帶你去了解一下爲何我認爲Serverless是Cloud 2.0的開始。

1、代碼爲王的時代

在技術發展的很長一段時間裏，構建網絡化應用程序依賴於軟件。要知道發生了什麼事情，你必須很是瞭解的軟件，或者瞭解從某個地方下載並部署的軟件。

開源運動在必定程度上是對試圖控制互聯網軟件供應的主要軟件公司的反應，這致使了一些難以置信的工具和服務的驚人爆炸式增加。

在20世紀90年代末和21世紀初，咱們看到了一些開源技術的出現，尤爲是LAMP技術棧，爲圍繞着互聯網的使人難以置信的一系列創新奠基了基礎。

隨着虛擬化技術的出現，「代碼爲王」彷佛是不可避免的，這致使了雲服務和可以改變技術方向的巨無霸雲供應商。

雲服務成爲了規範，儘管許多公司仍然停留在內部私有云時代，但它確定正在成爲企業的事實標準。

全部這些都是以可以將本身的代碼上傳到雲端爲前提的。

代碼爲王，程序員正在製造新的國王。https://thenewkingmakers.com/ —正如Redmonk的Stephen O’Grady所說，這句話由來已久。

這就是好久以來的狀況。開發人員開發軟件，運維團隊管理基礎設施，雖然DevOps運動爲這些團隊提供了更好的合做方式——CI/CD、流程自動化、理解的改進——但這種分離仍然存在。

2、Serverless模糊了開發和運維邊界

很快Serverless來了。而不少人會爭論何時Serverless出現（以及它是什麼！）我絕對會把Serverless的誕生與2014年在Re：invent推出的AWS lambda聯繫起來（我不會解釋爲何我要在這裏這樣作，這並不徹底相關）。Serverless!=FaaS，FaaS是Serverless的主要推進者，這是一個突破，意味着它成爲主流。

對我來講，關鍵是，Serverless依賴的開發人員，須要比以往任什麼時候候都更高的層次去理解運維。也就是說，開發人員須要瞭解軟件如何實現容量伸縮的行爲，包括：怎麼擴容到100和縮容到零，以及數據訪問行爲等，諸如：使用峯值如何影響數據訪問或相似的狀況。

我對Serverless的定義也是經濟層面的：

「一個Serverless應用程序是指在無人使用的狀況下運行它不須要花費任何成本，但不包括數據存儲成本。」

所以，這依賴於開發人員至少在必定程度上理解他們是業務的一部分，而不是孤立於業務決策。當涉及到雲計算時，這一般更像是運營團隊職責的一部分。

當您使用全部這些元素時，與之前的範例相比，開發人員在新的Serverless世界中承擔更多的責任。

對於開發人員來講，不瞭解Serverless解決方案中更改的影響以及發生的意外後果（具備財務影響）要容易得多。

Serverless的轉變依賴於他們對基礎設施如何工做的理解，實際上更少地依賴於他們的代碼質量多好或多差。

這給咱們帶來了一個有趣的觀點。

3、「代碼就是王者」時代已過期，「基礎設施」是新王者

當您以Serverless的方式構建時，您一般更依賴於雲提供商提供的服務。正如人們常常提到的，Serverless不是一個好名字，「服務型的」多是一個更好的名字。

這是有道理的。瞭解要使用的服務以及何時是構建一個好的Serverless應用程序的關鍵元素。

但這只是Serverless模式轉變的一部分。第二部分並不老是那麼明顯。

您實際上須要儘量少的代碼。

由於代碼是一種責任。

我不是惟一一個從上面的tweet看出結論的人。其餘人，如：Joe Emison，談到在Serverless的範例時，認爲LOC（代碼行數）須要保持儘量的少。

由於若是代碼更少，那麼複雜性就更少。

這包括您的基礎結構，它應該是某種定義語言的形式，容許您部署應用程序。由於當您構建一個Serverless應用程序時，您正在建立鏈接服務的基礎結構和業務邏輯，以及一些「代碼」，其中「代碼」只是您編寫的代碼，以實現服務沒法實現的功能。

事實上，您的代碼遠不如您如何設計應用程序重要。這仍然很重要，但比之前要少得多。如何利用雲服務成爲您的應用程序。

我建議這樣作：

最終的Serverless應用程序中根本沒有代碼

4、Cloud2.0：基礎架構爲王

爲何我把這個叫作「Cloud 2.0」，並把它變成一個「新事物」，好像它在某種程度上有所不一樣？          

這真的很簡單。

到目前爲止，雲計算的概念一直是關於構建應用程序和部署到服務器、實例容器上。            

Serverless，「Cloud 2.0」再也不是那麼回事了。

Serverless的目標是將代碼減小到零，並使用雲供應商服務儘量多地完成工做。這就是爲何當有人跟我說「在K8S上運行FaaS」是Serverless的時候，我以爲這很使人困惑。對我來講，這嚴重地增長了代碼的數量，減小了正在使用的服務的數量，與Serverless的想法徹底相反。是的，它使用「函數」，若是這是使某個東西變得Serverless的惟必定義，那麼很好，可是若是您看一下上面的內容，這種方法就變得荒謬了。

上世紀90年代末，我在一所大學的數據中心開始了個人技術生涯，而且是一名系統管理員。我知道運行實際的機器和處理全部問題意味着什麼。我整個職業生涯都在努力避免那些問題。

雲供應商花了十多年的時間來構建服務，以便用戶沒必要構建複雜的系統。

若是您能夠簡單地從雲提供商處購買服務，那麼爲何您要在K8S之上運行本身的服務功能，或者在雲提供商上運行相似的服務功能？從LOC/維護/時間/努力的角度來看，這真的沒有意義，除非你必須使用on-prem或相似產品，不然我不理解。

若是你還想，那就去吧。

但幾乎能夠確定的是，你再也不須要了。

5、Cloud 2.0：誰創造了新國王？

以Stephen O’Grady和他書中的詞組爲例，我想知道新的國王會是誰？

我有一些想法。

我認爲會是那些掌握了這種新的「基礎設施就是王者」模式的人。

我認爲會是那些明白了完美的代碼再也不是成功的必要條件的人。

我認爲會是那些明白了不管你今天寫的代碼，都是明天的技術債務的人。

我認爲會是那些明白了工做背後的商業規則比技術成就更重要的人。

我認爲會是Serverless的架構師……

......以及那些理解高伸縮性和可用性雲服務，並知道如何編寫高度優化和最小化的代碼來將它們鏈接在一塊兒，並對技術債務持很是務實的觀點的人。

6、可是，咱們仍未到達......

這個新世界缺乏工具、故事和英雄。

目前，咱們正在使用Cloud 1.0工具來嘗試提供Serverless解決方案。

目前，科技界尚未爲這些新工具作好準備。

不過咱們離得不遠。

Cloud 2.0是Serverless

這就是咱們將要結束的地方。我敢確定！

原文連接：

https://medium.com/@PaulDJohnston/cloud-2-0-code-is-no-longer-king-serverless-has-dethroned-it-c6dc955db9d5