最近幾個月，我已經停止寫關於Serverless的博客了。這有很多原因，但很多原因都是因為我感覺已經沒有太多的東西來增加討論了。不是因為我沒有什麼新鮮事要說，而是因為我已經在以前的博客帖子、Twitter帖子或錄音談話中說了很多。過了一陣子，這些談話和要點對我來說並不新鮮了，一遍又一遍地說同樣的話，對我來說真的很難，也有點毫無意義。
但我已經清楚的是，對於使用Serverless作為術語的個人，以及正在構建服務並稱之為Serverless的供應商，仍然有一些基本方面需要澄清。
所以，讓我帶你去了解一下為什麼我認為Serverless是Cloud 2.0的開始。
一、代碼為王的時代
在技術發展的很長一段時間裡，構建網絡化應用程序依賴於軟件。要知道發生了什麼事情，你必須非常瞭解的軟件，或者瞭解從某個地方下載並部署的軟件。
開源運動在一定程度上是對試圖控制互聯網軟件供應的主要軟件公司的反應，這導致了一些難以置信的工具和服務的驚人爆炸式增長。
在20世紀90年代末和21世紀初，我們看到了一些開源技術的出現，尤其是LAMP技術棧，為圍繞著互聯網的令人難以置信的一系列創新奠定了基礎。
隨著虛擬化技術的出現，“代碼為王”似乎是不可避免的，這導致了雲服務和能夠改變技術方向的巨無霸雲供應商。
雲服務成為了規範，儘管許多公司仍然停留在內部私有云時代，但它肯定正在成為企業的事實標準。
所有這些都是以能夠將自己的代碼上傳到雲端為前提的。
代碼為王，程序員正在製造新的國王。https://thenewkingmakers.com/ —正如Redmonk的Stephen O’Grady所說，這句話由來已久。
這就是很久以來的情況。開發人員開發軟件，運維團隊管理基礎設施，雖然DevOps運動為這些團隊提供了更好的合作方式——CI/CD、流程自動化、理解的改進——但這種分離仍然存在。
二、Serverless模糊了開發和運維邊界
很快Serverless來了。而很多人會爭論什麼時候Serverless出現（以及它是什麼！）我絕對會把Serverless的誕生與2014年在Re：invent推出的AWS lambda聯繫起來（我不會解釋為什麼我要在這裡這樣做，這並不完全相關）。Serverless!=FaaS，FaaS是Serverless的主要推動者，這是一個突破，意味著它成為主流。
對我來說，關鍵是，Serverless依賴的開發人員，需要比以往任何時候都更高的層次去理解運維。也就是說，開發人員需要了解軟件如何實現容量伸縮的行為，包括：怎麼擴容到100和縮容到零，以及數據訪問行為等，諸如：使用峰值如何影響數據訪問或類似的情況。
我對Serverless的定義也是經濟層面的：
“一個Serverless應用程序是指在無人使用的情況下運行它不需要花費任何成本，但不包括數據存儲成本。”
因此，這依賴於開發人員至少在一定程度上理解他們是業務的一部分，而不是孤立於業務決策。當涉及到雲計算時，這通常更像是運營團隊職責的一部分。
當您使用所有這些元素時，與以前的範例相比，開發人員在新的Serverless世界中承擔更多的責任。
對於開發人員來說，不瞭解Serverless解決方案中更改的影響以及發生的意外後果（具有財務影響）要容易得多。
Serverless的轉變依賴於他們對基礎設施如何工作的理解，實際上更少地依賴於他們的代碼質量多好或多差。
這給我們帶來了一個有趣的觀點。
三、“代碼就是王者”時代已過時，“基礎設施”是新王者
當您以Serverless的方式構建時，您通常更依賴於雲提供商提供的服務。正如人們經常提到的，Serverless不是一個好名字，“服務型的”可能是一個更好的名字。
這是有道理的。瞭解要使用的服務以及什麼時候是構建一個好的Serverless應用程序的關鍵元素。
但這只是Serverless模式轉變的一部分。第二部分並不總是那麼明顯。
您實際上需要儘可能少的代碼。
因為代碼是一種責任。
我不是唯一一個從上面的tweet看出結論的人。其他人，如：Joe Emison，談到在Serverless的範例時，認為LOC（代碼行數）需要保持儘可能的少。
因為如果代碼更少，那麼複雜性就更少。
這包括您的基礎結構，它應該是某種定義語言的形式，允許您部署應用程序。因為當您構建一個Serverless應用程序時，您正在創建連接服務的基礎結構和業務邏輯，以及一些“代碼”，其中“代碼”只是您編寫的代碼，以實現服務無法實現的功能。
事實上，您的代碼遠不如您如何設計應用程序重要。這仍然很重要，但比以前要少得多。如何利用雲服務成為您的應用程序。
我建議這樣做：
最終的Serverless應用程序中根本沒有代碼
四、Cloud2.0：基礎架構為王
為什麼我把這個叫做“Cloud 2.0”，並把它變成一個“新事物”，好像它在某種程度上有所不同？
這真的很簡單。
到目前為止，雲計算的概念一直是關於構建應用程序和部署到服務器、實例容器上。
Serverless，“Cloud 2.0”不再是那麼回事了。
Serverless的目標是將代碼減少到零，並使用雲供應商服務儘可能多地完成工作。這就是為什麼當有人跟我說“在K8S上運行FaaS”是Serverless的時候，我覺得這很令人困惑。對我來說，這嚴重地增加了代碼的數量，減少了正在使用的服務的數量，與Serverless的想法完全相反。是的，它使用“函數”，如果這是使某個東西變得Serverless的唯一定義，那麼很好，但是如果您看一下上面的內容，這種方法就變得荒謬了。
上世紀90年代末，我在一所大學的數據中心開始了我的技術生涯，並且是一名系統管理員。我知道運行實際的機器和處理所有問題意味著什麼。我整個職業生涯都在努力避免那些問題。
雲供應商花了十多年的時間來構建服務，以便用戶不必構建複雜的系統。
如果您可以簡單地從雲提供商處購買服務，那麼為什麼您要在K8S之上運行自己的服務功能，或者在雲提供商上運行類似的服務功能？從LOC/維護/時間/努力的角度來看，這真的沒有意義，除非你必須使用on-prem或類似產品，否則我不理解。
如果你還想，那就去吧。
但幾乎可以肯定的是，你不再需要了。
五、Cloud 2.0：誰創造了新國王？
以Stephen O’Grady和他書中的詞組為例，我想知道新的國王會是誰？
我有一些想法。
我認為會是那些掌握了這種新的“基礎設施就是王者”模式的人。
我認為會是那些明白了完美的代碼不再是成功的必要條件的人。
我認為會是那些明白了無論你今天寫的代碼，都是明天的技術債務的人。
我認為會是那些明白了工作背後的商業規則比技術成就更重要的人。
我認為會是Serverless的架構師……
......以及那些理解高伸縮性和可用性雲服務，並知道如何編寫高度優化和最小化的代碼來將它們連接在一起，並對技術債務持非常務實的觀點的人。
六、但是，我們仍未到達......
這個新世界缺少工具、故事和英雄。
目前，我們正在使用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
譯者介紹：
ArthurGuo 職場老司機。21世紀初開始擁抱開源，後轉型項目管理。現在某雲計算公司擔任技術總監。掌握多門計算機語言，但更擅長人類語言。愛玩文字，不喜毒舌。