隨著大量新平臺和支持工具的出現，雲原生勢頭正在增長。 這些新平臺為開發人員提供了越來越多的功能，可以自動化方式快速開發，部署和管理大量微服務。
但這種勢頭伴隨著成本，你最好準備為此付出代價。
最近我寫了一篇由Kubernetes等雲原生平臺提供的“開發人員的新分佈式原語”，以及這些原語如何與用於應用程序開發的編程原語相結合。 例如，下面看看開發人員必須瞭解和使用多少Kubernetes概念才能有效地運行單個容器化應用程序：
A Kubernetes based Microservice
請記住，此圖表不包含DevOps團隊的Ops部門必須管理的任何支持Kubernetes對象。在第2天操作之前也不需要額外的應用程序支持工具（用於日誌管理，監視，跟蹤，服務網格等）。
可能的情況是，開發人員必須編寫與容器中的應用程序代碼相同數量的YAML代碼。更重要的是，應用程序本身將依賴於以前比以往更多的平臺。雲本機應用程序期望平臺執行運行狀況檢查，部署，放置，服務發現，運行定期任務（cron作業）或調度原子工作單元（作業），自動擴展，配置管理等。
因此，您的應用程序已放棄並將所有這些職責委託給平臺，並期望以可靠的方式處理它們。事實上，現在您的應用程序和相關團隊在很多不同的級別上依賴於平臺：代碼，設計，體系結構，開發實踐，部署和交付管道，支持過程，恢復方案，您可以為其命名。
投注生態系統，而不是平臺
上圖顯示了您的代碼在Kubernetes微服務的上下文中有多小。但是，當我們談論基於生產就緒的微服務系統時，這種情況遠未完成。任何規模龐大的系統都需要集中監控，度量收集，跟蹤，服務網格，集成構建和部署工具，管道等工具。
該平臺只是冰山一角，為了在雲原生世界取得成功，您需要成為完全集成的工具和公司生態系統的一部分。因此，賭注絕不是單一平臺，項目或酷圖書館或一家公司。它是關於同步協同工作的整個項目生態系統，以及在未來十年左右合作並致力於事業的公司（供應商和客戶）的整個生態系統。我認為這兩個方面同樣重要：
技術：
考慮到向雲本地過渡是一個多年的旅程，只有長期成功才能帶來好處，重要的是打賭一種具有未來5 - 10年潛力的技術，而不是從過去5到10年的歷史。
文化：
雲原生是通過微服務，容器，持續交付和DevOps的組合實現的。而成為雲本機需要的不僅僅是為您的應用程序添加少量依賴項/庫（而不是在某些會議中如何推廣它）。您可能不得不改變團隊結構和儀式，工作習慣和編碼實踐，並習慣於消耗仍然非常活躍的技術空間。如果您的公司文化在某種程度上更接近於開發或僅使用雲原生平臺和相關工具的公司的文化，那就更容易了。諸如提出拉取請求與提交錯誤報告，檢查上游源代碼以及為即將發佈的新功能公開討論而不是等到新聞的下一次會議通知之類的小事情可以對團隊是否喜歡使用平臺與否。文化一致性和人為因素與技術優勢同等重要。
以下內容並不代表完整的環境，但我將嘗試將我想到的主要雲本地生態系統分組：
Mesosphere和Apache Mesos
作為Apache Software Foundations的一部分，Apache Mesos具有其優點（成熟的社區）和缺點（緩慢移動）。它誕生於2009年左右，是一個成熟的框架，它增加了對容器的支持（我的意思是這裡的docker格式）和類似的概念，比如最近的Pods / Task組。
Cloud Foundry和Spring Cloud
Cloud Foundry再次誕生於2009年左右，是雲原生世界的先驅之一。當Spring Cloud與Cloud Foundry一起使用時，該平臺與應用程序本身融為一體。服務發現，負載平衡，配置管理，重試，超時等一些功能在服務中執行（在本例中為JVM）。這是Kubernetes等平臺所採取的相反方法，其中所有這些職責都委託給平臺或其他支持容器（例如envoy，linkerd，traefik）。我在過去比較了Kubernetes和Spring Cloud（通知不是Cloud Foundry）。
AWS ECS和Docker Swarm
雖然Docker，Inc。（該公司）仍在研究它將要開發什麼以及銷售什麼，但亞馬遜使用Docker技術作為AWS Elastic Container Services的一部分創建了一個非常可靠的產品。帶有Blox的ECS（AWS的開源容器編排軟件）本身可能不是什麼大事，但當與所有其他AWS產品結合使用時，它是一個功能非常強大的集成平臺。
更不用說從虛擬機時代起成為AWS支持者的Netflix正在向容器領域過渡，並正在推動Amazon ECS的創新。
CNCF和Kubernetes
Kubernetes是此類別中最新的平臺之一，但同時也是有史以來最活躍，發展最快的開源項目之一。與整合的雲原生計算基金會項目和支持公司相結合，使整個生態系統成為這一類別中非常有力的競爭者。
作為一個後來者（2014年），Kuebernetes的優勢在於從一開始就以容器為中心的架構發展。而且它基於一個已有十年曆史的谷歌博格，這意味著原則（不是實施）是成熟的，並在最高級別進行戰鬥測試。
Container Orchestrators in Sysdig’s 2017 Docker Us
正如您可以從Sysdig最近的報告中看到的結果，雲本地用戶似乎很欣賞這一切。
選擇哪一個？
也許您在想，只要您將應用程序打包到容器中，就可以輕鬆地跨不同的雲原生平臺移植。你錯了。無論您是從Mesos，Cloud Foundry，Kubernetes，Docker Swarm，ECS開始，您都必須進行大量投資，以學習平臺和支持工具，瞭解文化和工作方式，並與這個仍然快速變化的生態系統進行互動。技術和公司。
本文的目的不是要比較這些生態系統，而是要顯示它們之間的差異，並證明如果需要，它將需要大量的時間和金錢來輸入一個或轉移到另一個生態系統。
Kubernetes作為應用程序可移植層
雲原生態系統在技術，流程和文化方面非常獨特。但即便在他們之間也有一些整合。許多由一個平臺推廣的概念也在向其他平臺傳播。例如，部署單元（Pod in Kubernetes）的概念現在出現在Mesos中，它也作為任務組存在於Amazon ECS中。服務器端負載平衡（Kubernetes中的服務）和帶有策略的調度/放置（Kubernetes調度程序）的概念也存在於Docker Swarm，AWS ECS等中。但這是它走多遠，從一個生態系統過渡到另外，需要付出很多努力。
那麼如何避免與單一供應商鎖定？一種方法是堅持使用Kubernetes並接受它作為雲和服務提供商之間的可移植性層。 Kubernetes如此受歡迎的原因之一是因為它不是單一的公司玩具，而是由多家大型科技公司支持，如谷歌，紅帽（OpenShift），Docker，Mesosphere，IBM，戴爾，思科等等。
另一個原因是有許多雲公司提供Kubernetes作為服務。如果您使用Kubernetes，那麼您可以通過第三方服務提供商以最小的努力在Google容器引擎，Microsoft Azure，IBM Bluemix容器服務等雲提供商之間移動您的應用程序，甚至可以在AWS上移動您的應用程序。這意味著Kubernetes API是雲平臺之間應用程序的可移植性層，而不僅僅是容器。一個容器本身就是雲原生海洋的一滴。
閱讀更多 智能時刻 的文章
