原文連結：https://dzone.com/articles/serverless-vs-containers
作者：Yan Cui
譯者：殷龍飛
讓我們來看看采用率，工具支援以及圍繞無伺服器和容器化争論的其他因素。
在無伺服器和容器中，我們有兩種令人驚歎的技術，可以為工程師提供高效的，與機器無關的抽象。然而，兩個陣營之間似乎存在着不可逾越的鴻溝。
如果你讀過我在過去兩年寫的任何内容，你就會知道我堅定地站在無伺服器陣營。但我也是容器的早期采用者。在Docker達到1.0裡程碑後不久，2015年初我的第一個容器化項目問世。
這篇文章不是企圖另一次引發陣營戰争或宣布某個陣營的勝利。相反，我将嘗試客觀地看待無伺服器和容器的狀态，根據它們提供的利弊權衡，并對未來的情況給出誠實的看法。
鑒于無伺服器和FaaS函數即服務（FAAS）通常已經可以互換使用，為了本文的目的，我将限制無伺服器的定義為FAAS産品，例如AWS Lambda。
容器狀态
自從Docker早期可用以來，事情已經走過了漫長的道路。随着我們在容器上運作的系統越來越複雜，我們的需求已經催生了豐富的工具生态系統。
AWS還擁有自己的托管容器服務ECS。這提供了與AWS生态系統其他部分更緊密的內建。
如服務網格也正在獲得可見性和被采用。它們将常見的交叉問題（例如跟蹤和斷路器）移出應用層。通過解決基礎架構層中的這些問題，它們為這些挑戰提供了語言和運作時無關的解決方案。這使它們非常适合現代IT組織，即使用各種不同語言的建構微服務。
無伺服器狀态
雖然圍繞無伺服器的炒作并沒有和容器一樣長。值得記住的是，在Lamber達到1.0之後僅一個月，AWS Lambda就在 2014年釋出了。它随附了CloudWatch的基本日志記錄和監視支援，即使我們現在依賴的許多事件源（例如API Gateway）都是在之後引入的。
除了這些托管服務之外，還有一些解決方案可以讓您在自己的Kubernetes叢集上運作無伺服器。這些包括谷歌和合作公司最近宣布的。雖然這些解決方案試圖滿足許多開發人員的需求，但我感到他們放棄了無伺服器的最佳功能 - 不必擔心伺服器！
采用趨勢
根據一些調查和研究，無伺服器和容器的采用正在快速增長。以下是我認為的一些亮點。
- A Cloudability發現，2017年第四季度AWS使用者的容器采用量增長了246％，高于第三季度的206％。同時，同一項研究發現，2017年第四季度AWS使用者無伺服器采用量增長了667％，高于第三季度的321％。
- 無伺服器公司最近發現，2018年有82％的聯絡員使用無伺服器，高于2017年的45％。超過53.2％的人表示他們使用無伺服器技術對他們的工作至關重要。
- 無伺服器公司的調查還報告說，在采用無伺服器之前，24％的聯絡員對公共雲的使用經驗有限或為零。20.2％的為擁有1000多名員工的大型企業工作。
- Logz.io的 DevOps Pulse 調查發現，在2018年，60.71％的聯絡員采用了容器編排，高于2017年的42.11％。
有趣的是，DevOps Pulse調查顯示，無伺服器采用率比其他報告小得多。從2018年的30。55％（2017年）上升到42.58％。這可能與其聯絡員的分布有關。其中28.54％認為自己是開發者，而44.26％認定為DevOps，DevSecOps，SysAdmin或SRE。
這與我在容器和無伺服器陣營之間的上述鴻溝的經驗一緻。那些認為自己是開發人員的人更傾向于無伺服器，而那些被認為是DevOps的人更有可能選擇容器。
控制與責任
關于無伺服器與容器的争論通常始于控制，或者在無伺服器的情況下缺乏控制。這不是新的。事實上，我清楚地記得當AWS在2009年開始獲得牽引力時圍繞控制的相同辯論。現在10年後，塵埃落定于原始辯論，但我們未能吸取教訓。
想要控制是人的本性，但你願意為此付出多少錢？ 您知道您将承擔的總體擁有成本（TCO）嗎？
控制自己的基礎設施的能力帶來了很多責任。要承擔這些責任，您需要擁有組織中的相關技能。這意味着工資（很容易成為大多數組織的最大開支），代理費以及從工程師和經理那裡抽出時間進行招聘和入職。
考慮到所涉及的TCO，具有該控制的目标必須是針對某些事物進行優化（例如，為業務關鍵工作流程實作可預測的性能），并且不為其自身控制。
建構基于容器的通用計算平台需要大量的工程專業知識和投資，該平台與AWS Lambda等無伺服器産品一樣高效，可擴充且具有彈性。大多數組織根本沒有能力解決這個問題。盡管有大量的時間和金錢投入，但我知道一些大企業在他們的嘗試中慘遭失敗。
工具支援
使用無伺服器，您可以從box-logging，名額和跟蹤中獲得基本的可觀察性工具。盡管有這些警告，但一開始它們通常就足夠了。
傳統上迎合IAAS或容器市場的供應商也開始為無伺服器應用程式提供支援。但是，他們需要調整自己的方法，因為無伺服器無法再使用基于代理的方法。
還有越來越多的供應商專注于解決無伺服器應用程式的可觀察性和安全性問題。但是，大多數仍處于開發的早期階段，尚未準備好進行嚴肅的生産使用。
與無伺服器相比，容器空間具有更成熟和多樣化的工具生态系統。事實上，我發現使用容器的挑戰之一是處理絕大多數的選擇！
有充足的修補機會，我也發現團隊可能會忽略獎品（即為我們的客戶建立更好的産品），并陷入過度工程的陷阱。
無伺服器的工具支援将會越來越好，但至少目前，仍然遠遠落後于容器。在容器領域工作的人面臨的挑戰是抵制修補和追求簡單的沖動。
供應商鎖定：風險與獎勵
無伺服器的批評者通常使用供應商鎖定作為他們的論據。與此同時，大多數AWS客戶實際上都在要求更緊密的內建，以便他們可以從平台中擷取更多價值。
可以肯定的是，供應商鎖定是一種風險。但正如任何投資者都會告訴你的那樣，如果你不承擔風險，你就永遠不會賺錢。訣竅是采取能夠帶來最佳回報的計算風險。
對于它所獲得的所有關注，供應商鎖定對于少數人來說是一種危險。相反，您更有可能找到過度設計的解決方案來阻止供應商鎖定，而不是建立其他形式的鎖定，無論是内部團隊還是其他私有雲供應商。
同樣，這不是新的。幾年前我們與ORM進行了同樣的辯論。我們建立了所有這些抽象來防止供應商鎖定，除了風險從未實作為我們大多數人的問題。所發生的一切都是我們花費了大量精力和時間，并推遲了我們的産品上市時間，因為這些産品從未成為問題。
更糟糕的是，ORM引入了他們自己的問題和複雜性，并持續阻礙了發展。它成為開發團隊的一項稅收，并在可預見的未來減緩了功能傳遞。
對于那些必須進行資料庫遷移的人來說，ORM并沒有讓事情變得更好。除了其他一切之外，這隻是你必須處理的另一個問題。
看到曆史重演，這次，甚至更高的層次可能會影響整個組織，這是痛苦的！
公司發現無伺服器團隊的工作量越來越多，工程師也越來越多。是以，就像一個明智的投資者一樣，我們應該問的問題是：“重要的生産力回報是否值得鎖定風險，實作問題的可能性很小？”
未來是無伺服器還是容器？
無伺服器為您提供了大量的生産力提升，但卻以控制基礎架構為代價。
對于我們的許多工作流程 - 網絡API，流處理，cron作業等 - 實際上我們不需要這些所有的控制，我們應該祝福為我們處理管道的人。
但總會出現這樣的情況：我們需要保持對基礎架構的控制，以便優化性能，成本或更高的可用性。或者，我們的工作量可能不利于無伺服器的目前限制，例如最長執行時間。
我認為無伺服器和容器應該混合使用，而不是選擇其中一個。實際上，許多公司都成功的采用了混合方法。
- 對無伺服器滿足其需求的工作負載使用無伺服器
- 例如，對于以下工作負載，請使用容器;
- 長期運作
- 需要可預測的性能
- 需要比無伺服器更容易實作的彈性
- 不斷地以大規模運作，并且按次付費定價模型變得過于昂貴
這也是Netflix前雲架構師兼現任AWS雲計算副總裁Adrian Cockcroft的建議。
我相信我們最終會看到這兩種範式的趨同。容器技術最終将成為無伺服器 - 想想Fargate，加上每次調用定價模型和毫秒計費。同時，無伺服器平台将開放并允許您攜帶自己的容器。進階使用者可以通過提供符合API的子元件進行日志記錄等來保留對其基礎架構的一些控制。
随着容器和無伺服器之間的界限被打破，我們終于可以廢除派系并停止談論底層技術。我想談的是如何建構客戶想要使用的産品，以及如何更快地建構它們。
我們來談談吧！