雲原生可移植性的神話

ServiceMesher2018-11-12 03:32:09

作者:Bligin Ibryam 譯者:殷龍飛 原文地址:https://thenewstack.io/myth-cloud-native-portability/

本文最初發表於2017年5月24日。介紹了的可移植性,告誡讀者應該看重而不是某個具體

隨著大量新平臺和支持工具的出現,雲原生勢頭正在增長。 這些新平臺為開發人員提供了越來越多的功能 ,可以以自動化的方式快速開發,部署和管理大量微服務。

但這種雲原生的勢頭的增長同樣會伴隨著成本的增加,最好做好為此付出代價的準備。

最近我寫了一篇由Kubernetes等雲原生平臺提供的“為開發者準備的新的分佈式原語”,以及這些原語如何與開發的編程原語相結合。 例如,下面看看開發人員必須瞭解和使用多少 Kubernetes 概念才能有效地運行單個容器化應用程序:

請記住,此圖表不包含DevOps團隊的Ops部門必須管理的支持Kubernetes的對象。在操作之前也不需要額外的應用程序支持工具(用於日誌管理、監控、跟蹤、服務網格等)。

更有可能的是,開發人員必須編寫與容器中的應用程序代碼相同數量的YAML代碼。 更重要的是,應用程序本身將依賴於比以往更多的平臺。雲原生應用程序期望平臺執行運行狀況檢查、部署、放置、服務發現、運行定時任務( cron 作業)或調度原子工作單元(作業)、自動擴展、配置管理等。

因此,您的應用程序已放棄並將所有這些職責委託給平臺,並期望以可靠的方式處理它們。 事實上,現在您的應用程序和相關團隊在很多不同的級別上依賴於平臺:代碼、設計、體系結構、開發實踐、部署和交付管道、支持過程、恢復方案,你能想到的一切。

在生態系統上下注而不是在平臺上

上圖顯示了代碼在Kubernetes微服務環境中的小巧程度。 但是,當我們談論基於生產就緒的微服務系統時,這種情況遠未完成。 任何規模龐大的系統都需要集中監控、度量收集、跟蹤、服務網格、集成構建和部署工具、管道等工具。

微服務需求層次

該平臺只是冰山一角,為了在雲原生世界取得成功,您需要成為完全集成的工具和公司生態系統的一部分。因此,賭注絕不是單一平臺、項目、很酷的庫或一家公司。它涉及整個協同工作的整個項目生態系統,以及在未來十年左右合作並致力於該事業的公司(供應商和客戶)的整個生態系統。 我認為這兩個方面同樣重要:

  • 技術 :考慮到向雲原生過渡是一個多年的旅程,只有長期成功才能帶來好處,重要的是打賭有可能在未來5到10年內發展的技術,而不是從過去5到10年的歷史。

  • 文化 :cloud-native是通過微服務、容器、持續交付和DevOps的組合實現的。而成為雲原生需要的不僅僅是為您的應用程序添加少量依賴項/庫(也不是在某些會議中如何推廣它)。您可能不得不改變團隊結構和固定流程、工作習慣和編碼實踐,並習慣於消耗仍然非常活躍的技術空間。如果您的公司文化在某種程度上更接近於開發或僅使用雲原生平臺和相關工具的公司的文化,那就更容易了。諸如提出拉取請求與提交錯誤報告,檢查上游源代碼以及為即將推出的新功能打開討論之類的小事情。 文化一致性和人文因素與技術優勢同等重要。

以下內容並不代表完整的格局,但我將嘗試將我想到的主要雲原生生態系統分組:

Mesosphere和Apache Mesos

作為Apache Software Foundations的一部分,Apache Mesos 有優勢(成熟的社區)也有缺點(進度緩慢)。 它誕生於2009年左右,是一個成熟的框架,它最近增加了對容器(我的意思是docker格式)和類似概念(如Pod/Task組)的支持。

Cloud Foundry和Spring Cloud

Cloud Foundry誕生於2009年左右,是雲原生世界的先驅之一。當 Spring Cloud與Cloud Foundry一起使用時, 該平臺與應用程序本身融為一體。 服務發現、負載平衡、配置管理、重試、超時等一系列功能在服務中執行(在本例中為JVM)。這是Kubernetes等平臺所採取的相反方法,其中所有這些職責都委託給平臺或其他支持容器(例如 envoy )。 我在過去比較過Kubernetes 和 Spring Cloud(請注意,不是的Cloud Foundry) 。

AWS ECS和Docker Swarm

在Docker公司仍然需要搞清楚它是要開發什麼,賣什麼,亞馬遜創造了使用Docker技術作為一部分一個非常堅實的產品 ECS 。帶有Blox的 ECS(AWS的開源容器編排軟件)本身可能不是什麼大事,但當與所有其他AWS產品結合使用時,它是一個功能非常強大的集成平臺。

