《這不是我想要的Serverless》要點：
本文介紹了這不是我想要的Serverless，希望對您有用。如果有疑問，可以聯(lián)系我們。
最近,我們在Container Solution平臺上探討了serverless的適用面,更重要的是,我們討論了它可能的走向.之前玩過Lambda,我發(fā)現(xiàn)討論遠比實際執(zhí)行更加有趣,因為它始于我們想要的以及我們所得到的.
我拒絕接受由供應(yīng)商執(zhí)掌“serverless”發(fā)展軌跡的現(xiàn)狀,大家需要一個標(biāo)準(zhǔn).我有一個目標(biāo),一個基于個人想法的目標(biāo).最后一個純粹出于個人嗜好,接受它或是提出你的建議.
在AWS推出Lambda時,我認(rèn)為這將會造成業(yè)界的興奮以及許多情況下的困惑.我不太確定是否每個人都能理解它是如何工作的以及這是否會為大家?guī)韼椭?此后,Lambda證明了它是一款非常酷的工具,毫無疑問它能夠削減運維的開銷.它同樣助長了我們正在經(jīng)歷的serverless熱潮.
坦白說,我個人并不喜歡AWS,Azure和GCE對于serverless的描述.我喜歡這些供應(yīng)商,我認(rèn)為它們的平臺是令人嘆為觀止的,但我是一個發(fā)自內(nèi)心的純粹主義者.我認(rèn)為要落實serverless,必須為其開發(fā)一個開放標(biāo)準(zhǔn).
我也認(rèn)為這些供應(yīng)商正在尋求能夠滿足顧客需求的最廉價的解決方案.但這通常并不會成為最佳解決方案.
開發(fā)標(biāo)準(zhǔn)會拉近大家距離,讓大家說同樣的術(shù)語,使工具更具兼容性,這一切完全說得通.
當(dāng)前的FaaS(Function as a Service)根本沒有做到這些.它們都在其生態(tài)中提供了框架,你只需要在此完成工作.
我們需要一個開放標(biāo)準(zhǔn),但是它應(yīng)該是怎樣的呢?好吧,首先,我們需要建立關(guān)于其如何工作的基本準(zhǔn)則.
在現(xiàn)有的產(chǎn)品中,上述內(nèi)容得不到任何保證.我需要想象一個擁有上述一切的世界.
因此我需要從未來借調(diào)一些內(nèi)容,并且在最后我會帶大家回到過去.
容器是我們將會在Serverless系統(tǒng)中嘗試,并用以實現(xiàn)安全性和速度的技術(shù).當(dāng)我們談及容器,大多數(shù)人馬上就會想到Docker.Docker其實并不能很好地適配Serverless功能,它慢、臃腫且需要一個守護進程.這并不是在挖苦Docker,但他確實并不算是Serverless的一個好選擇.畢竟我們需要一把外科手術(shù)刀,而Docker是一把瑞士軍刀.Docker和Rkt均非容器,它們只是用來促進容器化的工具罷了.
這并不意味著我們無法開發(fā)一個工具以使我們的工具容器化,使之得以在數(shù)毫秒內(nèi)啟動,并使所有的功能遵循相同的隔離.
或許unikernel才是答案,而非容器,或許僅需一臺經(jīng)過調(diào)整的Linux服務(wù)器,使其高效地隔離每個進程,不賦予它們文件訪問權(quán),僅允許向外的TCP連接.
在這個議題上,我想我會讓我的同事不厭其煩,但是至少就使用標(biāo)準(zhǔn)輸入和輸出而言,我成為了一名堅定的信徒.自使用諸如AWS KCL之類的工具之初,我便震驚了,它們提供了一個守護進程,并使用其包裝你的進程,如此你便可以在任意語言中提取Kinesis消息了.我便在Lambda上使用NodeJS的包裝器包裝了我的第一個Go程序.我們可以用不同的語言,使用不同的協(xié)議進行通訊,但是STDIN/STDOUT則是普適的.
Serverless方法的理念就是生成、執(zhí)行和銷毀,對我而言,這是一種獲取數(shù)據(jù)的好規(guī)范.
如果你深究云供應(yīng)商的FaaS實現(xiàn),你會發(fā)現(xiàn)它們僅提供2個變量.其一是“event”,它們不關(guān)心內(nèi)部有什么.其二便是“context”,它將請求置于上下文中.與可執(zhí)行程序中通過STDIN發(fā)送標(biāo)記和環(huán)境變量相比,這并沒有什么不同.
考慮更加簡單的STDIN/STDOUT確實給了我們很大的自由.它允許我們的方法是語言無關(guān)的,并且通過Linux強大的管道命令,我們便可構(gòu)建非常健壯的功能鏈了.
JSON看起來像是一個事實上的標(biāo)準(zhǔn),使大家回到通信,但是在云的世界里,我認(rèn)為需要更進一步.且在道別前花點時間.
當(dāng)前市場中,我認(rèn)為存在2種相對理想的格式,Cap’n Proto和Protobuf.前者允許快速傳送大量數(shù)據(jù),后者則允許向現(xiàn)存載荷拼接數(shù)據(jù).從目前來看,我無法確定哪一個才是更加理想的選擇,抑或是可能會出現(xiàn)更加優(yōu)秀的方案.但有一點我很清楚,如果我們建立了進程間共享數(shù)據(jù)的標(biāo)準(zhǔn),那么完全可以在之后構(gòu)建可替換的部分(標(biāo)準(zhǔn)).
我并不認(rèn)為我們當(dāng)前擁有的“Serverless”基礎(chǔ)設(shè)施,就是我們想要的供應(yīng)商無關(guān)的那種.盡管我們擁有能夠很好工作的工具,但是它們僅為服務(wù)提供商的利益而工作,這完全能夠理解,然而常止于進一步的開發(fā)工作無法為它們帶來利潤時.是時候開始考慮一個開放的框架了,這使我們能夠開發(fā)強大而開放的工具.如果我們可以開發(fā)一個符合開放標(biāo)準(zhǔn)的平臺,那么第三方服務(wù)就可以圍繞我們的標(biāo)準(zhǔn)開發(fā)工具.標(biāo)準(zhǔn)開發(fā)的目的并不在于鎖定供應(yīng)商或為迎合你的最高消費顧客.
這是一個正在進行中的思想性項目,我期望收到建議.下一篇文章和一個假想的系統(tǒng)相關(guān),它能夠?qū)崿F(xiàn)理想的serverless生態(tài)系統(tǒng).
文章來自：DockOne社區(qū)-孫科(譯)
原文鏈接：http://container-solutions.com/not-serverless-ordered/
轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/3758.html
