'無服務器應用成主流零運維代碼運行付費'

"

原創: ZOL企業站 今天

"

原創: ZOL企業站 今天

無服務器應用成主流零運維代碼運行付費

第686期

無服務器應用成主流

零運維代碼運行付費

文 | 徐朋鳥 文字校對 | 徐朋鳥

審核 | 李諾 張劍鋒 策劃 | 劉克麗

無服務器應用經過5年發展火起來了,同時這也催開了開發人員的春天,將編好的代碼上傳到雲,無需配置或管理服務器即可運行代碼,按照所編好的被管理代碼計算時間付費。如果說DevOps(開發運維一體化)是協作的代表,那麼無服務器計算強調的則是零運維NoOps,同時在代碼執行即時付費。

無服務器正成主流

根據CNCF的一項數據,無服務器應用正呈現增長態勢,有38%的企業客戶在使用這種技術,較此前提升7%,其中32%的企業採用託管類無服務器平臺,6%的企業採用安裝類的無服務器平臺,另有26%的企業表示要在未來12-18個月內使用該技術。相比之下,採用有服務器技術的客戶比例減少了4%。

零運維背後是智能化

什麼是NoOps?當然不是完全放棄運維,而是要突出自動化運維,避免更多的人工干預,與無服務器計算的思路有著異曲同工之妙。既然無法擺脫“顯性”的基礎設施,乾脆就把應用程序從原有的框架中取出來。在一定程度上,算是改變了軟件的開發和部署模式,對於開發者來說最直觀的影響就是付費。事實上,隨著虛擬機轉向容器和微服務,這也為無服務器計算概念的推廣奠定了基礎,帶來了更加細分化的需求。

系統可以自編排代碼

原有整體交付的方式可以被拆分為單獨功能或代碼實現,即一段完整的業務流不僅能夠體現為一段視頻或一幅圖片,也可以是一行代碼,這些代碼形成的片段均可實現完整功能。藉助無服務器計算,系統能夠自行編排代碼片段。應用程序會直接在服務器上運行,幾乎所有的管理工作交由服務商來負責,使用者無需進行預置、擴展、維護等操作,即可運行數據庫、存儲或軟件程序。

函數即服務交付功能

通常理解,無服務器架構包括了FaaS(函數即服務)和BaaS(後端即服務),當然無服務器並不是真的放棄了服務器,只是說客戶不用再將過多的精力放在物理機上,對平臺的控制力和通用性都要有改進。這種概念在普及的過程中,以AWS為代表的Lambda起到了推動作用,由此也引伸出了FaaS的概念。與已有的體系結構有所區別,無服務器是運行在無狀態計算容器內部的,後者可短暫觸發事件並由第三方管理,比如AWS。

執行代碼即付費

函數即服務就是函數可以當作一個功能,開發者寫進配置文件後交給服務器即可運行,這個函數是封裝在容器中的,自定義輸入函數執行出結果,同時FaaS也不需要對特定框架或庫編碼。其好處是,編寫成本大幅降低了,開發者為執行代碼過程中消耗的資源付費就行了。對於業務來說,可以更關注業務本身,不用花費太多注意力在底層資源。

無需考慮選擇什麼容器

無論是虛擬機還是容器,都可以看作是通過代碼實現的方案,本質上與無服務器計算並不衝突。操作過程中,開發人員無需考慮選擇什麼容器,只要安心編寫代碼,由服務商將片段加以整合管理,節省了軟件創建時的付出,讓雙方做各自擅長的事情,效率更高。在彈性基礎架構中,開發者能夠將應用“切成”小塊通過高度擴展的方式部署。從某種程度上來說,無服務器計算為資源使用提供了新模式,其定位更像是介於IaaS和PaaS之間。

計費也有了另外途徑

計費方面,開發者不用像原來那樣為了數分鐘或數小時的應用實例支付整套費用,而是隻需支付某一段函數運行的幾毫秒,這種方式是更精準的按需付費。按照這個邏輯,無服務器計算平臺在雲端似乎更適用於由眾多微服務“拼接”而成的應用。無論是基礎設施管理還是應用構建,均節省了不少“無用功”。

5分鐘即完成萬種預測

舉個零售門店的例子,以往要想在五分鐘內對1萬個門店的1萬個商品進行預測,動用集群計算的成本會非常高,而Lambda每使用5GB內存的啟動價格大約是1美分/次。也就說,其背後把成本的壓力給到了亞馬遜,方案商則可以把算法集成到容器裡,並且做了大量的優化,讓整個預測過程在200-300秒內就能完成。

從大公司開始延伸

目前,涉足無服務器計算的不僅包括亞馬遜(AWS Lambda)、微軟(Azure Functions)、谷歌(Cloud Functions)、IBM(OpenWhisk)這樣的巨頭公司,還有Iron.io這樣的垂直公司。這些服務各有特色,例如OpenWhisk主打開源,Azure Functions結合了微軟IoT、SaaS方案,Iron.io則是希望構建主流公有云和私有云的全平臺兼容,確保高度可移植性。

結語

隨著無服務器應用零成本運維的春天也來了。

"

相關推薦

推薦中...