雲原生可移植性的神話
雲原生可移植性的神話
原文連結：https://thenewstack.io/myth-cloud-native-portability/
作者：Bilgin Ibryam
譯者：殷龍飛
隨著大量新平臺和支援工具的出現，雲原生勢頭正在增長。 這些新平臺為開發人員提供了越來越多的功能 ，可以以自動化的方式快速開發，部署和管理大量微服務 。
但這種雲原生的勢頭的增長同樣會伴隨著成本的增加，最好做好為此付出代價的準備。
最近我寫了一篇由Kubernetes等雲原生平臺提供的“ 開發人員新的分散式原語”，以及這些原語如何與開發應用程式的程式設計原語相結合。 例如，下面看看開發人員必須瞭解和使用多少
請記住，此圖表不包含DevOps團隊的Ops部門必須管理的支援Kubernetes的物件。 在操作之前也不需要額外的應用程式支援工具（用於日誌管理，監視，跟蹤，服務網格等）。
更有可能的是，開發人員必須編寫與容器中的應用程式程式碼相同數量的YAML程式碼。 更重要的是，應用程式本身將依賴於比以往更多的平臺。 雲原生應用程式期望平臺執行執行狀況檢查，部署，放置，服務發現，執行定期任務（ cron 作業）或排程原子工作單元（作業），自動擴充套件，配置管理等。
因此，您的應用程式已放棄並將所有這些職責委託給平臺，並期望以可靠的方式處理它們。 事實上，現在您的應用程式和相關團隊在很多不同的級別上依賴於平臺：程式碼，設計，體系結構，開發實踐，部署和交付管道，支援過程，恢復方案，你能想到的一切。
打賭生態系統，而不是平臺
上圖顯示了程式碼在Kubernetes微服務環境中的小巧程度。 但是，當我們談論基於生產就緒的微服務系統時，這種情況遠未完成。 任何規模龐大的系統都需要集中監控，度量收集，跟蹤，服務網格，整合構建和部署工具，管道等工具。
該平臺只是冰山一角，為了在雲原生世界取得成功，您需要成為完全整合的工具和公司生態系統的一部分。 因此，賭注絕不是單一平臺，專案或很酷的庫或一家公司。 它涉及整個協同工作的整個專案生態系統，以及在未來十年左右合作並致力於事業的公司（供應商和客戶）的整個生態系統。 我認為這兩個方面同樣重要：
- 技術 ：考慮到向雲原生過渡是一個多年的旅程，只有長期成功才能帶來好處，重要的是打賭有可能在未來5到10年內發展的技術，而不是從過去5到10年的歷史。
- 文化 ：cloud-native是通過微服務，容器，持續交付和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，公司（企業）仍然 搞清楚 它是要發展什麼，賣什麼，亞馬遜創造了使用Docker技術作為一部分一個非常堅實的產品 AWS彈性容器服務 。 帶有 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如此受歡迎的原因之一是它不是單一的公司玩具，而是由多家大型科技公司支援，如谷歌，紅帽（ OpenShift ），Docker，Mesosphere，IBM，戴爾，思科等等。
另一個原因是有許多雲公司提供Kubernetes作為服務。 如果您使用Kubernetes，那麼您可以通過第三方服務提供商以最小的努力在Google容器引擎，Microsoft Azure，IBM Bluemix容器服務等雲提供商之間移動您的應用程式，甚至可以在AWS上移動您的應用程式。 這意味著Kubernetes API是雲平臺之間應用程式的可移植性層，而不僅僅是容器。 一個容器本身就是雲原生海洋中的一滴。
Cloud Foundry Foundation ， Cloud Native Computing Foundation 和 Red Hat 是The New Stack的贊助商。
關於作者
Bilgin Ibryam （@bibryam）是 Red Hat 的首席架構師，提交者和 ASF 成員。 他是一名開源傳播者，部落格作者，《Camel Design Patterns》 和 《Kubernetes Patterns》 書籍的作者。 在他的日常工作中，Bilgin 喜歡指導編碼和領導開發人員成功構建雲原生解決方案。 他目前的工作重點是應用程式整合、分散式系統、訊息傳遞、微服務、devops 和一般的雲原生挑戰。 你可以在 Twitter、Linkedin 或他的 部落格 上找到他 。