由于沒有哪個云計算平臺可適合所有用例，所以我們來看看主要的云計算平臺，并且確定在哪些時候選用哪些服務更合適?
無論你是否購買、構建還是部署開源服務，你可能已經在使用某種軟件平臺來構建、部署和擴展應用程序。
經過多年從應用程序提取常用功能到較低抽象層，平臺隨之出現。現在市面上有很多云計算平臺，正確的平臺可幫助你在靈活性和簡單性之間實現所需要的平衡，從而使你能夠更快地構建而不受太多限制。本文中，我們將探討這些云計算平臺以幫助你找到最適合自己的平臺。
對于什么是完美的平臺，每個人都有自己的想法，但每個人都希望實現的是：
·提高開發速度
·自動化操作技能
既然沒有平臺適合所有用戶，你是否應該自己構建平臺?如果你自己構建，是否在現有平臺之上構建?你如何選擇基礎平臺?你想要從上至下緊密集成的平臺，還是想要松散連接強大擴展點的多層平臺?
這些都不是簡單的問題，也沒有真正適合每個人的單一答案。下面讓我們來看看如何選擇：
平臺類型
每個供應商都會告訴你他們的軟件是特別的、獨一無二的，他們都在試圖區分其產品來提供不可取代的價值。但如果你足夠堅定，不被他們的營銷術語動搖，則應該先根據他們提供的接口類型來對這些產品進行分組。
▲云計算平臺示例
軟件平臺
“軟件即服務”一詞最早可追溯到2000年左右，它指的是捆綁封裝軟件產品和支持服務到托管解決方案中，以避免未知部署和操作成本。SaaS產品本身可作為平臺。該術語的原始用例描述的是取代傳統企業資源規劃(ERP)和客戶關系管理(CRM)平臺的解決方案。
Salesforce和SAP等公司在這個領域非常成功，他們讓那些沒有大型工程或IT部門可構建及管理這些復雜系統。即使是擁有足夠資源的企業也可能會認為這些事情不在其核心競爭力范圍之內，不值得自己去構建或運作。盡管如此，幾乎每個類別的軟件都可從SaaS獲取，從電子郵件到文字處理到內容管理系統。
另一方面是基礎設施即服務。
▲在基礎設施平臺上配置應用程序
基礎設施平臺
在SaaS出現不久后，基礎設施平臺開始出現。VMware GSX Server(2006年)和Amazon Elastic Compute Cloud(EC2,2006年)都提供早期虛擬化平臺。VMware最初專注于企業內部部署安裝，而Amazon云計算服務則獲得更廣泛的市場，因其將托管IaaS和SaaS產品相結合。隨后，Rackspace和NASA開發的OpenStack(2010年)作為VMware的vSphere(2009年發布，取代GSX)和Amazon的EC2的開源競爭對手。
這些IaaS主要提供了一些特定的抽象化：虛擬機計算節點、軟件定義網絡和可附加存儲。與SaaS一樣，托管IaaS的主要賣點是外包手動容量配置的操作和自動化，但與SaaS不同的是，托管IaaS還提供你自己軟件無限量級幻影。對于大多數對外包基礎設施感興趣的公司而言，AWS提供比以往任何時候都更多的容量，甚至在你要求更多節點之前他們就已經擴展數據中心。而對于無法或不愿意外部的公司，OpenStack和vSphere等基礎設施平臺讓你可在自己選擇的數據中心托管自己的云計算。
雖然管理硬件以及基礎設施平臺看起來是更多的工作，但其實這是企業在內部部署的平臺正在做的工作。有些企業甚至在沒有虛擬層的情況下手動管理硬件，無論哪種情況，他們都渴望讓配置更加自助化。這也讓即服務模式更加完整：托管的平臺成為封裝產品，這次增加了多租戶功能，允許客戶自己為內部用戶群體進行操作。
隨之而來的是應用平臺。
▲基礎設施平臺上的應用平臺
應用平臺
最早使用平臺即服務的是Fotango的Zimki(2006年)以及Heroku(2007年)。隨后谷歌App Engine(2008年)、CloudFoundry(2011年)等也加入這個陣營。
那個時候，這些顯然都是真正的應用平臺(aPaaS)，專門用于加速開發人員的速度和減少運營開銷。開發人員可自我配置以及管理他們開發的應用程序，這進一步壓縮從開發到發布到反饋到改進的周轉時間，進一步促進靈活軟件開發，并與新興的DevOps運動相結合。
但進步永遠不會停止，容器平臺應運而生。
▲基礎設施平臺上的容器平臺
容器平臺
容器化出現的時間可能比你想象的更長(FreeBSD Jails在2000年已經出現)，但可以肯定的是，容器化在Docker(2013年)結合Linux操作系統級虛擬化及文件系統鏡像才開始真正廣泛流行。這使得很容易構建和部署容器化應用程序，IaaS用戶熟悉這種模式，因為他們一直在構建磁盤鏡像來加速基礎設施平臺配置。但與虛擬機不同，容器允許你在本地部署完整的微服務堆棧，大大加快了開發周期。另外，由于開銷降低，每個微服務都可以有自己的容器鏡像、發布周期以及更新，這允許更小的團隊來同時開發。
從容器運行時到容器平臺是明顯的進步。CloudFoundry等應用平臺和Apache Mesos等集群資源管理器一直在透明地使用容器隔離。下一步是公開平臺API，允許開發人員部署日益流行的Docker鏡像。與基礎設施平臺一樣，容器平臺也是在內部部署開始，后來被提供為托管服務。Mesosphere的Marathon(2013年)是第一個通用容器開源平臺，但前面還有一些內部平臺，例如谷歌的Borg(大約2004年)以及Twitter的Aurora(2010年編寫;2013年開源化作為Apach Aurora)。
容器編排是容器平臺的核心。與應用平臺一樣，容器平臺需要提供聲明性基于約束的調度。但與應用平臺不同，容器不限于12因素應用。例如，狀態服務需要持久卷、隔離保證、特定域遷移過程、并置備份作業等。由于這種靈活性，容器平臺很容易變得比應用平臺更復雜，以支持更多類型的工作負載。
▲計算機集群上的容器平臺
為了增加靈活性，以及為了在沒有遷移的情況下支持傳統工作負載，很多人在基礎設施平臺上運行容器平臺，但這并不是絕對必要。容器足夠靠近幾乎所有工作負載兼容的單個機器，所以并非每個人都需要這種靈活性。很多開發人員將所有時間花在單層堆棧中，他們試圖想辦法避免重復任務(例如為每個新的應用手動制作容器鏡像)，為了滿足這個要求，功能平臺(也就是無服務器)隨之出現。
▲基礎設施平臺上容器平臺上的功能平臺
功能平臺
亞馬遜在2014年推出AWS Lambda，引發“無服務器”熱潮，AWS Lambda在其虛擬基礎設施平臺之上提供輕量級容器化事件處理。與其他亞馬遜云服務一樣，Lambda只有托管形式。隨后Iron.io(2014年)、Apache OpenWhisk(2016年)、Fission(2016年)、Galactic Fog的Gestalt(2016)、OpenLambda(2016)進入市場。
功能平臺的運行方式與應用平臺相同，它們還包括語言特定框架。因此，開發人員只需要使用平臺API來編寫事件處理程序以及映射觸發器到處理程序，而不需要通過多個端點來編寫應用程序。功能平臺通常整合API網關來處理代理、負載均衡以及集中式服務發現。與應用平臺不同，功能平臺透明地整合基于負載的自動縮放，因為它們可控制所有入口點和多路復用。
與容器平臺相同，功能平臺不一定需要基礎設施平臺，但與容器平臺提供的靈活性不同，功能平臺的設計不是為了支持各種工作負載。所以僅運行一個功能平臺可能不明智或者不可能，你還可能需要較低水平的容器或基礎設施平臺。有些功能平臺甚至被設計成與容器平臺整合，利用中間層自動化來降低上層的復雜性。
▲云計算平臺、接口及抽象規模
平臺抽象化
這些平臺層都提供自己獨特的抽象化和API，有些比其他層更抽象化。有些高級平臺具有自上至下的集成，但僅支持你運行的小部分工作負載。你可能會選擇最高層的抽象化來最大限度提高開發人員的速度，但你也必須考慮這些平臺上構建的軟件將與平臺緊密耦合，可能需要重復大部分工作，增加你的風險。在另一方面，較低級別平臺提供最大的靈活性，可支持最廣泛的工作負載，包括Web應用程序、微服務、舊巨集、數據管道和數據存儲服務。它們允許輕松遷移和更容易的基礎設施操作，但不一定可實現更容易地開發或操作應用、服務或作業。
應用平臺和基礎設施平臺之間的沖突是容器平臺受歡迎的重要原因之一。容器平臺允許你根據每個容器來決定你的工作負載是否需要自己的環境或者可作為二進制運行，支持更多種類的工作負載。它們還提供聲明性配置、生命周期管理、復制和調度，就像應用平臺。如果你還需要更高水平的抽象化，你可輕松地在容器平臺部署應用或功能平臺，與較低級別的工作負載共享資源和機器。如果你需要較低水平的抽象化，你可在基礎設施平臺之上部署容器平臺，而不是直接在裸機上構建。
▲DC/OS Architecture Layers
京公網安備 11010502049343號