Knative是FaaS的反模式嗎？

banq發表於2018-09-06
模式
Knative在7月份Google Next上釋出時，在部落格圈引發了一片譁然，然後Riff和Openwhisk採用了它實現自己的FaaS解決方案。從表面上看，它似乎是基於容器即服務（CaaS）解決方案的最佳實踐，但對於函式即服務（FaaS）解決方案，可以認為Knative事實上是一個FaaS反模式。

在Knative的描述中，它指出它自己是“......構建，部署和管理現代無伺服器工作負載”的方式，自Amazon Lambda推出以來，“無伺服器”一詞與FaaS相關聯，說到這一點，重要的是要意識到建立一個無伺服器程式或應用程式FaaS解決方案不是必須的，開發人員可以建立通常應用程式容器（例如使用NGINX），如果這些容器啟動足夠快並且可以在不受影響的情況下可暫停其操作，那麼從技術上講，基於Nginx的這些傳統方式也是可以實現無需基於FaaS的無伺服器架構。

在CaaS世界中，Knative可以被認為是在Kubernetes上執行自動縮放的正確方法，它解決了scale-to-zero情況，如果你想要正確自動縮放，則需要這樣做，它還插入了諸如服務網格（Istio）之類的重要元件，以及執行日誌記錄和跟蹤的能力。簡而言之，對於CaaS，它似乎是一種最佳實踐。

然而，談到FaaS，恰恰相反，首先，重要的是要意識到FaaS解決方案有不同的風格。其中兩個最重要的是：

1. FaaS解決方案是否有自己的排程器？
2. FaaS解決方案是否需要打包程式碼放入容器中？

這些問題的答案很重要，因為它從根本上改變了這些FaaS平臺的功能，例如，具有自己的排程程式的FaaS解決方案可以：

1. 支援冷/暖/熱 lambda池，從而獲得更好的效能和日程安排
2. 支援組合函式的流水線最佳化
3. 在Kubernetes以外的環境中執行

看看Amazon Lambda，Google Cloud Functions和Azure Functions等公共雲提供商，他們每個都使用自己單獨的排程程式，而且是不依賴於像Kubernetes這樣的外部排程器來進行排程的。

類似地，如何打包一個函式的問題很重要，因此不需要將程式碼打包到容器中有下面好處：

1. 可以快速迭代解決方案，而無需透過完整的CI / CD流程。（即，開發人員的工作效率不受影響）

2. 可以執行管道最佳化，例如在同一程式空間內以不同語言執行函式。

再次看看公共雲提供商的FaaS解決方案，如AWS Lambda，他們部署的腳手架不是容器。

如果你看一下公開採用Knative的FaaS解決方案，那就比較弱了，者或缺乏這些能力，作為獎勵，這些解決方案會獲得比以前更好的擴充套件解決方案，同時還新增了Istio支援和日誌記錄整合。

然而，需要在下面兩者之間權衡考慮：一個平臺是偏重提高開發人員生產力？還是側重提高應用程式的效能？

我們將再次強調......將程式碼打包到容器中應該被視為FaaS反模式！正確的方法是讓容器以像那些公共FaaS解決方案一樣，直接從腳手架中提取和執行程式碼。

Knative, a FaaS anti-pattern? – Galactic Fog – Med

[該貼被banq於2018-09-12 07:30修改過]

相關文章