探索各類雲平臺，幫您找到最適合您的那一款！無論您是購買、從零開始搭建還是採用開源技術，您可能已經在使用某種軟體平臺來構建，部署和擴充套件應用程式。
一個平臺的誕生必定是經年錘煉而來，即從應用程式中提取通用的功能到更底層的抽象中。如果完成了既定的設計意圖，那麼您將得到一個可用的平臺，反之，您將得到一個“燙手山芋”，既而您將再次尋找合適的平臺，這時候您會發現別人已經構建好的平臺給您帶來了一線希望的曙光。
正確的平臺，您將在靈活性和簡單性之間達到您所需要的平衡，從而使您能夠更快速地構建而不受太多限制。本文將探討雲平臺的範圍，以幫助您找到最適合您的那一款。
對於什麼樣的平臺才是完美的，每個人有每個人的看法，因為每個人的使用場景有所不同。但是幾乎所有人都尋求以下兩個特徵：
這兩個要求推動了大多數軟體平臺的投資。真的，這兩項可以作為自動化任何事情的檢驗標準。
所以，沒有一個平臺對於任何使用者來說是完美的，那麼是否意味著我們要自己寫呢？如果自己寫，是否建立在一個現有的平臺之上？您想要一個從上到下的緊密整合的平臺，還是想要使用強大的擴充套件點鬆散連線的多層平臺？
這些都是一時間難以回答的問題，並沒有一個真正適合每個人的單一答案。尋找合適平臺的成就感是發現，比較和權衡之一。所以我們一起來吧！
每個廠商都會告訴你，他們的軟體是特別的，甚至是獨一無二的。他們都在努力區分產品，以提供不可替代的價值。但是，如果您仔細觀察，並容忍一些粗糙的邊緣，您可以根據它們提供的介面型別對這些產品進行分組。
術語“軟體即服務”一詞最早可追溯到2000年左右，指的是將打包的軟體產品和支援服務捆綁在託管解決方案中，以避免經常未知的執行和操作成本。一個SaaS產品本身就是一個基礎上的平臺。術語描述的一些原始用途取代了傳統企業資源計劃(ERP)和客戶關係管理(CRM)平臺。
像Salesforce和SAP這樣的公司，對於那些沒有大型工程師團隊或IT部門來構建和管理這些複雜的系統客戶，他們會在這些領域非常成功。即使是擁有這些資源的公司也可能認為這些事情不在其核心競爭力範圍之內，不值得自己去建設或經營。如今幾乎所有類別的軟體都可以透過SaaS獲得，從電子郵件到文書處理系統，再到內容管理系統比比皆是。
基礎設施平臺在SaaS之後不久就出現了。VMware GSX Server(2006)和亞馬遜彈性計算雲(EC2，2006)提供了早期的虛擬化平臺。然而，VMWare最初專註在企業內部部署，亞馬遜web服務則將其託管的IaaS和SaaS產品結合，定位於更廣闊的市場。後來，Rackspace和美國航天局開發了OpenStack (2010)作為VMware vSphere (2009年釋出，取代GSX)和亞馬遜EC2的開源競爭對手。
這些IaaS主要提供了一些具體的抽象：虛擬機器計算節點，軟體定義的網路和可掛載的儲存。在有SaaS的情況下，託管的IaaS的主要賣點是外部資源容量配置操作的自動化，但與SaaS不同，託管的IaaS會給使用者帶來資源規模無限大的錯覺。對於大多數對基礎設施外包感興趣的公司來說，AWS會提供比客戶以往任何時候資源需求量大得多的資源，在您向AWS尋求更多節點之前，已經擴充套件了資料中心。對於無法或者不願意外包的公司，像OpenStack和vSphere這樣的基礎設施平臺可以在您選擇的資料中心中託管自己的雲。
然而，管理不僅僅只是涉及硬體，還包括管理一個基礎設施平臺，並且這需要更多的工作，這是企業公司已經在自己的平臺上做過的。無論是手動管理沒有虛擬化層的硬體，還是渴望使配置更加自助化。因此，X即服務樣式是圓滿的：託管的平臺成為了打包的產品，此次增加的多租戶功能，允許客戶自己的內部使用者群體進行操作。
Fotango的Zimki(2006)和Heroku(2007)率先使用平臺即服務。後來的Google App Engine（2008），CloudFoundry（2011）和其他幾個加入了戰鬥。在當時，很明顯，這些是真正的應用平臺（aPaaS），專門用於加快開發人員的速度並降低運營開銷。使得開發人員自己配置和管理他們開發的應用，進一步壓縮了從開始到釋出到反饋到迭代的周轉時間，與日益普及的敏捷軟體開發思想相契合，併為剛剛起步的DevOps運動播下種子。
容器化已經比您想象得要深入（FreeBSD Jails自2000年以來一直在使用），但是可以肯定的是直到Docker（2013）將Linux作業系統級虛擬化與檔案系統映象結合起來，容器化才真正廣泛流行起來。這使得構建和部署容器化應用更加容易，這是一種可以理解為透過構建磁碟映象來加快基礎設施平臺配置的IaaS使用者樣式。但與VM相比，同時執行的幾臺驅動器足以讓您的工作站超負荷執行，容器則允許您在本地部署完整的微服務堆疊，大大加快了開發週期。另外，由於降低了開銷，每個微伺服器都可以擁有自己的容器映像，自己的釋出週期和自己的滾動升級，允許更小的團隊並行開發它們。
從容器執行時到容器平臺，這是一個明顯的進步。像CloudFoundry這樣的應用平臺和像Apache Mesos這樣的叢集資源管理系統自成立以來就一直使用容器隔離。下一步是公開一個平臺API，允許開發人員在一組機器上部署越來越受歡迎的Docker映象。像基礎設施平臺一樣，容器平臺也是在內部開始的，後來提供託管服務。
Mesosphere的Marathon（2013）是通用容器編排的首個開源平臺之一，但它早期是由內部努力推動的，比如Google的Borg（〜2004）和Twitter的Aurora（2010年寫成，在2013年開放為Apache Aurora）。
容器編排是容器平臺的核心。與應用平臺一樣，容器平臺需要提供基於約束的宣告性排程。與應用平臺不同的是，容器不限於十二要素應用程式。比如，有狀態服務需要的持久捲，隔離保證機制，特定域的遷移過程及並行的備份作業等等。由於這種靈活性，容器平臺可以輕鬆地變得比應用程式平臺更複雜，以支援更多種類的工作負載。
為了增加靈活性，並且在不遷移的情況下支援傳統工作負載，許多人在基礎設施平臺之上執行容器平臺，但這並不是絕對必要的。容器與單個機器已經十分接近，幾乎所有的工作負載都是相容的。所以並不是每個人都需要這種靈活性。許多開發人員將他們所有的時間都花在單層的堆疊中。他們尋找避免重覆執行任務的辦法，例如為他們構建的每個新應用程式手工製作容器映象。對於這些人來說，功能平臺（也稱為無伺服器）就出現了。
基礎架構平臺上的容器平臺，容器平臺上的功能平臺
亞馬遜推出了AWS Lambda（2014），引領了無服務的“熱潮”，在其虛擬基礎設施平臺之上提供輕量級的容器化事件處理。像其他Amazon Web Services一樣，Lambda僅僅只是一種託管服務。
因此，由Iron.io(2014)，Apache OpenWhisk(2016)，Fission(2016)，Galactic Fog的Gestalt(2016)，OpenLambda（2016）填補了私有化部署替代品的市場。
除了他們各自基於特定語言的框架之外，功能平臺的執行方式與應用平臺相同。因此，開發人員只需要開發事件處理程式，並使用平臺API將觸發器對映到該處理程式即可，而不是使用多個端點編寫應用程式。功能平臺通常與API閘道器配合或整合，以處理代理，負載均衡和集中式服務發現。與應用平臺不同，功能平臺透明地集成了基於負載的自動縮放，因為它們控制所有入口點和復用。
像容器平臺一樣，功能平臺不一定需要基礎架構平臺，但與容器平臺提供的靈活性不同，功能平臺不是設計用於支援各種各樣的工作負載。所以僅僅只執行一個功能平臺可能是不明智的或不可能的。您可能還需要一個較低階別的容器或基礎架構平臺。一些功能平臺甚至被設計成與容器平臺整合，利用中間層自動化來降低較高層的複雜性。
這些平臺中的每一層都提供了自己獨特的抽象和API，某些層比其他層更抽象。一些更高層級的平臺要麼全部採用，要麼就全不用。它們具有頂部到底部的整合，但只能支援您要執行的一小部分工作負載。您可能會嘗試選擇最高層的抽象化來最大限度地提高開發人員的速度，但是您也必須考慮到這些平臺上構建的軟體將與平臺最緊密耦合，當您需要重新選擇平臺的時候， 這將增加您的風險。另一方面，較低階別的平臺可以提供最大的靈活性，可以實現最廣泛的工作負載，包括Web應用程式，微伺服器，過時的整體架構應用，資料管道和資料儲存服務。它們使得遷移更輕鬆和基礎設施操作更容易，但是在上面實際開發或運維應用程式，服務或作業卻更難。
應用平臺和基礎設施平臺之間的衝突是容器平臺受歡迎的重要原因之一。容器平臺在這兩方面作出了妥協。它們允許您根據每個容器來決定您的工作負載是否需要自己的環境，或者可以作為二進位制執行，支援更多種類的工作負載。但它們還像應用程式平臺一樣提供宣告式配置，生命週期管理，複製和排程。如果您還需要更高層次的抽象，您可以輕鬆地在容器平臺之上部署更輕量級的應用程式或功能平臺，共享具有較低階別工作負載的資源和機器。如果您還需要較低階別的抽象，您可以輕鬆地在基礎設施平臺之上部署容器平臺，而不是直接使用裸機。
在Mesosphere，我們的使命就是讓它非常容易建立和擴充套件規模到足以改變世界的技術。這意味著我們不僅僅服務於開發人員，也不僅僅是運營商，而是二者皆有。幫助您實現真正的敏捷性，既需要開發人員的速度和也需要運維人員的靈活性。開發人員希望減少重覆工作，自動化的彈性，並建立在強大的平臺服務之上。運維人員希望可見性，避免供應商鎖定，以及控製成本的能力。因此，我們構建了DC/OS，以提供基於雲的服務和開放的合作伙伴生態系統，與基礎設施無關的容器平臺。透過DC/OS，您可以獲得一個堅實的容器平臺，加上更高階別服務的目錄：資料庫，佇列，自動化測試，持續交付流水線，日誌記錄和指標堆疊，彈性擴容及功能平臺等。
文章譯者：付輝(DockOne社群翻譯)，原文連結：https://mesosphere.com/blog/iaas-vs-caas-vs-paas-vs-faas/
溫馨提示：
請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號，點選原文連結獲取電子書詳情。
求知若渴, 虛心若愚
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球