一個平臺的誕生必定是經(jīng)年錘煉而來，即從應用程序中提取通用的功能到更底層的抽象中。如果完成了既定的設計意圖，那么您將得到一個可用的平臺，反之，您將得到一個“燙手山芋”，既而您將再次尋找合適的平臺，這時候您會發(fā)現(xiàn)別人已經(jīng)構(gòu)建好的平臺給您帶來了一線希望的曙光。

正確的平臺，您將在靈活性和簡單性之間達到您所需要的平衡，從而使您能夠更快速地構(gòu)建而不受太多限制。本文將探討云平臺的范圍，以幫助您找到最適合您的那一款。

對于什么樣的平臺才是完美的，每個人有每個人的看法，因為每個人的使用場景有所不同。但是幾乎所有人都尋求以下兩個特征：

• 提高開發(fā)速度

• 自動化運維

這兩個要求推動了大多數(shù)軟件平臺的進化。真的，這兩項可以作為自動化檢驗標準：速度和可重復性。

所以，沒有一個平臺對于任何用戶來說是完美的，那么是否意味著我們要自己寫呢？如果自己寫，是否建立在一個現(xiàn)有的平臺之上？您想要一個從上到下的緊密集成的平臺，還是想要使用強大的擴展點松散連接的多層平臺？

這些都是一時間難以回答的問題，并沒有一個真正適合每個人的單一答案。尋找合適平臺的成就感是發(fā)現(xiàn)，比較和權衡之一。所以我們一起來吧！

云平臺的“彩虹”，總有您喜歡的色彩。

每個廠商都會告訴你，他們的軟件是特別的，甚至是獨一無二的。他們都在努力使自己的產(chǎn)品與眾不同，以提供不可替代的價值。但是，如果您仔細觀察，并容忍一些粗糙的地方，您可以根據(jù)它們提供的接口類型對這些產(chǎn)品進行分組。???

云平臺的示例

“軟件即服務”一詞最早可追溯到2000年左右，指的是將打包的軟件產(chǎn)品和支持服務捆綁在托管解決方案中，以避免經(jīng)常未知的執(zhí)行和操作成本。一個SaaS產(chǎn)品本身就是一個基礎平臺。SaaS的一些原始用途取代了傳統(tǒng)企業(yè)資源計劃（ERP）和客戶關系管理（CRM）平臺。

像Salesforce和SAP這樣的公司，對于那些沒有大型工程師團隊或IT部門來構(gòu)建和管理這些復雜的系統(tǒng)客戶，他們會在這些領域非常成功。即使是擁有這些資源的公司也可能認為這些事情不在其核心競爭力范圍之內(nèi)，不值得自己去建設或經(jīng)營。如今幾乎所有類別的軟件都可以通過SaaS獲得，從電子郵件到文字處理系統(tǒng)，再到內(nèi)容管理系統(tǒng)比比皆是。

Spectrum的另一方面是基礎設施即服務。

將應用程序配置到基礎架構(gòu)平臺上

基礎設施平臺在SaaS之后不久就出現(xiàn)了。VMware GSX Server（2006）和亞馬遜彈性計算云（EC2，2006）提供了早期的虛擬化平臺。然而，VMWare最初專注在企業(yè)內(nèi)部部署，亞馬遜web服務則將其托管的IaaS和SaaS產(chǎn)品結(jié)合，定位于更廣闊的市場。后來，Rackspace和美國航天局開發(fā)了OpenStack（2010）作為VMware vSphere（2009年發(fā)布，取代GSX）和亞馬遜EC2的開源競爭對手。

這些IaaS主要提供了一些具體的抽象：虛擬機計算節(jié)點，軟件定義的網(wǎng)絡和可掛載的存儲。在有SaaS的情況下，托管的IaaS的主要賣點是外部資源容量配置操作的自動化，但與SaaS不同，托管的IaaS會給用戶帶來資源規(guī)模無限大的錯覺。對于大多數(shù)對基礎設施外包感興趣的公司來說，AWS會提供比客戶以往任何時候資源需求量大得多的資源，在您向AWS尋求更多節(jié)點之前，已經(jīng)擴展了數(shù)據(jù)中心。對于無法或者不愿意外包的公司，像OpenStack和vSphere這樣的基礎設施平臺可以在您選擇的數(shù)據(jù)中心中托管自己的云。

然而，管理不僅僅只是涉及硬件，還包括管理一個基礎設施平臺，并且這需要更多的工作，這是企業(yè)公司已經(jīng)在自己的平臺上做過的。無論是手動管理沒有虛擬化層的硬件，還是渴望使配置更加自主化。因此，as-a-service模型又回到了起點:承載的平臺變成了打包產(chǎn)品，這次添加了多租戶功能，允許客戶為自己的內(nèi)部用戶組操作它。

隨之而來的應用平臺。

基礎架構(gòu)平臺上的應用平臺

Fotango的Zimki（2006）和Heroku（2007）率先使用平臺即服務。后來的Google App Engine（2008），CloudFoundry（2011）和其他幾個加入了戰(zhàn)斗。在當時，很明顯，這些是真正的應用平臺（aPaaS），專門用于加快開發(fā)人員的速度并降低運營開銷。使得開發(fā)人員自己配置和管理他們開發(fā)的應用，進一步壓縮了從開始到發(fā)布到反饋到迭代的周轉(zhuǎn)時間，與日益普及的敏捷軟件開發(fā)思想相契合，并為剛剛起步的DevOps運動播下種子。

但進步永遠不會停止。容器平臺出現(xiàn)了。

基礎架構(gòu)平臺上的容器平臺

