FONK 乙個面向K8S的無伺服器LAMP技術棧

關於無伺服器，有一種說法我聽過很多次：「無伺服器是一種自找麻煩的解決方案」。

當一項新技術破壞了人們習慣的工作流程時，就會出現類似的防禦性宣告。這種宣告也是在告訴無伺服器社群裡的所有人，無伺服器的學習曲線有多陡峭。

如果人們理解了無伺服器，他們就不會說出這麼負面的話。因此，我提出了乙個問題：如何馴服無伺服器的學習曲線？

我給出的答案是乙個web應用程式。讓我來解釋一下。

去年春天，我第四次聽到開頭那句話。所以我問自己，「你能用無伺服器構建的最簡單的東西是什麼？人們可以把它與自己已經知道的東西聯絡起來。」

我認為，我可以向人們展示他們可以如何做他們現在正在做的事情，只是以更簡單的方式，以此來展示無伺服器的價值。

因此，我構建了乙個web應用示例，稱之為guestbook。

就是每個人都知道的lamp技術棧。

它很簡單，並且提供了可選的元件，這可以說明它為什麼在過去20多年裡如此流行。我們甚至在kubernetes（k8s）的學習曲線中看到了它的影響：

guestbook是大多數人在第一次學習kubernetes時最先部署的應用程式之一，儘管它使用nosql伺服器代替了mysql，但仍然是基本的lamp結構。

有鑑於此，降低無伺服器學習曲線的一種方法是向人們展示如何用更少的**和配置構建同樣複雜的web應用程式。

使用aws構建，則該web應用程式如下所示：

雖然這只需要大約一半的**和配置，但它也把你鎖定在aws中。

如果你可以建立乙個類似lamp的設計模式，但使用k8s上的無伺服器概念來確保可移植性，那會怎麼樣？

aws體系結構的元件分別是函式即服務（faas）執行時、物件儲存和nosql伺服器。

如果你在任何超過3000 star的github專案或其他流行開源元件上使用了五個faas執行時之一，那麼整個技術棧就可以像下面這樣安裝在k8s上：

把它們都放在一起，就可以得到乙個簡潔的無伺服器設計模式縮寫：

（我把這個動物圖示歸功於我的女兒，她說：「fonk聽起來就像是鵝說的話。」）

為了讓人們更容易地從本地k8s過渡，這些web應用程式中的第乙個示例就是guestbook。以下是我們的早期進展：

只有create和list函式的guestbook是自然而然的第一選擇，不過，我們的計畫是讓這個應用程式變得更加複雜。我們希望新增待辦（完整crudl操作）、部落格（經過身份驗證的cud、公共rl）和論壇（經過身份驗證的crudl）。

更長遠來看，內建一些ci/cd功能，包括列測試自動化或跨行效能基準測試，這會很酷。

在構建第一組示例的過程中，我們學到了很多比較faas執行時的知識。

從開發人員體驗的角度來看，以下是一些早期研究結果：

基於k8s執行時上的某些faas開發，其體驗和本地k8s開發類似；它公開了函式將在其上執行的映象的一些內部結構。其他的則更接近於遮蔽了映象細節的aws lambda模型。

在這個領域，谷歌的knative是那只重達800磅的大猩猩，它在github上還沒有達到3000星的門檻，過了這個門檻，我們就提供guestbook示例。但是，我們正密切關注它的進展，因為它很可能會實現這一目標。

一旦開始實施這個想法，我們認為最好有乙個以它為中心的社群。所以，我們試著讓整件事成為成為一件有吸引力的事。

雖然並不是所有基於k8s執行時的faas都支援無伺服器框架，但是kubeless和openwhisk做得非常好。乙個簡單的入門方法是從頭到尾做乙個完整的示例：

我們很感激您的github之星，但是，我們更希望看到乙個新的faas執行時/語言組合pr。

你可以檢出我們在github上的fonk專案，自己嘗試一些例子。或者，你可以提出任何faas/語言組合請求，我們會構建所有可能的guestbook！

檢視英文原文：