為什么我會被Kubernetes“洗腦”？
Kubernetes 已在容器編排之戰中取勝，未來很可能會成為“多云”之上的標準層，進而為分布式系統的分發和運行帶來根本性的改變，而其自身則會慢慢變得像 Linux Kernel 一樣，成為一種系統底層的支撐，不再引人注目。
本文金句：
- 通過 Kubernetes，分布式系統工具將擁有網絡效應。每當人們為 Kubernetes 制作出的新的工具，都會讓所有其他工具更完善。因此，這進一步鞏固了 Kubernetes 的標準地位。
- 云提供商并非可替換的商品。不同的云提供的服務會變得越來越獨特和不同。如果可以訪問不同的云提供商提供的不同服務，那么企業將因此受益。
- 當多節點應用與單節點應用一樣可靠時，我們將看到定價模型的變化。
- 這就是為什么我會被 Kubernetes 洗腦的原因，它是跨越異構系統的一個標準層。
- 將來，我們會像討論編譯器和操作系統內核一樣討論 Kubernetes。 Kubernetes 將會是低層級的管路系統，而不在普通應用開發人員的視野之內。
Kubernetes 已成為部署分布式應用的標準方式。在不遠的將來，任何新成立的互聯網公司都將用到 Kubernetes，無論其是否意識到這點。許多舊應用也正在遷移到 Kubernetes。
在 Kubernetes 之前，特定的分布式系統平臺還沒有一個標準。正如 Linux 是針對單個節點的標準的服務器側操作系統那樣，Kubernetes 已成為編排應用節點的標準方式。
通過 Kubernetes，分布式系統工具將擁有網絡效應。每當人們為 Kubernetes 制作出新的工具，都會讓所有其他工具更完善。因此，這進一步鞏固了 Kubernetes 的標準地位。
谷歌、微軟、亞馬遜和 IBM 都有自己的 Kubernetes 即服務產品，這讓我們在大型云提供商之間切換基礎設施變得更加簡單。
我們將很有可能看到 Digital Ocean、Heroku 和其他長尾型云提供商開始提供受管理的和托管 Kubernetes 服務。
在這邊文章中，我將探討以下問題：
- 為什么正在發生這種情況？
- 對于開發者來說這意味著什么?
- 云提供商將受到什么影響？
- 在 Kubernetes 標準化的世界中，有哪些新的業務模型將會出現？
軟件標準
標準化的軟件平臺有利有弊。
標準讓開發者可以對軟件的運行方式抱有一定的預期。如果一個開發者為某個標準化平臺構建了某個產品，他可以評估出該軟件的目標市場總規模。
如果你用 JavaScript 寫了一個程序，你會知道它將會在所有人的瀏覽器中運行。如果你給 iOS 創作了一個游戲，你會知道每個有 iPhone 的人都可以下載它。
如果你構建了一個工具來分析 .NET 中的垃圾收集，你會知道大量的 Windows 開發者會遇到內存問題，所以他們會購買你的軟件。
標準化的專有平臺可以給平臺提供者創造大量的利潤。1995 年，Windows 這個很好的平臺讓微軟能夠以 100 美元的價格售出一個只是紙盒子裝著的光盤。
2018 年，iPhone 這個很好的平臺讓蘋果能夠從平臺所有的應用銷售額中拿走 30%。
但是專有的標準會導致分裂。
比如，你的 iPhone 應用無法在 Kindle Fire 上運行。我不能在 Facebook Messenger（臉書信使）上使用你的 Snapchat 增強現實貼紙。
我最喜歡的數字音頻工作站[1]只能在 Windows 上使用，所以我不得不使用 Windows 電腦來制作音樂。
當開發者們見到這種分裂時，他們會抱怨。他們會聯想到貪婪的資本家，這些資本家為了賺錢，不惜犧牲軟件的質量。
開發者們會想：“為什么人們不能和諧共處？”為什么我們不能讓所有東西開放和免費？開發者們還會想：“我們不需要專有標準。我們可以擁有開放標準。”
Apache 的增長，Apache 是 LAMP (Linux、 Apache、MySQL 和 PHP)堆棧的一部分，Linux 就曾發生過這樣的事。
現在，大多數新的服務側應用都在使用 Linux。但曾經有一段時間，人們對此有爭議。見上圖的左側遠端部分。
最近，我們還看到了一個更新的開放標準：Docker。Docker 給了我們一個開放、標準化的打包、部署和分布單個節點的方法。
這極其有價值！但在 Docker 解決的所有大問題之中，有個新的問題非常突出，那就是我們應該如何將這些節點編排到一起？
畢竟，你的應用肯定不只是單個節點。你知道自己希望部署一個 Docker 容器，但是容器應該如何相互通信呢？你如何向上擴展容器實例呢？你如何在容器實例之間路由流量呢?
容器編排
在 Docker 流行之后，一大批開源項目和專有平臺紛紛出現，以解決容器編排的問題。
Mesos、Docker Swarm 和 Kubernetes 均提供了不同的抽象來管理容器。Amazon ECS 提供了一個專有的受管的服務，它可以為 AWS 用戶提供 Docker 容器的安裝和擴展服務。
有些開發者并未采用任何編排平臺，而是使用 BASH、Puppet、Chef 和其他工具來為他們的部署編寫腳本。
無論一個開發者是否使用編排平臺或者腳本來部署容器，Docker 都可以加快開發，并且讓開發者和運營之間更加和諧。
隨著愈來愈多的開發者使用 Docker 來部署容器，編排平臺的重要性日益突出。容器對于分布式系統的重要性就如同對象對于面向對象程序的重要性那樣[2]。
所有人都希望使用容器平臺，但是眾多平臺之間存在著競爭，很難看出哪個平臺會最終勝出，所以這可能會是持續十多年的競爭，就如 iOS 和安卓的競爭那樣。
這樣的競爭正在制造分裂。這并不是因為流行的編排框架是專有的（Swarm、Kubernetes 和 Mesos 都是開源的），而是因為每個容器編排社區都已經在自己的系統上投入了太多資金。
所以，從 2013 到 2016 年，Docker 用戶一直有種隱憂。選擇容器編排框架就像一次豪賭，如果你選擇了錯誤的編排系統，這就好像你開了一家影像店，卻選擇了高清 DVD，而不是藍光光碟[3]。
集裝箱（container）船傾覆的圖片從不過時。
正如在所有戰爭中那樣，總是有一層霧，讓我們很難看透彼此。在我報道容器編排之戰時，我曾用一條條播客記錄我和容器編排專家的談話，其中，我會問到這樣的問題，”那么，哪一個容器編排系統會贏？“
我一直這么做，直到某個我十分景仰之人告訴我問這樣的問題一點也沒有意思，還不如評估一下不同編排商之間的技術權衡。
回首過去，我后悔自己被不同容器編排商之間的戰爭的故事所吸引。
當有關容器編排商的辯論如火如荼時，甚至是我這樣的記者也被這樣的情緒激發，并且認為這將是一場與派系斗爭有關的故事時，那些最聰明的人大多數卻正在進行著平靜和科學的談論。
容器編排之戰并非是一場派系斗爭，而更多的是觀點和開發者工程學之間的差異。
好吧，或許容器編排之戰并不只是觀點之間的差異。因為這個領域將會創造大量財富。我們現在談論的是與數十億市值的老組織如銀行、電信公司和保險公司之間的合同，這些組織正在逐步向云遷移。
如果你正在幫助電信公司遷移到正確的平臺，那么你的業務會很好。但如果你擁護了錯誤的平臺，最終你只會得到一倉庫的高清 DVD。
沖突最嚴重的時間大約是 2016 年底，那時有關于 Docker 可能出現分歧的傳言，原因是因為 Docker 公司想改變 Docker 標準，以更好地適配其容器編排系統 Docker Swarm[4]。但即使在那時，做一個樂觀者仍然是明智的。
具有毀滅性的創新會帶來痛苦，但它是一個進步的標志。在爭取容器編排統治地位的斗爭中，出現了許許多多的毀滅性創新。
但在 2016 底迷霧消散之后，Kubernetes 成了明顯的獲勝者。
今天，隨著 Kubernetes 成為保險的選擇，CIO 們對在企業中采用容器編排感到更安全了，這也讓廠商更愿意投入到 Kubernetes 專用的工具中，并且把這些工具銷售給這些 CIO。
讓我們來看看現狀：
- 開源開發者正在朝同樣的方向前進，并且為他們能構建的東西感到興奮。
- 大公司（無論是新還是老）都在逐漸采用 Kubernetes。
- 大型云提供商也準備好迎接低成本的 Kubernetes 即服務。
- 監控、日志記錄、安全和合規軟件廠商也極為激動，因為他們能更加容易地預測自己要集成的底層軟件堆棧了。
走向多云化
今天，盈利最多的專有后端開發者基礎設施提供商就是亞馬遜 AWS 云服務。開發者并不憎恨 AWS，因為 AWS 是創新和具備使能性的，并且便宜。如果你在 AWS 花了很多錢，那說明你的生意很好。
通過 AWS，開發者不會感到 90 年代時的主導專有平臺所給人的那種被鎖定的感覺。
但仍然有一些鎖定感。一旦你深深地扎根于 AWS 的生態系統中，并使用如 DynamoDB、Amazon Elastic Container Service（彈性容器服務）、或 Amazon Kinesis 服務時，你會發現你很難再脫離亞馬遜。
然而，由于 Kubernetes 為基礎設施創造的是一個開放、共有的層，所以理論上，將你的 Kubernetes 集群從一個云提供商處”遷移到“另一個提供商那里是可行的。
如果你決定遷移你的應用，你需要重寫應用的部分組件來停止使用亞馬遜特定的服務（如亞馬遜 S3）。
例如，如果你想要一個可以在任何云上運行的 S3 替代品，你可以配置一個帶 Rook[5] 的 Kubernetes 集群，并使用與你在 S3 上使用的相同 API 來存儲對象到 Rook 上。
這是一個很好的選項，但是我還從未聽說過誰真正地將他們的應用從云中遷走，除了 Dropbox[6] 之外，但他們的遷移是如此宏大，以至于耗費了 2 年半的時間[7]。
當然，除了 Dropbox 之外，肯定還有其他人也在亞馬遜 S3 上投入了很多錢，雖然他們也想創造自己的對象存儲，但是遷移會非常費力。
（Kubernetes 可以被用于遷移應用，但更可能會用于在不同的云之中提供相似的操作層）
在不遠的將來，Kubernetes 或許不會成為一個廣泛用于應用遷移的工具。更可能的情況是 Kubernetes 將會成為一個無所不在的控制平面，企業可以在多個云上使用它。
NodeJS 便是一個有用的類比。為什么人們喜歡 NodeJS 的服務器側應用？這并不一定是因為 NodeJS 是最快的 Web 服務器，而是因為人們喜歡在客戶端和服務器上使用相同的語言。
NodeJS 可以讓你在客戶端和服務器節點切換，而無需切換語言，同樣，Kubernetes 也能讓你在不同的云之間切換，而無需改變運營方式。
在每個云上，你都會有一些定制的應用代碼，它們由 Kubernetes 運行，并且與那個云提供的受管服務進行交互。
企業希望多云化，部分是因為容災的考慮，但還因為訪問不同云上的受管服務有實際的好處。
一個新出現的模式是將基礎設施分布于 AWS（用于用戶流量）和 Google Cloud（用于數據工程）上。Thumbtack[8] 公司正在使用此模式。
在 Thumbtack，位于 AWS 的生產基礎設施負責處理用戶請求。事務日志將從 AWS 推送到 Google Cloud，并在那里進行數據工程。
在 Google Cloud 上，事務記錄在 Cloud PubSub 中排隊。Cloud PubSub 是一個信息隊列服務。這些事務會從隊列里被抽出，并存儲在 BigQuery 中，BigQuery 是一個存儲和查詢大量數據的系統。
BigQuery 充當編排機器學習任務時的數據池，以便人們從中抽取數據。這些機器學習任務是在 Cloud Dataproc 中運行的，Cloud Dataproc 是一個運行 Apache Spark 的服務。
在 Google Cloud 上訓練好一個模型之后，這個模型會被部署到 AWS 側，然后處理用戶流量。在 Google Cloud 側，這些不同的受管服務的編排是由Apache Airflow完成的。
Apache Airflow 是一個開源工具。Thumbtack 在 Google Cloud 上管理自己時，需要 Apache Airflow。
今天，Thumbtack 用 AWS 來處理用戶請求，并用 Google Cloud 來進行 PubSub 中的數據工程和排隊。Thumbtack 在谷歌中訓練其機器學習模型，并將它們部署到 AWS 中。
這就是今天我們常見的現象。Thumbtack 最終或許還會將 Google Cloud 用于面向用戶的服務。
某家日本公司采用的多云化的數據工程流水線
越來越多的公司將逐漸遷移至多個云，而且它們當中的某些公司會在每個云上管理獨立的 Kubernetes 集群。
你可能在谷歌上有一個 GKE Kubernetes 集群來編排 BigQuery、Cloud PubSub 和 Google Cloud ML 之間的負載。
而且你可能會有一個 Amazon EKS 集群來編排 DynamoDB、 Amazon Aurora 和你的生產 NodeJS 應用之間的負載。
云提供商并非可替換的商品。不同的云提供的服務會變得越來越獨特和不同。如果可以訪問不同的云提供商提供的不同服務，那么企業將因此受益。
分布式系統分發
Google BigQuery 等 AWS Redshift 服務十分流行，因為它們給了你強大、可擴展和多節點的工具，而且 API 還簡單。開發者經常選擇這些受管服務，因為它們是如此好用。
針對單個節點的付費工具并不常見。我不需要給 NodeJS、React 或 Ruby on Rails 付費。
針對單個節點的工具比針對分布式系統的工具用起來更容易。相比于在我的筆記本上運行 Ruby on Rails 應用來說，在許多服務器上部署 Hadoop 難多了。然而，有了 Kubernetes 后，這一切都將改變。
如果你正在使用 Kubernetes，你可以使用一個名叫 Helm 的分布式系統包管理器。它就好比是用于 Kubernetes 應用的 npm。
如果你正在使用 Kubernetes，無論你使用的是哪個云提供商，你都可以用 Helm 來輕松安裝一個復雜的多節點應用。
下面是對 Helm 的描述：
Helm 幫助你管理 Kubernetes 應用。Helm Charts 幫助你定義、安裝和升級 Kubernetes 應用，無論它們有多復雜。Charts 很容易創建、進行版本控制、共享和發布，所以請開始使用 Helm 吧，停止復制-粘貼的瘋狂舉動。
一個用于分布式系統的包管理器。不可思議！讓我們看看我們能安裝的東西。
未列出的還有 WordPress、Jenkins 和 Kafka。
分布式系統配置很難，不信就去問問配置過 Kafka 集群的人。Helm 將使安裝 Kafka 像在你的 MacBook 上安裝新版 Photoshop 那樣簡單。 而且你可以在任何云上這么做。
在 Helm 之前，最接近分布式系統軟件包管理器（就我所知道的）的東西是 AWS[9] 或 Azure[10] 或 Google Cloud Launcher[11] 上的應用市場。
在這里，我們再次看到了專有軟件如何導致分裂。在 Helm 之前，沒有任何一個標準的、與平臺無關的一鍵安裝 Kafka 的方法。
你可以在 AWS、Google 或 Azure 上找到一鍵安裝 Kafka 的方法。 但是，這些安裝中的每個都必須獨立編寫，以供每個特定的云提供商使用。 而要在 Digital Ocean 上安裝 Kafka，則需要遵循這個 10 步教程[12]。
Helm 是一個在任何 Kubernetes 實例上分布多節點軟件的跨平臺系統。你可以在任何云提供商那里或你自己的硬件上使用已安裝有 Helm 的應用。
你可以輕松安裝 Apache Spark 或 Cassandra 系統。眾所周知，它們都是難以設置和操作的。
Helm 是 Kubernetes 的包管理器，但它看起來也像是 Kubernetes 應用商店的雛形。有了應用商店，你就可以出售用于 Kubernetes 的軟件。
你可以賣什么樣的軟件？
你可以銷售 Cloudera Hadoop，Databricks Spark 和 Confluent Kafka 等分布式系統平臺的企業版。 或者難以安裝的 Prometheus 等新型監控系統和 Cassandra 等多節點數據庫。
也許你甚至可以銷售像 Zendesk 這樣的更高級的消費級軟件。
自主托管 Zendesk 的想法聽起來很瘋狂，但是有人的確可以構建它，并以專有二進制文件的形式出售，以固定費用而不是訂閱進行收費。
如果我向你出售價值 99 美元的 Zendesk-for-Kubernetes，并且你可以在 AWS 上的 Kubernetes 集群上輕松運行它，那么你將在工單軟件上節省大量支持費用。
企業經常運行自己的 WordPress 來管理公司的博客。 Zendesk 的軟件比 WordPress 更復雜嗎？ 我不這么認為，但比起管理自己的博客軟件，企業更害怕管理自己的 Help Desk 軟件。
我經營了一家非常小的公司，但我訂閱了很多不同的軟件即服務工具。包括一個昂貴的 WordPress 主機，一個用于廣告銷售的昂貴的 CRM 軟件，和用于通訊簡報的 MailChimp。
我支付這些服務是因為它們超級可靠和安全，而且它們也是復雜的多節點應用。我不想在自己的機房里運行它們。我也不想自己管理它們。當我的簡報發送失敗時，我不想自己排除技術故障。我不想運行太多的軟件[13]。
相比之下，我并不擔心我的單機軟件出錯。
我在單機軟件上的開銷往往要便宜得多，因為我不需要把它們作為服務購買。我用來寫音樂的軟件有一次性的固定成本。
Photoshop 有一次性固定成本。我支付電費來運行我的電腦，但除此之外，我不需要持續的資本支出才能運行 Photoshop。
當多節點應用與單節點應用一樣可靠時，我們將看到定價模型的變化。
也許有一天我可以購買 Zendesk-for-Kubernetes。Zendesk-for-Kubernetes 將會給我提供我需要的所有東西。
它將啟動一個電子郵件服務器，它會給我一個網絡前端來管理工單。 如果出現任何問題，我可以在需要支持時支付費用。
Zendesk 是一個非常棒的服務，但如果它有一個固定的定價模式，那將會更好。
Metaparticle
借助 Kubernetes，部署和管理分布式應用程序變得更加容易。借助 Helm，將這些應用程序分發給其他用戶變得更加容易。但是開發分布式系統還是相當困難的。
這是 Brendan Burns 最近所作的一篇 CloudNative Con / KubeCon 主題演講的焦點，那個演講的題目為“構建新工具、模式和范例來讓分布式系統開發更加大眾化的工作實在太難了[14]”。
Brendan 在發言中提出了一個名為 Metaparticle 的項目。Metaparticle 是云原生開發的標準庫，其目標是實現分布式系統的大眾化。Brendan 在對 Metaparticle 的介紹[15]中寫道：
云原生開發是定制且復雜的，而且僅限于少數專家開發人員。Metaparticle 通過在熟悉的編程語言中引入一系列實用程序來改變這種狀況，這些實用程序符合開發人員當前的處境，并使他們能夠使用熟悉的語言開始開發云原生系統。
Metaparticle 建立在 Kubernetes 原語的基礎上，而且它使分布式協調更容易。Metaparticle 提供獨立于語言的模塊，用于鎖定和主選舉，并把這些模塊作為熟悉的編程語言中易于使用的抽象。
經過幾十年的分布式系統研究和應用，我們如何構建這些系統的模式已經顯現。我們需要一種方法來鎖定一個變量，這樣兩個節點便不能以非確定性的方式寫入該變量。
我們需要一種方法來做主選舉，以便在主節點死亡時，其他節點可以選擇一個新節點來編排系統。
今天，我們使用 etcd 和 Zookeeper 這樣的工具來幫助我們進行主選舉和鎖定，而這些工具都有接入成本。
Brendan 用 Zookeeper 的例子來說明這一點。Hadoop 和 Kafka 都使用 Zookeeper 來做主選舉。
你需要花費大量的時間和精力來學習如何操作 Zookeeper。在構建 Hadoop 和 Kafka 的過程中，這些項目的創始工程師設計的系統可以與 Zookeeper 協作，共同來維護一個主節點。
如果我正在編寫一個系統來執行分布式 MapReduce，我希望不考慮節點故障和競爭條件。Brendan 的想法是將這些問題推到一個標準的庫中，從而讓下一個開發人員為多節點應用程序提出新想法更加容易。
重要的元點：使用 Metaparticle 的前提是使用 Kubernetes。Metaparticle 是一個語言層級的抽象，它是建立在對底層（分布式）操作系統的假設之上的。這再一次使我們回到了標準這一話題。
如果每個人都在同一個分布式操作系統上，我們可以對我們項目的下游用戶做出更大的假設。
這就是為什么我會被 Kubernetes 洗腦的原因。 它是跨越異構系統的一個標準層。
無服務器工作負載
功能即服務（通常稱為“無服務器”功能）是一種功能強大且價格低廉的抽象，開發人員可以與 Kubernetes 一同使用它，在 Kubernetes 之上使用它，或者在某些情況下，單獨使用它。
讓我們快速回顧無服務器應用程序的現狀，然后考慮無服務器和Kubernetes之間的關系。
功能即服務的快速回顧[16]：
功能即服務是無需依賴特定服務器運行的可部署功能。
功能即服務旨在部署、執行和擴展開發人員的單個調用。在你調用無服務器功能之前，你的功能并沒有在任何地方運行，所以你并未使用任何資源，除了存儲原始代碼的數據庫以外。當你把一個功能作為服務調用時，你的集群將負責調度和運行該功能。
你不必考慮啟動一臺新機器并監控該機器，或者在機器閑置時停機。 你只需告訴集群你想要運行一個功能，然后集群將執行它并返回結果。
在部署無服務器功能時，功能代碼實際上并未被部署。你的代碼將以純文本形式保存于數據庫中。當你調用這個功能時，你的代碼將從數據庫入口中取出，加載到一個 Docker 容器中并執行。
AWS Lambda 在 2014 年開創了“功能即服務[17]”的理念。從那以后，開發人員一直在思考各種用例。
有關開發人員如何使用無服務器的完整列表，請參見 CNCF 無服務器工作組創建的共享 Google 文檔（本文發布時文檔為34頁）[18]。
從我在《軟件工程日報》上的交談中來看，這些作為服務的功能至少有兩個明顯的應用例子：
- 可以快速而廉價地進行擴展以應對突發性的工作負載的計算（例如，Yubl 的社交媒體可擴展性案例研究[19]）。
- 在多種工作負載頻度下的的事件驅動粘合代碼（例如，帶有多種數據庫消費者的事件溯源模型）。
為了創建一個功能即服務(FaaS)平臺，云提供商提供了一個名為調用者(invokers)的 Docker 容器集群。
這些調用者等待得到調配給他們的大塊代碼。當你要求你的代碼執行的時候，你必須等待一段時間用于將代碼加載到調用者并執行。 這個等待便是“冷啟動”的問題。
冷啟動問題是你決定在 FaaS 上運行部分應用時必須做的折衷之一。你不需為沒有進行任何工作的服務器的運行時間付費，但是當你想調用功能時，你必須等待代碼被調配給一個調用者。
在 AWS 上，會為 AWS Lambda 的請求指定調用者。在 Microsoft Azure 上，會為 Azure Functions 請求指定調用者。在 Google Cloud 上，會為 Google Cloud Functions 保留調用者。
對于大多數開發人員來說，使用 AWS、Microsoft、Google 或 IBM 的“功能即服務”平臺都可以。因為成本低，冷啟動問題對于大多數應用來說不成問題。但是一些開發者會想要更低的成本。
或者他們可能希望編寫自己的調度器，該調度器會定義如何將代碼調度到調用者容器上。這些開發人員可以推出自己的無服務器平臺。
像 Kubeless 這樣的開源 FaaS 項目可以讓你在 Kubernetes 之上配置你自己的無服務器集群。你可以定義自己的調用者池，你可以確定如何按照計劃調度容器，你可以決定如何解決你的集群的冷啟動問題。
Kubernetes 的開源 FaaS 只是一種資源調度器。它們只是 Kubernetes 之上的其他自定義調度器的預覽。開發人員總是在構建新的調度器，以便在這些調度器之上構建更高效的服務。
那么，在 Kubernetes 之上還有哪些其他類型的調度器？ 那么，正如他們所說，未來已經到來，但這些調度器只能作為一個 AWS 受管服務被提供。
AWS 有一項名為 Amazon Aurora Serverless 的新服務，它是一種自動擴展存儲和計算的數據庫。來自 Jeff Barr 關于 AWS Serverless Aurora 的帖子[20]：
當創建 Aurora 數據庫實例時，你可以選擇所需的實例大小，并可以選擇使用讀副本提高讀取吞吐量。
如果你的處理需求或查詢速率發生變化，你可以選擇修改實例大小或根據需要更改讀副本的數量。這個模型在工作負載可預測、并且請求速率和處理需求在一定范圍內的環境下運行得非常好。
在某些情況下，工作負載可能是間歇性的和/或不可預知的，并且可能每天或每周只能出現持續幾分鐘或幾小時的突發請求。
閃電銷售、不頻繁的或一次性的事件、在線游戲、報告工作負載（小時或每天），開發/測試和全新的應用都符合該條件。做出適當的容量規劃可能需要做很多工作；穩定地付費可能是不明智的。
由于存儲和處理是分開的，因此可以將規模一直縮小到零并僅支付存儲費用。
我覺得這真的很好，而且我期望它可以帶來新型的瞬時應用程序的出現。擴展只需要幾秒鐘，并基于一池子“熱”資源之上進行構建，這些資源急切地渴望滿足你的要求。
AWS 可以構建這樣的東西，我們并不感到驚訝，但是很難想象它會成為一個開源項目，直到 Kubernetes 出現。任何開發人員都可以在 Kubernetes 之上構建的這類系統。
如果你想在 Kubernetes 之上構建自己的無服務器數據庫，則需要解決一些調度問題。網絡、存儲、日志記錄、緩沖和緩存需要不同的資源層級。對于每個不同的資源層，你需要定義資源如何按照需求進行擴展和縮減。
就像 Kubeless 為功能代碼的一小部分提供調度器一樣，我們可能會看到其他自定義調度器被人們用作更大應用的構建塊。
一旦你真正建立你的無服務器數據庫，也許你可以把它賣到 Helm 應用程序商店，一次性購買它只需要 99 美元。
總結
我希望，通過一些 Kubernetes 的歷史和對未來的猜測，你能享受這次旅程。
2018 年已經開始，這些將是我們今年想要探索的一些領域：
- 人們如何管理在 Kubernetes 上機器學習模型的部署？ 我們和 Matt Zeiler 一起做了一個展示[21]，他討論了這個問題，聽起來很復雜。
- Kubernetes 是否用于無人駕駛汽車？ 如果是這樣，你是否部署了一個集群來管理整個汽車？
- Kubernetes 物聯網部署是什么樣的？ 在具有間歇性網絡連接的一組設備上運行 Kubernetes 是否有意義？
- 用 Kubernetes 構建的新的基礎設施產品和開發工具有哪些？ 什么是新的商業機會？
Kubernetes 是構建現代應用后端的絕佳工具，但它仍然只是一個工具。如果 Kubernetes 完成其使命，它最終會消失，成為背景。將來，我們會像討論編譯器和操作系統內核一樣討論 Kubernetes。
Kubernetes 將會是低層級的管路系統，而不在普通應用開發人員的視野之內。
參考地址：
[1] https://www.image-line.com/flstudio/
[2] https://youtu.be/gCQfFXSHSxw?t=611
[3] https://en.wikipedia.org/wiki/High-definition_optical_disc_format_war
[4] https://softwareengineeringdaily.com/2016/10/03/docker-fork-with-alex-williams-and-joab-jackson/
[5] https://rook.io
[6] https://softwareengineeringdaily.com/2016/05/17/dropboxs-magic-pocket-james-cowling/
[7] https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/
[8] https://softwareengineeringdaily.com/2017/11/28/thumbtack-infrastructure-with-nate-kupp/
[9] https://aws.amazon.com/marketplace
[10] https://aws.amazon.com/marketplace
[11] https://cloud.google.com/launcher/
[12] https://www.digitalocean.com/community/tutorials/how-to-install-apache-kafka-on-ubuntu-14-04
[13] https://softwareengineeringdaily.com/2017/11/20/run-less-software-with-rich-archbold/
[14] https://www.youtube.com/watch?v=gCQfFXSHSxw
[15] https://metaparticle.io/posts/welcome-to-metaparticle/
[16] https://www.softwaredaily.com/#/post/5a251d5f0cbcbe0004c932e1
[17] https://aws.amazon.com/cn/blogs/aws/run-code-cloud/
[18] https://docs.google.com/document/d/1UjW8bt5O8QBgQRILJVKZJej_IuNnxl20AJu9wA8wcdI/edit#heading=h.yiaul8is1ki
[19] https://softwareengineeringdaily.com/2017/08/04/serverless-startup-with-yan-cui/
[20] https://aws.amazon.com/cn/blogs/aws/in-the-works-amazon-aurora-serverless/
[21] https://softwareengineeringdaily.com/2017/05/10/convolutional-neural-networks-with-matt-zeiler/
