但這種勢頭是有成本的，妳最好做好為此買單的準備。
最近，我寫了壹篇關於Kubernetes等雲原生平臺提供的“面向開發人員的新分布式原語”的文章，以及如何將這些原語與編程原語結合起來進行應用程序開發。例如，讓我們看看開發人員必須理解和使用多少Kubernetes概念才能有效地運行壹個容器化的應用程序:
請記住，該圖不包含任何DevOps團隊的Ops部門必須管理的支持Kubernetes對象。不需要額外的應用支持工具(用於日誌管理、監控、跟蹤、服務網格等)。)運營第二天之前。
開發人員可能必須編寫與容器中的應用程序代碼相同數量的YAML代碼。更重要的是，應用程序本身將依賴於比以往更多的平臺。雲原生應用期望平臺執行健康檢查、部署、放置、服務發現、運行周期性任務(cron作業)或調度原子工作單元(作業)、自動擴展、配置管理等。
所以妳的應用已經放棄了，把這些責任全部委托給平臺，期望以壹種可靠的方式來處理。事實上，現在您的應用程序和相關團隊在許多不同的層面上依賴於該平臺:代碼、設計、架構、開發實踐、部署和交付管道、支持流程、恢復方案，您可以命名它。
上圖顯示了在Kubernetes微服務的上下文中，您的代碼有多小。然而，當我們談論基於生產就緒的微服務系統時，這種情況還遠遠沒有完成。任何大型系統都需要集中監控、測量收集、跟蹤、服務網格、集成構建和部署工具、管道等工具。
這個平臺只是冰山壹角。為了在雲世界取得成功，妳需要成為壹個完全集成的工具，成為公司生態系統的壹部分。所以，賭註絕不是單壹的平臺、項目或者酷庫、公司。它是關於同步協同工作的整個項目生態系統，以及在未來十年左右合作並致力於該事業的公司(供應商和客戶)的整個生態系統。我認為這兩個方面同等重要:
技術:
考慮到向本地雲的過渡是壹個多年的旅程，只有長期的成功才能帶來好處。重要的是賭壹個未來5-10年有潛力的技術，而不是過去5年到10年的歷史。
文化:
雲原生是通過微服務、容器、持續交付和DevOps的組合實現的。而成為雲機器需要的不僅僅是給妳的應用增加幾個依賴/庫(不是在壹些會議上怎麽推廣)。妳可能不得不改變團隊結構和儀式、工作習慣和編碼實踐，並習慣於消耗仍然非常活躍的技術空間。如果妳的公司文化在某種程度上更接近開發或只使用雲原生平臺和相關工具的公司文化，那就更容易了。小事情，比如提出拉取請求和提交錯誤報告，檢查上遊源代碼和公開討論即將到來的新特性，而不是等待下壹次會議的消息，都可能影響團隊是否喜歡使用平臺。文化的壹致性和人為因素與技術優勢同樣重要。
以下內容並不代表壹個完整的環境，但我會嘗試對我想到的主要雲本地生態系統進行分組:
作為Apache軟件基礎的壹部分，Apache Mesos有它的優勢(成熟社區)和劣勢(動作慢)。它誕生於2009年左右，是壹個成熟的框架。它增加了對容器(我這裏指的是docker格式)和類似概念的支持，比如最近的Pods/Task group。
Cloud Foundry在2009年左右重生，是雲原生世界的開創者之壹。當Spring Cloud與Cloud Foundry壹起使用時，平臺與應用程序本身集成在壹起。服務發現、負載平衡、配置管理、重試、超時等功能都是在服務中執行的(在本例中是JVM)。這與Kubernetes等平臺采取的方法相反，在這些平臺中，所有這些職責都委托給平臺或其他支持容器(如envoy、linkerd、traefik)。我過去拿Kubernetes和春雲比較過。
盡管Docker Inc .(該公司)仍在研究它將開發和銷售什麽，但亞馬遜已經使用Docker技術創建了壹個非常可靠的產品，作為AWS彈性容器服務的壹部分。帶有Blox(用於AWS的開源容器編排軟件)的ECS本身可能沒什麽大不了的，但當與所有其他AWS產品結合使用時，它是壹個非常強大的集成平臺。
更不用說自虛擬機時代以來壹直是AWS支持者的網飛，正在向容器領域過渡，並正在推動亞馬遜ECS的創新。
Kubernetes是這壹類別中最新的平臺之壹，但它也是歷史上最活躍和發展最快的開源項目之壹。結合集成雲原生計算基礎項目和支持公司，整個生態系統已經成為該類別中非常強大的競爭對手。
作為後來者(2014)，Kuebernetes的優勢在於從壹開始就開發以容器為中心的架構。此外，它是基於10年前的谷歌博客，這意味著該原則(而不是實現)是成熟的，並在最高級別進行了測試。
從Sysdig最近的報告中可以看出，雲本地用戶似乎很欣賞這壹切。
也許妳在想，只要把妳的應用打包到壹個容器裏，就可以很容易地跨不同的雲原生平臺進行移植。妳錯了。無論妳是從Mesos、Cloud Foundry、Kubernetes、Docker Swarm、ECS開始，妳都必須投入巨資學習平臺和支持工具，了解文化和工作方法，並與這個仍在快速變化的生態系統互動。技術和公司。
本文的目的不是比較這些生態系統，而是展示它們的不同之處，證明如果有必要的話，導入壹個或者轉移到另壹個生態系統需要花費大量的時間和金錢。
雲原生態系統在技術、工藝、文化上非常獨特。但即使它們之間有壹些整合。壹個平臺推廣的很多概念也在向其他平臺傳播。比如Kubernetes中的Pod概念現在出現在Mesos中，在亞馬遜ECS中也是作為任務組存在的。服務器端負載均衡(Kubernetes中的服務)和帶策略的調度/放置(Kubernetes scheduler)的概念也存在於Docker Swarm、AWS ECS等中。但這就是它所走的路，從壹個生態系統過渡到另壹個生態系統需要付出很多努力。
那麽如何避免鎖定單壹供應商呢？壹種方法是堅持使用Kubernetes，並接受它作為雲和服務提供商之間的可移植層。Kubernetes如此受歡迎的壹個原因是，它不是壹個單壹公司的玩具，而是由許多大型科技公司支持的，如Google、OpenShift、Docker、Mesosphere、IBM、戴爾、思科等等。
另壹個原因是許多雲公司提供Kubernetes作為服務。如果妳使用Kubernetes，妳可以通過第三方服務提供商以最小的努力在Google Container Engine、Microsoft Azure、IBM Bluemix Container Service等雲提供商之間移動妳的應用，甚至在AWS上移動妳的應用。這意味著Kubernetes API是雲平臺之間應用程序的可移植層，而不僅僅是壹個容器。壹個容器本身就是壹滴原生海洋的雲。