這不是我想要的Serverless

05-03

【譯者的話】本文作者就serverless闡述了一些自己的想法，以及對標準的訴求。

最近，我們在Container Solution平台上探討了serverless的適用面，更重要的是，我們討論了它可能的走向。之前玩過Lambda，我發現討論遠比實際執行更加有趣，因為它始於我們想要的以及我們所得到的。

我拒絕接受由供應商執掌「serverless」發展軌跡的現狀，大家需要一個標準。我有一個目標，一個基於個人想法的目標。最後一個純粹出於個人嗜好，接受它或是提出你的建議。

供應商

在AWS推出Lambda時，我認為這將會造成業界的興奮以及許多情況下的困惑。我不太確定是否每個人都能理解它是如何工作的以及這是否會為大家帶來幫助。此後，Lambda證明了它是一款非常酷的工具，毫無疑問它能夠削減運維的開銷。它同樣助長了我們正在經歷的serverless熱潮。

坦白說，我個人並不喜歡AWS，Azure和GCE對於serverless的描述。我喜歡這些供應商，我認為它們的平台是令人嘆為觀止的，但我是一個發自內心的純粹主義者。我認為要落實serverless，必須為其開發一個開放標準。

我也認為這些供應商正在尋求能夠滿足顧客需求的最廉價的解決方案。但這通常並不會成為最佳解決方案。

開放標準

開發標準會拉近大家距離，讓大家說同樣的術語，使工具更具兼容性，這一切完全說得通。

當前的FaaS（Function as a Service）根本沒有做到這些。它們都在其生態中提供了框架，你只需要在此完成工作。

我們需要一個開放標準，但是它應該是怎樣的呢？好吧，首先，我們需要建立關於其如何工作的基本準則。

在支持多任務處理時，它必須是安全的
它需要足夠快
對於數據格式需要一致認同
它必須是語言無關的
它需要在任何地方運行

在現有的產品中，上述內容得不到任何保證。我需要想像一個擁有上述一切的世界。

未來

因此我需要從未來借調一些內容，並且在最後我會帶大家回到過去。

容器

容器是我們將會在Serverless系統中嘗試，並用以實現安全性和速度的技術。當我們談及容器，大多數人馬上就會想到Docker。Docker其實並不能很好地適配Serverless功能，它慢、臃腫且需要一個守護進程。這並不是在挖苦Docker，但他確實並不算是Serverless的一個好選擇。畢竟我們需要一把外科手術刀，而Docker是一把瑞士軍刀。Docker和Rkt均非容器，它們只是用來促進容器化的工具罷了。

這並不意味著我們無法開發一個工具以使我們的工具容器化，使之得以在數毫秒內啟動，並使所有的功能遵循相同的隔離。

或許unikernel才是答案，而非容器，或許僅需一台經過調整的Linux伺服器，使其高效地隔離每個進程，不賦予它們文件訪問權，僅允許向外的TCP連接。

STDIN/STDOUT

在這個議題上，我想我會讓我的同事不厭其煩，但是至少就使用標準輸入和輸出而言，我成為了一名堅定的信徒。自使用諸如AWS KCL之類的工具之初，我便震驚了，它們提供了一個守護進程，並使用其包裝你的進程，如此你便可以在任意語言中提取Kinesis消息了。我便在Lambda上使用NodeJS的包裝器包裝了我的第一個Go程序。我們可以用不同的語言，使用不同的協議進行通訊，但是STDIN/STDOUT則是普適的。

Serverless方法的理念就是生成、執行和銷毀，對我而言，這是一種獲取數據的好規範。

如果你深究雲供應商的FaaS實現，你會發現它們僅提供2個變數。其一是「event」，它們不關心內部有什麼。其二便是「context」，它將請求置於上下文中。與可執行程序中通過STDIN發送標記和環境變數相比，這並沒有什麼不同。

考慮更加簡單的STDIN/STDOUT確實給了我們很大的自由。它允許我們的方法是語言無關的，並且通過Linux強大的管道命令，我們便可構建非常健壯的功能鏈了。

數據格式

JSON看起來像是一個事實上的標準，使大家回到通信，但是在雲的世界裡，我認為需要更進一步。且在道別前花點時間。

當前市場中，我認為存在2種相對理想的格式，Capn Proto和Protobuf。前者允許快速傳送大量數據，後者則允許向現存載荷拼接數據。從目前來看，我無法確定哪一個才是更加理想的選擇，抑或是可能會出現更加優秀的方案。但有一點我很清楚，如果我們建立了進程間共享數據的標準，那麼完全可以在之後構建可替換的部分(標準)。

未完待續

我並不認為我們當前擁有的「Serverless」基礎設施，就是我們想要的供應商無關的那種。儘管我們擁有能夠很好工作的工具，但是它們僅為服務提供商的利益而工作，這完全能夠理解，然而常止於進一步的開發工作無法為它們帶來利潤時。是時候開始考慮一個開放的框架了，這使我們能夠開發強大而開放的工具。如果我們可以開發一個符合開放標準的平台，那麼第三方服務就可以圍繞我們的標準開發工具。標準開發的目的並不在於鎖定供應商或為迎合你的最高消費顧客。

這是一個正在進行中的思想性項目，我期望收到建議。下一篇文章和一個假想的系統相關，它能夠實現理想的serverless生態系統。

原文鏈接：This is not the Serverless I Ordered（翻譯：孫科）