并沒有所謂的“無(wú)服務(wù)器”計(jì)算，因?yàn)橛?jì)算資源總是要在某個(gè)地方運(yùn)行。這個(gè)術(shù)語(yǔ)源于用戶必須擺脫對(duì)實(shí)際服務(wù)器和基礎(chǔ)設(shè)施的管理。我們現(xiàn)在看到的是對(duì)“無(wú)容器”計(jì)算的需求——在這種計(jì)算中，應(yīng)用程序開發(fā)人員可以專注于要提供的服務(wù)，而不是創(chuàng)建和編排這些服務(wù)的基礎(chǔ)設(shè)施。
當(dāng)然，事情并不總是這樣。自Fortran和COBOL時(shí)代，我們被迫從數(shù)據(jù)庫(kù)開始，以單體的方式思考應(yīng)用程序，并朝著前端前進(jìn)?，F(xiàn)在情況不同了；開發(fā)人員越年輕，就越有可能從一開始就學(xué)習(xí)面向?qū)ο缶幊?，這使得他們更容易適應(yīng)微服務(wù)的思維方式。
這是一種調(diào)整。
為什么要將應(yīng)用程序分解為服務(wù)？
這是一個(gè)必要的調(diào)整，因?yàn)闉榱藙?chuàng)建真正現(xiàn)代化的云原生應(yīng)用程序，我們需要以一種方便、容錯(cuò)的方式將特定的功能進(jìn)行容器化和編排。這意味著按功能、按運(yùn)維、甚至按組織單位將整個(gè)最終目標(biāo)分解為單個(gè)服務(wù)。
在過去，我們編寫這些功能，將它們包含在庫(kù)中，然后導(dǎo)入到應(yīng)用程序中。在這方面，這并不是一個(gè)很大的轉(zhuǎn)變。這些庫(kù)現(xiàn)在基本上是存儲(chǔ)在諸如Docker Hub這樣的存儲(chǔ)庫(kù)中的容器鏡像，可以根據(jù)需要進(jìn)行拆分。
但這又如何引導(dǎo)我們走向“無(wú)容器”架構(gòu)的呢？
這樣想吧。我們習(xí)慣于將無(wú)服務(wù)器計(jì)算與Kubernetes等編排容器的技術(shù)分離開來(lái)。兩者的區(qū)別在于（理論上）當(dāng)一個(gè)函數(shù)不在無(wú)服務(wù)器環(huán)境中使用時(shí)，它就不存在，也不使用資源或花費(fèi)金錢；而在Kubernetes環(huán)境中，你可以將資源縮減到單個(gè)容器，但那個(gè)容器仍在運(yùn)行（而且要花錢），即使它沒有被使用。
其實(shí)不需要這樣。在Kubernetes上已經(jīng)有了啟用無(wú)服務(wù)器計(jì)算的方法。但是，如果我們能夠創(chuàng)建一個(gè)環(huán)境，在這個(gè)環(huán)境中我們可以獲得Kubernetes的優(yōu)勢(shì)，而不必麻煩用戶了解如何使其工作的細(xì)節(jié)，那會(huì)怎么樣呢？
假設(shè)你作為一名開發(fā)人員正在創(chuàng)建一個(gè)應(yīng)用程序來(lái)流式傳輸和分析視頻。在這個(gè)過程中的某個(gè)時(shí)刻，你必須對(duì)數(shù)據(jù)進(jìn)行編碼。在分解應(yīng)用程序時(shí)，你已經(jīng)確定這是一個(gè)單獨(dú)的服務(wù)，因此你創(chuàng)建了一個(gè)容器，該容器將接收原始數(shù)據(jù)作為請(qǐng)求并返回編碼的版本。現(xiàn)在怎么辦？
假設(shè)你可以將該容器添加到安全注冊(cè)表中（這樣只有你的組織才能使用它），并且當(dāng)應(yīng)用程序需要編碼數(shù)據(jù)時(shí)，服務(wù)就在那里。你不必?fù)?dān)心是否有可用的服務(wù)器、可擴(kuò)展性、網(wǎng)絡(luò)或任何相關(guān)內(nèi)容。在某些方面，這就是無(wú)服務(wù)器計(jì)算的定義。但是，作為一種實(shí)踐，無(wú)服務(wù)器有一個(gè)缺點(diǎn)：它沒有標(biāo)準(zhǔn)化，使我們回到了供應(yīng)商鎖定狀態(tài)。
Kubernetes標(biāo)準(zhǔn)化
如果在Kubernetes上被標(biāo)準(zhǔn)化了呢？那就能夠避免供應(yīng)商鎖定，使用現(xiàn)有的技能，并輕松創(chuàng)建多集群應(yīng)用程序。我們甚至可以創(chuàng)建一個(gè)環(huán)境，其中一些資源是共享的，另一些是私有的——這取決于開發(fā)人員的需求。我們還可以使用Istio等服務(wù)網(wǎng)格技術(shù)來(lái)管理和分段網(wǎng)絡(luò)流量。
事實(shí)上，我們可以更進(jìn)一步。如果我們可以為這些容器的供應(yīng)添加智能呢？如果一個(gè)神經(jīng)網(wǎng)絡(luò)或其他機(jī)器學(xué)習(xí)算法可以預(yù)測(cè)何時(shí)可能需要不同的容器，并提前將它們運(yùn)轉(zhuǎn)起來(lái)呢？該算法不僅可以擴(kuò)展容器，還可以擴(kuò)展基礎(chǔ)設(shè)施本身——在最大限度地提高性能的同時(shí)，最小化維護(hù)基礎(chǔ)設(shè)施的成本。
所有這些都可以在可信計(jì)算的上下文中運(yùn)行，其中的鏡像存儲(chǔ)在可信注冊(cè)表中，并且只能在已通過可信平臺(tái)模塊（TPMs）等技術(shù)驗(yàn)證的服務(wù)器和設(shè)備上實(shí)例化。這使分布式計(jì)算成為可能，同時(shí)降低了安全風(fēng)險(xiǎn)。
變得復(fù)雜的地方
當(dāng)然，不是說(shuō)毫無(wú)挑戰(zhàn)。這種新思維方式的另一個(gè)重要方面是標(biāo)準(zhǔn)化和安全性。我們現(xiàn)在需要將其規(guī)劃到架構(gòu)中，既包括內(nèi)部運(yùn)行的內(nèi)容，也包括外部運(yùn)行的內(nèi)容，這樣執(zhí)行中的應(yīng)用程序就不會(huì)受到攻擊。在這些領(lǐng)域，企業(yè)必須投入大量資金，以實(shí)現(xiàn)所需的技術(shù)進(jìn)步。例如，為了實(shí)現(xiàn)今天所需的靈活性，我們常常不得不以根用戶的身份運(yùn)行容器；這絕對(duì)不是一個(gè)長(zhǎng)期的解決方案。我們需要一個(gè)共同的權(quán)威模式，這意味著每個(gè)人都必須就該方法的工作方式達(dá)成一致。業(yè)界需要定義權(quán)限，以及可信計(jì)算如何在所有這些類型的基礎(chǔ)設(shè)施（如容器、VM和裸機(jī)）中協(xié)調(diào)工作。
然而，有一點(diǎn)與目前的情況保持一致，那就是圍繞這些技術(shù)進(jìn)步形成的新業(yè)務(wù)最終將把所有東西——容器、編排、網(wǎng)絡(luò)，甚至硬件——都當(dāng)作代碼。所有新的自動(dòng)化方法都必須是自我修復(fù)、自我擴(kuò)展、自我配置，甚至跨應(yīng)用程序進(jìn)行自我自動(dòng)化。例如，神經(jīng)網(wǎng)絡(luò)需要能夠在必要時(shí)擴(kuò)展，預(yù)測(cè)需要，并根據(jù)需要改進(jìn)其模型（和精度）。
更重要的是，整個(gè)技術(shù)進(jìn)步網(wǎng)絡(luò)需要能夠在不中斷服務(wù)的情況下進(jìn)行升級(jí)和更新，這意味著除了軟件開發(fā)供應(yīng)商之外，所有硬件供應(yīng)商都需要參與其中。
原文鏈接：
https://thenewstack.io/containerless-computing-the-ultimate-service-decomposition/