容器化已經(jīng)比您想象得要深入（FreeBSD Jails自2000年以來一直在使用），但是可以肯定的是直到Docker（2013）將Linux操作系統(tǒng)級虛擬化與文件系統(tǒng)鏡像結(jié)合起來，容器化才真正廣泛流行起來。這使得構(gòu)建和部署容器化應用更加容易，這是一種可以理解為通過構(gòu)建磁盤鏡像來加快基礎設施平臺配置的IaaS用戶模式。但與VM相比，同時運行的幾臺驅(qū)動器足以讓您的工作站超負荷運行，容器則允許您在本地部署完整的微服務堆棧，大大加快了開發(fā)周期。另外，由于降低了開銷，每個微服務器都可以擁有自己的容器映像，自己的發(fā)布周期和自己的滾動升級，允許更小的團隊并行開發(fā)它們。

從容器運行時到容器平臺，這是一個明顯的進步。像CloudFoundry這樣的應用平臺和像Apache Mesos這樣的集群資源管理系統(tǒng)自成立以來就一直使用容器隔離。下一步是開放一個平臺API，允許開發(fā)人員在一組機器上部署越來越受歡迎的Docker鏡像。像基礎設施平臺一樣，容器平臺也是在內(nèi)部開始的，后來提供托管服務。Mesosphere的Marathon（2013）是通用容器編排的首個開源平臺之一，但它早期是由內(nèi)部努力推動的，比如Google的Borg（?2004）和Twitter的Aurora（2010年寫成，在2013年開放為Apache Aurora）。

容器編排是容器平臺的核心。與應用平臺一樣，容器平臺需要提供基于約束的聲明性調(diào)度。與應用平臺不同的是，容器不限于十二要素應用程序。比如，有狀態(tài)服務需要的持久卷，隔離保證機制，特定域的遷移過程及并行的備份作業(yè)等等。由于這種靈活性，容器平臺可以輕松地變得比應用程序平臺更復雜，以支持更多種類的工作負載。

計算機集群上的容器平臺

為了增加靈活性，并且在不遷移的情況下支持傳統(tǒng)工作負載，許多人在基礎設施平臺之上運行容器平臺，但這并不是絕對必要的。容器與單個機器已經(jīng)十分接近，幾乎所有的工作負載都是兼容的。所以并不是每個人都需要這種靈活性。許多開發(fā)人員將他們所有的時間都花在單層的堆棧中。他們尋找避免重復執(zhí)行任務的辦法，例如為他們構(gòu)建的每個新應用程序手工制作容器鏡像。對于這些人來說，功能平臺（也稱為無服務器）就出現(xiàn)了。

亞馬遜推出了AWS Lambda（2014），引領了無服務的“熱潮”，在其虛擬基礎設施平臺之上提供輕量級的容器化事件處理。像其他Amazon Web Services一樣，Lambda僅僅只是一種托管服務。因此，由Iron.io（2014），Apache OpenWhisk（2016），F(xiàn)ission（2016），Galactic Fog的Gestalt（2016），OpenLambda（2016）填補了私有化部署替代品的市場。

除了他們各自基于特定語言的框架之外，功能平臺的運行方式與應用平臺相同。因此，開發(fā)人員只需要開發(fā)事件處理程序，并使用平臺API將觸發(fā)器映射到該處理程序即可，而不是使用多個端點編寫應用程序。功能平臺通常與API網(wǎng)關配合或集成，以處理代理，負載均衡和集中式服務發(fā)現(xiàn)。與應用平臺不同，功能平臺透明地集成了基于負載的自動縮放，因為它們控制所有入口點和復用。

像容器平臺一樣，功能平臺不一定需要基礎架構(gòu)平臺，但與容器平臺提供的靈活性不同，功能平臺不是設計用于支持各種各樣的工作負載。所以僅僅只運行一個功能平臺可能是不明智的或不可能的。您可能還需要一個較低級別的容器或基礎架構(gòu)平臺。一些功能平臺甚至被設計成與容器平臺集成，利用中間層自動化來降低較高層的復雜性。

云平臺，它們的接口和抽象規(guī)模

這些平臺中的每一層都提供了自己獨特的抽象和API，某些層比其他層更抽象。一些更高層級的平臺要么全部采用，要么就全不用。它們具有頂部到底部的集成，但只能支持您要運行的一小部分工作負載。您可能會嘗試選擇最高層的抽象化來最大限度地提高開發(fā)人員的速度，但是您也必須考慮到這些平臺上構(gòu)建的軟件將與平臺最緊密耦合，當您需要重新選擇平臺的時候， 這將增加您的風險。另一方面，較低級別的平臺可以提供最大的靈活性，可以實現(xiàn)最廣泛的工作負載，包括Web應用程序，微服務器，整體架構(gòu)應用，數(shù)據(jù)管道和數(shù)據(jù)存儲服務。它們使得遷移更輕松和基礎設施操作更容易，但是在上面實際開發(fā)或運維應用程序，服務或作業(yè)卻更難。

應用平臺和基礎設施平臺之間的沖突是容器平臺受歡迎的重要原因之一。容器平臺在這兩方面作出了妥協(xié)。它們允許您根據(jù)每個容器來決定您的工作負載是否需要自己的環(huán)境，或者可以作為二進制運行，支持更多種類的工作負載。但它們還像應用程序平臺一樣提供聲明式配置，生命周期管理，復制和調(diào)度。如果您還需要更高層次的抽象，您可以輕松地在容器平臺之上部署更輕量級的應用程序或功能平臺，共享具有較低級別工作負載的資源和機器。如果您還需要較低級別的抽象，您可以輕松地在基礎設施平臺之上部署容器平臺，而不是直接使用裸機。

DC / OS架構(gòu)層

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