當今Google技術市場的云容器服務競爭加劇，谷歌，亞馬遜與微軟Azure正在為開發他們的服務而努力，從而能夠更好、更快的適應市場。

這篇文章通過對3種不同的云容器平臺進行深入比較，讓讀者了解到哪一種平臺適合您的企業發展。

Docker Linux云容器中最重要的競爭對手仍然是亞馬遜和谷歌，由于微軟Azure加入，他們的競爭正在如火如荼的進行著。

[[203687]]

亞馬遜網絡服務和Google正積極開發云端容器服務，從而更好的適應企業應用開發業務。

這些公司的云容器服務于Docker容器管理能夠遠離用戶，從而更容易部署和擴展其上構建的應用程序。 然而，他們在彼此的產品之間仍存重大差異，包括每個產品都選擇實現自動縮放，冗余和與第三方工具和云的互操作性。

自動縮放是競爭的主要關鍵點

Google容器引擎(GKE)由pod，復制控制器和節點組成。 Pods是對應用程序特定的邏輯主機建模的容器的邏輯分組。 復制控制器確保任意一個時間運行特定數量的pod副本。 節點是支持容器化環境的Google Compute Engine虛擬機。

GKE基于Google的Kubernetes云容器業務流程平臺。 Kubernetes 1.1版，11月24日發布，1.0個月后***亮相，是市場上***個使用水平pod自動縮放功能自動調整pod的功能，這是用戶非常尋求為GKE多種用例提供理由的功能。

笛卡爾實驗室公司的共同創始人兼云架構負責人Tim Kelton說，“我們對所有類型的項目都進行了自動縮放，這是一家位于美國馬薩諸塞州洛斯阿拉莫斯市的機器學習公司，負責處理PB級衛星數據。

(備注：“TB是一個計算機存儲容量的單位，它等于2的40次方，或者接近一萬億個字節(即，一千千兆字節)。”

一提到數據量級，人們通常會聯想到美國國會圖書館(見圖)。德勤、麥肯錫、IBM、Gartner和移動廣告公司Adfonic的數據專家向TechTarget記者介紹了PB級數據究竟有多大。

麥肯錫***分析師Michael Chui指出，美國國會圖書館“在2011年4月前已經收集了235TB的數據，而一個PB相當于它的4倍。”

TechTarget自己的百科網站Whatis有關于PB大小的定義：“PB是數據存儲容量的單位，它等于2的50次方個字節，或者在數值上大約等于1000個TB。”

未來學家Raymond Kurzweil他的論文中對PB的定義進行延伸：人類功能記憶的容量預計在1.25個TB。這意味著，800個人類記憶才相當于1個PB。

如果這樣還不夠清楚，那么Adfonic的CTO Wes Biggs給出了下面更直接的計算：

假設手機播放MP3的編碼速度為平均每分鐘1MB，而1首歌曲的平均時長為4分鐘，那么1PB歌曲可以連續播放2000年。

如果智能手機相機拍攝相片的平均大小為3MB，打印照片的平均大小為8.5英寸，那么總共1PB的照片的并排排列長度就達到48000英里——大約可以環繞地球2周。

1PB足夠存儲整個美國人口的DNA，而且還能再克隆2倍。)

Kelton解釋說，自動縮放可以派上用場。 有時，他的公司處理了一百PB的數據，這需要擴展到3萬個內核。 他在Kubernetes的***個版本 - 這是由GKE不久之后加入的 - “這不是核心功能集的一部分，”他說。 GKE的高級產品經理David Aronchick表示，GKE不支持垂直容器擴展或節點自動縮放，但是這些功能即將推出，他還負責Kubernetes的產品管理。

同時，亞馬遜的EC2云容器服務(ECS)由服務，任務和實例組成。 服務是構成應用程序的任務組，而實例則是支持容器的彈性計算云虛擬機，非常像GKE中的節點。

Amazon ECS的自動縮放功能與GKE的功能相反：服務可以使用Amazon CloudWatch和Amazon Web Services(AWS)Lambda進行自動縮放，實例也可以基于CloudWatch指標進行自動縮放，相當于pods - 不能自動縮放。

雖然所有類型的自動縮放都很重要，但是Amazon用戶希望將自動縮放功能添加到ECS中。一個Web內容聚合器ACI信息組技術副總裁Chris Moyer說：“旋轉一個額外的實例意味著您有額外的能力來運行其他任務，但并不意味著任何新的任務將被轉移。

“如果你只是在自動縮放你的實例，它并沒有真正的幫助你處理額外的負荷——你必須把額外的任務放大來擴展。”

跨越區域的冗余