更不用說從虛擬機時代起成為AWS支持者的Netflix正在向容器領域過渡 ,並正在推動Amazon ECS的創新。

CNCF和Kubernetes

Kubernetes是此類別中最新的平臺之一,但同時也是有史以來最活躍,發展最快的開源項目之一。 與整合的 雲原生計算基金會項目 和支持公司相結合 ,使整個生態系統成為這一類別中非常有力的競爭者。

作為一個後來者(2014年),Kuebernetes的優勢在於從一開始就以容器為中心的架構發展。 而且它基於一個已有十年曆史的Google Borg,這意味著原則(不是實施)是成熟的,並在最高級別測試。

Sysdig 2017年Docker使用報告中的容器編排

正如您可以 從Sysdig 最近的 報告中 看到的結果 ,雲原生用戶似乎很欣賞這一切。

選擇哪一個?

也許您在想,只要您將應用程序打包到容器中,就可以輕鬆地跨不同的雲原生平臺移植。你錯了。無論您是從Mesos、Cloud Foundry、Kubernetes、Docker Swarm還是ECS開始,您都必須投入大量資金來學習平臺和支持工具,瞭解文化和工作方式,並與這個仍然快速變化的生態系統的技術和公司進行互動。

本文的目的不是要比較這些生態系統,而是要顯示它們之間的差異,並證明如果需要,它將需要大量的時間和金錢來輸入,或轉移到另一個生態系統。

Kubernetes作為應用程序可移植層

雲原生態系統在技術、流程和文化方面非常獨特。 但它們之間也有一些整合。許多由一個平臺推廣的概念也在向其他平臺傳播。 例如,部署單元(Pod in Kubernetes)的概念現在出現在Mesos中,它也作為任務組存在於Amazon ECS中。服務器端負載平衡(Kubernetes中的服務)和帶有策略的調度/放置(Kubernetes Scheduler)的概念也存在於Docker Swarm、AWS ECS等中。但這是它走多遠,從一個生態系統過渡到另外,需要付出很多努力。

那麼如何避免與單一供應商鎖定? 一種方法是堅持使用Kubernetes並接受它作為雲和服務提供商之間的可移植性層。Kubernetes如此受歡迎的原因之一是它不是單一的公司玩具,而是由多家大型科技公司支持,如谷歌、紅帽( 現被 IBM 收購【譯者注】)、Docker,Mesosphere、IBM、戴爾、思科等等。

另一個原因是有許多雲公司提供Kubernetes作為服務。 如果您使用Kubernetes,那麼您可以通過第三方服務提供商以最小的努力在Google容器引擎,Microsoft Azure、IBM Bluemix容器服務等雲提供商之間移動您的應用程序,甚至可以在AWS上移動您的應用程序。 這意味著Kubernetes API是雲平臺之間應用程序的可移植性層,而不僅僅是容器。一個容器本身就是雲原生海洋中的一滴。

關於作者

Bilgin Ibryam (@bibryam)是 Red Hat 的首席架構師、提交者和 ASF 成員。 他是一名開源佈道師,博客作者,《Camel Design Patterns》 和 《Kubernetes Patterns》 書籍的作者。 在他的日常工作中,Bilgin 喜歡指導編碼和領導開發人員成功構建雲原生解決方案。 他目前的工作重點是應用程序集成、分佈式系統、消息傳遞、微服務、devops 和一般的雲原生挑戰。 你可以在 Twitter、Linkedin 或他的 博客 上找到他 。

推薦閱讀

  • 雲端設計平臺Coohom在生產環境中使用istio的經驗與實踐

  • 服務網格是中間件的終結者嗎?

  • Istio微服務平臺集成實踐

  • 論服務網格的控制平面和邊緣代理的重要性

  • 後Kubernetes時代的微服務

  • SOFAMesh(https://github.com/alipay/sofa-mesh)基於Istio的大規模服務網格解決方案

  • SOFAMosn(https://github.com/alipay/sofa-mosn)使用Go語言開發的高性能Sidecar代理

合作社區

參與社區

以下是參與ServiceMesher社區的方式,最簡單的方式是聯繫我!

  • 加入微信交流群:關注本微信公眾號後訪問主頁右下角有獲取聯繫方式按鈕,添加好友時請註明姓名-公司

  • 社區網址:http://www.servicemesher.com

  • Slack:https://servicemesher.slack.com (需要邀請才能加入)

  • GitHub:https://github.com/servicemesher

  • Istio中文文檔進度追蹤:https://github.com/servicemesher/istio-official-translation

  • Twitter: https://twitter.com/servicemesher

  • 提供文章線索與投稿:https://github.com/servicemesher/trans



閱讀原文

TAGS: