未來的數據中心架構，誰將主導容器的編排與控制，Mesos還是Kubernetes？答案可能兩者都不是。這一領域還遠未發展成熟，由其是在責任分工或替代方法方面仍有很多其他的選擇在不斷進化。
消費者面臨的挑戰是，所有這些工具都是並行推進且各自獨立發展，而隨著市場逐漸趨於適應該領域的業務需求，各項工具的主導企業為尋求收入來保持競爭，現在出現了一些趨同。這是一個活躍的，迅猛發展的領域。
希望這篇文章能夠闡述2017年數據中心架構領域存在的各種責任層面，可能應用它們的不同方式，以及各自如何演進。
數據中心架構領域能夠提供給開發人員的開發方案，當前業界存在6種：
Bare metal machines (PXE)
Workload jobs/tasks (HPC clouds)
VMs (elastic compute clouds)
Containers (container schedulers & runtimes)
Applications or Microservices (cloud native platforms)
Functions (serverless clouds)
大多數數據中心架構都會同時採用多種方案來應對其特定的需求。下面我們從下到上逐個分析：
1. 基礎設施控制器（Infrastructure Controllers）
在新一代的數據中心裡，容器應該運行在何處？這裡有兩種競爭方案：通過裸機PXE驅動，如pxelinux, kickstart, cobbler, Crowbar, OpenStack Ironic, RackHD；通過運行在基礎設施雲（IaaS）上的VM驅動，常見IaaS包括AWS, GCE, Azure, vSphere, OpenStack, VMware Photon Controller。
2. 容器格式與運行時（Container Formats and Runtimes）
儘管存在CoreOS的容器鏡像格式ACI，Docker已經成為容器鏡像格式的事實標準。運行時方面，大多數人認同使用Open Container Initiative（OCI）的runC作為底層CLI和庫來運行容器。Docker使用名為containerd的runC實現作為守護進程。更高級別的運行時包括Docker引擎，由CoreOS rkt領導的appC系列和Cloud Foundry的Garden，它支持Droplets，Docker鏡像和Windows容器。微軟自己在Windows 2016中發佈了部分基於Docker技術的Windows容器。
3. 容器操作系統與虛擬機管理器（Container OSes and Hypervisors）
容器操作系統的先驅者是CoreOS，現還有陸續出現的rancherVM，Photon Machine和vSphere Integrated Containers，所有這些都可以直接為容器提供硬件層的VM隔離。有跡象表明，微軟也將使用HyperV為容器直接提供硬件層的隔離。未來真的會是裸機上的Linux內核嗎？敬請關注。
4. 基礎架構/配置管理器（Infrastructure/Config Managers）
所有這些基礎架構都具有要管理和配置的服務器/網絡/存儲，並且容器位於這些基礎設施之上。這種方案距離真正解決問題還很遠。下一代的基礎架構中比較突出的是Hashicorp生態系統（Vagrant，Terraform，Consul等），它們結合的非常好。Cloud Foundry的BOSH在多雲和基礎架構控制器方面也表現優異，擁有獨特的封裝，編譯，一次性虛擬機和發佈管理理念。Docker Machine也在這個領域不斷髮展。當然，還有Puppet, Chef, RedHat Ansible, 和/或 SaltStack，以及來自BMC（Bladelogic和RLM），CA（App Deployment Automation）和IBM（UrbanCode）的專有產品。
5. 調度框架（Scheduler Frameworks）
現在看看我們如何運行一些實際的工作負載。假設我們有幾種不同的需要在一組服務器上運行統一工作負載（Batch批處理，Database數據庫，文件系統等）。這些工作負載可能在或可能不在容器中，並且它們可能不包含需要傳統無狀態橫向擴展的冗餘複製服務。特別是，它們可能是文件系統和數據庫等有狀態的服務，因此不能對它們做出太多的假設。如何部署和管理這些工作負載的生命週期（啟動/停止）？主導這一領域的是Apache Mesos / Mesosphere DCOS，儘管還有Hadoop的YARN。這裡的關鍵是你必須構建自己的應用調度程序來使用這些框架，如Hadoop，Spark，Cassandra等。如果你想要通用的橫向工作負載擴展方案，你實際上想跳到容器調度（Cointainer Scheduler，下面的＃7），並考慮Mesos自己的容器調度框架，稱為Marathon。
這個層面，關於這些調度框架是否是一切的新基礎，是業界熱門的辯論領域。例如Mesosphere所營銷的“數據中心操作系統”是否適合Hadoop集群，Spark集群，Twitter或Google這類的大型網站等大型統一的工作負載。CoreOS看上去更符合要求，“你需要的只有＃1，2，3，4和6，然後運行構造（Kubernetes）＃7”！Mesos是谷歌或蘋果Siri所代表的“反對HPC集群陣營”中的領導者，這使得裸機再次變得酷炫，而虛擬化則不再是必要的。
因此，當你想要依賴裸機而不希望重新PXE機器來交換工作負載時，Mesos成為無需燒腦的選擇。從另一個角度看待這個問題，那就是Mesos的魅力取決於你的基礎架構管理（＃4）的好壞。如果你真的討厭配置管理和設施供給，並希望儘量減少使用，Mesos會變得有趣。如果你喜歡你的基礎架構協調，就像你夢想著Chef recipes的精彩，或喜歡觀看BOSH分析其自動化部署計劃的方式，Mesos的存在就不那麼有趣了。
6. 基本任務調度/容器管理（Basic Job Scheduler / Container Managers）
唷！最終我們還是在使用容器。那麼，如果我不想運行統一的工作負載呢，我只想管理幾個容器編排的混合工作負載呢？這就有了Docker Compose，CoreOS Fleet，Mesos Chronos或systemd-nspawn的用武之地。這裡的重點是在幾臺機器上管理簡單或定製的過程和/或容器生命週期，而不是下述容器調度器所管理的更統一的“橫向擴展”的容器生命週期。
7. 容器調度器（Container Schedulers）
更常見的情況，業內關注的重點是如何管理承載於容器內的服務工作負載的負載平衡，橫向擴展，可恢復性，並且能夠根據需要為工作負載附加存儲或網絡或其他服務。這就是Kubernetes或Cloud Foundry的Diego所擅長的，還有像Hashicorp Nomad，Docker Swarm，或者Mesosphere的Marathon這樣的新秀。在當前容器調度熱潮中，向天空扔一塊石頭，掉下來很可能就會擊中2個或3個容器調度器。
8. 容器管理控制檯（Container Management Consoles）
需要一個面向技術的GUI來管理#6和#7？這就是Shipyard, Docker的 Universal Control Plane,和 Tutum佔據的地盤。
9. 容器打包，分發和存儲
使用容器時需要我們來構建，維護，存儲和分發它們。當你有多個層級和團隊時，它不像“Dockerfile＆go”看起來那麼簡單。上述的大多數容器調度程序都需要某種Docker兼容的存儲倉庫，因此Cloud Foundry配備了自己的虛擬機和容器Blobstore來輔助Docker應用。Hashicorp的Packer幫助重複創建虛擬機和容器，如同Cloud Foundry的Buildpacks或OpenShift的S2I。CoreOS的Quay是Docker容器構建器和倉庫，與Docker的Trusted Registry競爭，儘管後者可以下載，而不僅僅是一個雲產品。Concourse CI是一個以容器為中心的持續整合/交付系統，在通過容器組裝構建任務方面也很強大。
10. 容器卷管理器（Container Volume Managers）
對許多容器系統來說這是一個正在推進的工作，這不是很成熟，但2017年將是至關重要的階段。這裡的關鍵是為容器啟用可恢復的動態調度的持久卷，以便有狀態的橫向擴展容器工作負載。傳統的Docker卷只能綁定到單個主機，即需要卷的容器隨主機一起存在或死亡;除非你願意丟失數據，否則無法遷移它們。
可以像主機上的容器一樣在集群內和跨集群快速無縫地遷移，是持久卷需要面對的一個難題。傳統的橫向擴展工作負載主要針對無狀態服務，並將狀態管理職責轉移到不同的層，例如橫向擴展的NoSQL數據庫（BigTable，HBase，Cassandra，Riak，Geode / GemFire等），集群文件系統（例如Ceph或GlusterFS）或傳統的基礎架構/配置管理器方法。這需要容器調度器的一致性調度，例如， Kubernetes的狀態集（Stateful Sets）。今天，Kubernetes擁有可插拔的卷管理方法，類似Docker的卷驅動程序。Cloud Foundry Diego的持久卷驅動程序以組合的方式，使用Open Service Broker API來配置卷本身，使用Docker卷驅動程序API來管理容器內的卷生命週期。
11. 容器虛擬網絡（Container Virtual Networking）
這也是一個正在推進的工作，解決方案卻遠比存儲要成熟，通過使用VXLAN，GRE封裝或其他專有手段，容器可以偽裝擁有專用網絡，可以通過UDP隧道化邏輯網絡，或通過BGP構建完整的對等網絡。專注於網絡這一領域的Docker生態系統早已經在市場上銷售，其中包括Weaveworks Net，Scope和Flux，Docker網絡本身，CoreOS flannel，OpenvSwitch等。而Calico通過創造性地使用IPTables和BGP路由反射提供了一種新方案。在這一領域，VMware擁有領先地位，是最成熟的產品供應商，NSX將在不久之後實現容器集成。這些解決方案也是OpenStack社區所需要的，所以經常有重疊來支持這兩個，儘管有些（例如Weave）是以Docker為中心的。OpenShift使用Open vSwitch作為其Kubernetes的Overlay方案。儘管VMware NSX插件即將於2017年推出，默認情況下，Cloud Foundry在其容器網絡（c2c）技術中使用Flannel。
根據OpenStack Neutron或VMware NSX早期使用者的經驗，客觀地說，這一層的實踐是需要一定的膽量的，因為在性能，安全性和可擴展性方面仍存在很多不確定性。沒有這一層許多容器系統可以很好地運行，但是如果這一層能夠“正常工作”，對開發人員來說，工作將變得更簡單。
12. 容器即服務CaaS/容器平臺
這一層的重點是我們應該考慮這個層次的產品聚集。Docker,Inc.在這一層之上畫了一條線，並將包括這一層以下的所有內容都稱為“容器即服務”或CaaS，而這一模型是其Docker數據中心產品提供的基礎能力，並通過額外的鉤子為其Docker Engine，Trusted Registry和Universal Control Plane添加安全性（RBAC，LDAP等）。Rancher也在這一層提供了非常有趣的產品，它為你所選的基礎設施雲控制器上的任意一個Mesos（+ Marathon），Docker Swarm或Kubernetes提供統一的GUI/目錄/控制平面。Hashicorp提供了Atlas，它是其下面各種生態系統工具的組合。Mesosphere在商業上通過封裝Mesos + Marathon提供了一個稱為DC/OS的增值產品，它是具有包裝安裝程序，軟件分發，操作/網絡/存儲服務和GUI功能。
Amazon EC2容器服務，Google容器引擎和Microsoft Azure容器服務都是些大型可租用容器服務，它們是專有和開放（即Docker或Kubernetes兼容）容器服務的組合。Cloud Foundry本身（IBM的Bluemix，Pivotal，SAP，華為，Swisscom，Centurylink等）也在Docker的支持下運行。
這裡有一個有趣的市場辯論。在這一層面定位其主要商業產品的供應商都聲稱這一層是下一代數據中心的最佳抽象層。這裡假定容器（或諸如“Pods”等變體）作為管理單元。這要比傳統的平臺即服務（PaaS）雲以“應用程序”或“服務”作為管理單元的層面要低。
這些供應商對PaaS的主要觀點是它對於現實世界的場景（如遺留系統）來說太限制了。有關討論，請參閱＃14。
13. 雲原生服務和框架（Cloud Native Services and Frameworks）
容器並不是很有趣，除非你可以利用其優勢獲得巨大收益（更高的密度，更快的配置/部署軟件，一次性/不可變的服務器管理）。雖然Google證明了容器的潛力，但大多數人都在採用容器來實現更快速部署可擴展的軟件，Netflix和Amazon都表明，只需使用虛擬機即可實現更快的工作，並擴展更多。容器很好，但還不夠。
微服務的模式在這裡變得至關重要。 Pivotal的Spring Boot和Spring Cloud已經成為構建基於Java的雲原生微服務的一種非常受歡迎的方法，而且很少的努力。替代方案包括.NET Core（Web API），Python（Flask，Django），Ruby（Sinatra或Rails），JavaScript（具有快速表達式），Scala（使用Akka）和Golang作為流行的微服務語言+框架。Netflix OSS Eureka，Archaius或Hystrix + Turbine，或者Hashicorp的Consul等服務發現，動態配置，斷路器等設施都非常有用。用於橫向擴展數據的工具也有很多，例如用於流緩衝的Apache Kafka，用於流處理的Apache Flink或Spring Cloud Data Flow（在幾乎任何容器調度器上都可部署）。還要考慮像Cassandra，HBase，Riak這樣的NoSQL解決方案，用於解決最終一致性的區域主動 - 主動數據複製，或者像Hadoop，Spark等大數據解決方案。
Cloud Foundry的玩家如Bluemix和Pivotal Network具有豐富的基於Open Broker API的產品組合，可以像Bluemix（IBM Watson流行）一樣按需提供服務，也可以下載可安裝任何地方的BOSH版本（通過Github或Pivotal網絡）。當然，AWS，Google和Microsoft擁有最廣泛的選擇，其中許多是專有的重新定義的開放源代碼和專用代碼的組合，作為服務提供。
14. 雲原生應用平臺（Cloud Native Application Platforms）
這一切看上去非常複雜！有些人希望有一個“一體化”解決方案，簡化和組合自動化層，並提供更多的架構和編程工具，性能監控，多租戶安全，面向開發人員的UI等。雲原生應用和微服務不只是通過“提升和轉移”一個遺產，來獲得輕微的好處。
雲原生平臺為開發人員提供了兩種體驗：部署應用程序代碼並消費服務。更具體地說，他們可以將應用程序代碼大規模，穩定地以高可用的方式推送到雲上，而不用擔心平臺下面的深層技術。其次，他們可以請求服務/實用程序，並將其應用到自己的代碼中，如數據庫，消息隊列，緩存，中間件，安全系統等。
這一層在2014年之前被稱為平臺即服務（PaaS），但這是一個誤導：這個軟件並不總是“即服務”，它可以安裝在任何地方。這裡的傳統產品是Google App Engine，Force.com和Heroku。但是，這一層已經超越了這些相對不透明的平臺，簡直就是這篇文章中提到的所有其他技術的定製組合！想想一個雲原生平臺，對於開發人員應該如何通過Cloud Native Services/Frameworks進行應用程序的開發，並預先集成使用其他技術，有更多的選項，而容器平臺（＃12）真的不在乎，而是力求廣泛替代傳統的基於VM的數據中心。兩者都可以不同程度的運行傳統工作負載，因為它們都基於相同的技術。區別在於用戶體驗和堆棧中各種功能的專注度/成熟度。至於哪種是否優先取決於你的目的和目標。
將時間倒回2012年，在Heroku使用容器之後，Cloud Foundry（包括Pivotal Cloud Foundry和IBM BlueMix）迅速跟上。Pivotal現在正在將Netflix OSS商業化，並將這些基礎覆蓋到基礎設施，儘管如此其獨立的開源模塊在CF生態系統之外並沒有被廣泛使用。另一個新的選擇是Red Hat的OpenShift v3與Red Hat最近收購的Ansible。 OpenShift v3旨在將Kubernetes，RedHat JBoss/Wildfly和RedHat Enterprise Linux組成一個半結構化平臺。它比Cloud Foundry少得多，但比典型的容器平臺要更完善。
15. 無服務平臺（Serverless Platforms）
推送應用程序代碼並消費服務的下一個邏輯步驟是推送可重用函數到某個地方，甚至不用擔心實例或容器等。有些廠商稱這為“函數即服務”（FaaS）。這一層是IT行業的新潮流，容器供應商將雲原生平臺轉變為“無服務器狀態”。 AWS Lambda是今天這個領域的主要產品，但Google Cloud Functions和Azure Cloud Functions功能也已經出爐了。 Docker，Kubernetes和Cloud Foundry的無服務器框架正在萌芽。注意跟蹤這一領域的進展。
16. 供應商，基金會，開源協作與競爭
這裡討論的許多項目都隸屬於下述其中之一：
通過一些開源基金會（例如Apache）可以獲得的開源產品
直接作為商業開源，通過風投支持的創業公司（即Docker,Inc.或CoreOS,Inc.），或在某些情況下，較大的軟件供應商（即VMware）
通過可能基於開源產品的雲服務提供商（例如Google的容器引擎基於Kubernetes）提供的專有產品，或者可以是重新打包開源產品甚至重新包裝專有軟件作為服務（AWS同時使用這兩種方案）
這些領域將成為一個非常有競爭力和嘈雜的市場，因為所有這些解決方案，如上所述，同時發展和相互獨立。目前尚不清楚哪些供應商將在這種競爭格局中生存下去，儘管我認為大部分主要的供應商將在2020年之前獲得資金。
不出重大變故，AWS，Azure，Google將成為三巨頭（附：本想把阿里雲加進來，看了一下數據：2016年AWS營收122億美元，阿里雲營收66.63億人民幣，確實還有差距）。所有這些開源框架和選項可以說是複雜性太高 - 我們被寵壞了。他們最多將成為這三大巨獸的收購目標。也就是說，這不是一個既成事實，這個行業過去幾十年來一直把控制權鎖定到一個供應商，並不是很好。開放雲技術仍然是專有云的有效對手。
鑑於這一競爭和希望避免陷入困境，一些項目得到非營利組織的支持，以確保獨立的治理和管理，主要的兩個基金會是Cloud Native Container基金會（CNCF）和Cloud Foundry基金會（CFF），以及Apache基金會提供主要組件。CNCF正在採納幾個項目的所有權和管理權，從Kubernetes（來自Google），Open Tracing（來自Pivotal的幾個開發商，Soundcloud，Twitter等）和Prometheus（從Soundcloud）開始，進入一個開放的生態系統。CFF擁有所有Cloud Foundry代碼，並專注於認證使用Cloud Foundry的開源內核的供應商產品，管理成員之間的提交權，以及培訓開發人員使用雲原生開發技術。兩個基金會都是Linux基金會的子項目，而不是純粹的競爭對手，這些基金會可能會成為用於非常不同的焦點目標的重疊技術集合：CNCF的章程廣泛地推動了容器和微服務技術的採用和發展，而Cloud Foundry的使命是通過廣泛定義的開放雲軟件加速業務創新。我們已經看到合作（例如一個跨基金會的工作組，採用CF Service Brokers作為標準）。
本文觀點來自原作者Stuart Charlton，原文來自Quora，翻譯搬運至此，讓大家對當前整個雲計算技術發展趨勢有個大致的瞭解。