在開發ECS時，亞馬遜優先考慮在同一集群中本地跨越可用性區域(AZ)的能力，以便根據客戶需求對任務自動縮放進行冗余。 當ECS服務調度程序啟動新任務時，它還會嘗試在集群中的AZ之間自動平衡。

“這很重要，因為單個AZ可以失敗，所以如果兩個任務都在同一個AZ，那可以輕松地取消你的服務，”Moyer說。

根據Google的Aronchick，Google可以通過命令行界面(CLI)跨越GKE的多個區域。

“真的很容易 – 只需兩三個命令，”他說。然而，這涉及到GKE客戶***的愿望清單項：Web UI的改進，包括跨區域擴展集群。

Vendasta Technologies在Saskatoon Sask的***架構師Dale Hopkins表示：“UI需要大量的工作，該公司為媒體公司建立銷售和營銷軟件。 霍普金斯說，UI目前允許集群創建和更多。 “如何擴展集群是非直觀的。”

互通性

ECS被構建為一個可擴展平臺，旨在被放置在客戶現有的工作流程中，主要用于代表用戶處理集群狀態。 與現有工作流程的集成的一部分適用于客戶已經使用的工具，例如用于高級調度的Apache Mesos。 亞馬遜還擁有廣泛的云容器合作伙伴網絡，向亞馬遜ECS提供諸如監控，持續集成和安全性等功能。

據Aronchick介紹，Google同時建立了一個云容器合作伙伴聯盟，使得Kubernetes能夠跨多個云提供商部署 - 而且也是今天的CLI功能。 當Kubernetes 1.0去年夏天發布時，Google領導了Cloud Native Computing Foundation的創建。 基金會成員包括企業云服務公司，如IBM和紅帽，以及最終用戶Box，eBay和Twitter。

笛卡爾的Kelton說：“有了Kubernetes，我實際上可以在Amazon上部署，我可以部署在Azure上，我可以部署在IBM上，我可以部署在我自己的物理硬件上。 “這很有吸引力，因為我們有選擇。” Google還有一個開源項目，每個月有數百個提交者和數千個提交，允許Kubernetes快速添加新的功能，如水平pod自動縮放。

451研究公司的分析師杰·萊曼(Jay Lyman)說：“Google是Kubernetes的***，Google對此做得非常好，擴大了該社區的發展。

