什麼時候該用無服務器，什麼時候該用Kubernetes構建雲原生應用程序？
一個好的無服務器應用場景應該是在夜間沒有太多或者完全沒有流量。由於無服務器平臺僅在代碼運行期間收費，因此可以顯著降低成本。較大的應用程序不執行任何操作，無服務器便宜的可能性越大。
但是，這並不意味着無服務器就可以降低成本，如果應用程序全天候運行，可能存在一些隱性成本，比如管理API造成的額外成本和測試函數的調用成本。
沒經驗，怎麼選？
就聽而言，無服務器和Kubernetes好像已經非常成熟；但就實踐而言，二者還有很多成長空間，研發人員也並未達到人人普及的程度。如果既沒有無服務器也沒有Kubernetes經驗，那麼，在無服務器平臺運行Hello World應用程序應該更容易。
因爲無服務器只需將精力集中在代碼上即可，使用Kubernetes則通常需要等待一段時間來創建集羣，配置Kubernetes以獲取公共IP地址，然後再部署容器。使用無服務器平臺，只需使用雲提供商的Web工具即可在幾分鐘內上手。
有經驗，怎麼看？
這種難易程度也是變化的，無服務器並不總比Kubernetes更容易。使用一堆函數構建和管理無服務器應用程序比只有一個容器的簡單Kubernetes應用程序更難。實際上，將Kubernetes用於更復雜的應用程序可能更容易，因爲該平臺更成熟。
無服務器計算最強大的功能之一是自動可擴展性，開發人員無需採取任何措施就可利用此功能。使用Kubernetes，研發人員還可使用pod甚至節點自動可擴展性，但需要一些配置並且速度稍慢，因爲只有在某些規則適用時纔會觸發此過程。
但是，Kubernetes可能提供比某些無服務器平臺更好的可擴展性，因爲Kubernetes更加成熟，並且在不同區域之間提供HA（高可用性），這並非所有無服務器平臺都提供。
A/B測試可能是構建雲原生應用程序的關鍵功能，但無服務器平臺並不具備這一點，Kubernetes則可以。此外，Kubernetes應用程序的監控功能更加成熟。例如，使用Istio可以看到微服務的執行時間，服務調用情況以及是否存在問題。無服務器平臺因其自身的最大優勢就是不需要操心基礎設施，所以研發人員可做的操作也十分有限。
如果應用程序相當簡單，只有一個函數提供API，則無服務器可能是更好的選擇，因爲部署會更容易，並且各種無服務器平臺都可提供對單個函數的監控。
響應延遲對比
使用無服務器平臺時，由於需要初始化代碼，因此第一次調用函數需要花費一些時間。比如，在OpenWhisk中使用Docker容器，容器需要時間才能啓動Java應用程序。如果需要快速可靠的響應時間，則可以使用Kubernetes。
通過應用緩存，無服務器平臺對響應時間做了改善。第一次冷啓動後，不必再花費較長響應時間啓動第二次，這可能足以滿足應用需求。
高性能計算對比
無服務器平臺通常具有某些資源限制，比如，功能不能超過512 MB的RAM，不能超過5分鐘。如果這些限制對應用程序來說過於嚴格，則需要使用Kubernetes。有時也會在較小的功能中分解應用程序，比如，將現有單片應用程序移到雲中。
結語
無服務器計算和Kubernetes對應不同的應用場景，也有着各自的缺點。如果是初學者，建議從無服務器計算開始，畢竟Kubernetes的配置過程相對繁瑣。如果是企業用戶，追求高性能計算、更優性能並希望運行大規模應用程序，Kubernetes依舊是最佳選擇。
參考鏈接：https://dzone.com/articles/when-to-use-serverless-when-to-use-kubernetes