無服務器計算是當前的熱門話題，甚至熱度超過 Docker 容器。當然，技術圈內的口水戰從來不會因為技術發展而停止。過去一年，關於無服務器計算可能取代容器的言論甚囂塵上。搞好了，無服務計算可以和容器相輔相成；搞不好，不僅面臨綁定風險還可能耗費高昂成本。
無服務器與容器現狀
自 Docker 出現開始計算，容器已經走過漫長的一段路。目前，不少企業在容器上運行越來越複雜的應用，生態系統也越來越完善。大型互聯網公司，比如阿里巴巴，在容器層面進行了不少自研工作。通過解決基礎架構層的問題，目前容器已經可以提供與語言和運行時無關的解決方案，這非常適合現代 IT 架構，即使用不同的語言構建微服務。
圍繞無服務器的炒作顯然沒有容器那麼長，除了託管服務外，一些解決方案可讓用戶在自己的 Kubernetes 集群上運行無服務器，比如谷歌與其合作伙伴所做的工作。雖然這些解決方案試圖滿足開發人員的所有需求，但不免讓人感覺已經開始放棄無服務器的最大優勢——不必擔心服務器！
適用場景
雖然無服務器計算可以和容器一起使用，但研發人員還是需要清楚各自的使用場景。
無服務器計算更傾向於處理網站或移動應用程序的後端任務，該任務相對快速且簡單，可以根據需要執行，不會佔用太多前端時間或資源；負責高容量的後臺進程，比如將數據移動到長期存儲設備上，或者轉換、處理和分析數據，無服務器可以協調各個數據庫，這一點也很關鍵；實時數據流處理和上傳，無服務器可以解析、過濾傳入數據流；將資源密集型實時進程挪出主應用，避免佔用過多資源。
相比較而言，容器更適合需要長期運行、性能可掌握的大規模應用程序。由於二者的不同特點，容器比無服務器更容易實現彈性，並且更容易接觸底層架構以調整性能、可用性和易用性等之間的關係。
優劣對比
眾所周知，無服務器計算並不是沒有服務器，這只是相對用戶體驗而言，服務器由雲供應商統一管理、配置，開發人員只需專注代碼層面即可，無需操心底層細節，這可能就是技術研發人員更喜歡無服務期計算的原因。
對企業而言，這種方式很容易被供應商鎖定，而且很可能與單一雲供應商的綁定越來越緊密，企業試圖找到解決方案但往往會陷入另一種形式的綁定中，比如私有云。此外，不少企業在運行應用程度時其實希望瞭解底層基礎設施的狀況，以此調整一些性能指標。但是，無服務器計算無法讓企業掌握這些信息，這既是它的優勢也是它的劣勢。當然，不少雲供應商在積極嘗試解決這些問題，只是還都處於早期階段。
容器在很多方面都可以做得比無服務器計算更優，比如更適合運行大規模複雜應用程序，容器可以將其拆分為微服務；可以很容易掌握整個虛擬化基礎架構，這可能也是 DevOps 人員偏愛容器的原因之一；在瞭解架構的基礎上，技術人員可以進行適當的測試和調整。
投入成本
風險總是與回報並存，無服務期計算雖然有不足，但可以節省不小一筆開支，比如基礎設施成本、人力成本等，同時免於承擔設置基礎設施的責任。
但是，構建基於容器的通用計算平臺需要大量具備專業知識的人才和一筆不小的投資，該平臺與 AWS Lambda 等無服務器產品一樣高效，可擴展且具有彈性。大多數企業根本沒有能力解決過程中的問題。往往是投入了大量時間和金錢，最終還是竹籃打水一場空。
未來是無服務器還是容器？
無服務器可大幅提升生產力，但卻以控制基礎架構為代價。開發人員糾結得往往是選擇哪種方式運行應用程序。最終，無服務期計算和容器大概率會趨向協同，無服務器計算可能會更加開放，允許用戶自己選擇容器。高級用戶甚至可通過提供符合 API 的子組件進行日誌記錄等保留對基礎架構的控制。
閱讀更多 InfoQ 的文章