根據創始人約翰·德埃斯波西托(John D'Esposito)，一家總部位于紐約的一家咨詢大型企業IT項目的公司計劃在兩個新項目中使用ECS。 “促使我們使用ECS [包括]與現有的經過驗證的基礎設施服務(如彈性負載平衡，虛擬私有云，身份和訪問管理以及彈性塊存儲)的無縫集成的主要優點。

GKE和Compute Engine定價也非常吸引客戶。 除了以10分鐘的增量為基礎的虛擬機資源收費，GKE還免費提供了Kubernetes主機，這特別適用于Vendasta的Hopkins。 他說：“我沒有為Kubernetes付出代價，直到我進入大量的機器--GKE為***套機器免費提供了Kubernetes的主人，”他說。

在推出Kubernetes和容器引擎之前，霍普金斯和凱爾頓都已經使用Google云服務，包括Google App Engine。 因此，數據重力也起到了他們選擇部署云服務器服務的作用。

Kelton說：“我們的大部分數據都是在PB級，所以你不能只是移動它們或復制它們，所以你必須將數據移動到數據旁邊。 大部分數據目前都存在于Google Cloud Platform中，盡管笛卡爾與AWS的合作伙伴合作。

Microsoft Azure云容器服務準備就緒

盡管Google和AWS在云端容器戰爭中處于領先地位，但亞馬遜最為關鍵的競爭對手仍然是微軟Azure，它擁有自己的基于Linux的云端容器服務，預計將有限，以及今年將推出的新版本的Windows Server 支持基于Windows的容器。 “我們大多數客戶都是在Azure或亞馬遜，”馬薩諸塞州羅徹斯特HKM咨詢公司的創始合伙人克里斯·萊利(Chris Riley)說，“微軟有一些有趣的工具正在開發中。 如果我們來看一個次要的，那可能是Google之前的Azure。“

與許多微軟產品一樣，簡單易用的使用是設計的重點，根據Kristian Nese的說法，他是挪威的微軟Azure系統集成商。

Nese說:“當我們今天部署Azure云容器服務時，它的代碼是100行。”“一旦部署了Azure容器服務，就可以部署23個資源。如果您手動執行這個操作，它很可能會導致數千行代碼。”

Azure容器服務還在工作中以獨立服務的形式進行了自動縮放，這一服務也在預覽中被稱為VM Scale集。Nese還說，Azure還將提供一些現有的、熟悉的工具來管理容器，比如Azure資源管理器。評估Azure容器服務與Google和AWS的對比

David Linthicum、云技術合作伙伴AWS、谷歌和Azure都提供了自己的云容器服務。盡管它們各有優缺點，但對您來說***的服務取決于您的應用程序需求。

隨著越來越多的組織使用容器技術來部署云應用程序，看起來容器和云將會加入到更時髦的環境中。因此，三大云服務提供商——亞馬遜網絡服務、微軟Azure和谷歌——在市場上擁有自己的容器服務也就不足為奇了。然而，這些服務并不是生來平等的。

出于本文的目的，云技術合作伙伴，一家位于波士頓的云計算咨詢公司，對Amazon Web Services(AWS)、Google和Azure容器服務進行了內部審查，對技術進行了輪詢咨詢，并檢查了用例。在評估或使用基于云的容器服務時，該公司考慮了幾個重要的特性，包括數據管理、可伸縮性、性能、安全性、DevOps和與管理和操作的集成(如表1所示)，使用的是開發和操作——簡而言之，企業對此該做些什么?

對于1-5級，1是***分，5是***。 指定為1意味著該技術根本不支持該類別，而5則表示該技術滿足該類別的大部分功能和功能要求。 我們研究DevOps類別的一個要求是容器子系統支持DevOps操作或提供集成存儲庫的能力。 對于評估Google，AWS或Azure容器服務的企業，本文提供了一些基礎知識。 企業如何應用，將最終將推動您的最終產品發展方向。

集成和數據考慮

Azure容器服務(ACS)基于Apache Mesos，這是一個開源的容器編排系統。 這意味著考慮到ACS之前的功能和功能，可以對ACS的特性和功能做出一些很好的假設。 目前尚不普遍可用的ACS是上述三個容器服務中***的。 隨著我們在Microsoft容器產品上提供更多的數據點，將會有很大的變化。

使用AWS EC2容器服務(ECS)，我們看到一些操作問題，例如無法以細粒度的級別監控容器。當考慮ECS與管理和運營的集成時，應該與任何AWS產品一樣強大，我們必須將其降低到4分，相對于Google容器引擎(GKE)5分。然而，ECS確實包含了CloudWatch集成，與ACS相比，它可以使其更加穩定。此外，此時，ACS僅支持Linux容器。雖然Windows的支持即將到來，隨著Microsoft端口Mesos的過去，.NET開發人員現在已經落后于曲線。在數據方面，所有這些服務都提供本機數據連接，而不會強制使用外部API，但還有改進的余地。一個問題是他們將綁定容器與本地數據服務，而不提供開放的數據訪問，這增強了可移植性。如果數據與容器緊密耦合，則難以創建便攜式容器。這是我們現在關注的一個新興領域。

AWS，Google和Azure容器安全

在考慮安全性時，我們發現Google的服務通過其Kubernetes容器業務流程系統，具有“秘密”功能和其他兩項服務缺乏的額外資源限制。 因此，GKE獲得了更高的安全排名。 請記住，Microsoft也使用Kubernetes，但是以不同的方式。 大部分技術本身都是從用戶中抽象出來的。

然而，當查看主機平臺或容器服務所在的公共云平臺時，有趣的是，Google平臺在安全性方面，在某些方面不如AWS或Azure。 雖然Google可以使用第三方身份訪問管理(IAM)工具，但它缺乏本地IAM支持。 雖然這并沒有影響到表中列出的排名，但是隨著任何這些平臺的前進，這是值得考慮的。

DevOps的可擴展性

對于DevOps，GKE和Amazon ECS現在有自己的注冊中心，但是Azure容器服務卻沒有。Google和AWS在考慮各自云中的容器服務時，提供了更好的DevOps集成。

可擴展性與您的應用程序的需求相關，因此我們根據其提供的機制(如Mesos)以及我們在項目中看到的一些用例做出假設。 當您查看這些技術來托管和執行容器時，您可以使用相同的方法。 例如，使用Mesos的ACS應提供公平的可擴展性，但不如GKE提供更好的集群功能。

眾所周知，亞馬遜ECS提供優質的可擴展性，主要由AWS為其容器引擎提供的高度可擴展的平臺功能驅動。

總而言之，由于Google與其自己的Kubernetes容器集成緊密集成，以及Google的開發和運營支持，Google的產品總體上更為先進。 不過，Google并不是那么遠，AWS和微軟不能快速趕上。 考慮到AWS在市場上的擔心，它可能會在不久的將來提供更好的容器技術。