摘要: Docker 相繼被 Azure 和 GCP 接納已經證明了雲計算資源場景化應用的需求所在,分散和割裂的雲端資源開始無法滿足企業使用者和運維的需求。 然而,FIT2CLOUD 的自動化覆蓋面更廣更深,也許
Docker 相繼被 Azure 和 GCP 接納已經證明了雲計算資源場景化應用的需求所在,分散和割裂的雲端資源開始無法滿足企業使用者和運維的需求。 然而,FIT2CLOUD 的自動化覆蓋面更廣更深,也許,你不再需要接觸 IaaS 的後臺。
雲存儲、雲虛機、資料庫、網站前後端程式部署...... 對於業務複雜、覆蓋範圍廣的公司而言,過多重複工作和割裂的後端平臺給他們很大的管理和維護負擔——這並不是雲計算概念興起的初衷。
先後在 MOTO、惠普、三星等跨國企業從事多年雲計算相關工作的阮志敏深諳其中的不便。 在這些輾轉任職期間,他也曾嘗試創業 PaaS 類產品,但 CloudFoundry 的迅速崛起讓他意識到自己的小公司步伐並不夠快。 這次以場景化雲中介軟體為切入點,解決自己在工作時作為使用者切身體會到的問題,他趕了個早集。
IaaS 的出現讓企業省去了採購和管理機器這類工作,而 PaaS 讓這個流程進一步精簡到「需求確認」和「應用開發」兩部分。 但在阮志敏看來,PaaS 的過度精簡讓客戶對技術細節的可控性降低,無法滿足定制化的細節需求。 FIT2CLOUD 的 IaaS + DevOps 模式是他為這個問題提供的解決方案:一個更全面、更深入的 "Docker"。 它的整合將虛機管理也包含在內,允許使用者根據應用場景和應用需求利用不同語言腳本來定義「軟體安裝」、「應用開發」、「應用部署」和「系統運維」在內的「應用全生命週期」自動化方案。
以博客為例,使用者可以定義虛擬機器數量/配置、儲存、資料庫、Wordpress 安裝為完整流程,一鍵開啟、複製,或在故障後進行重建。 此外,FIT2CLOUD 允許使用者對資源進行統一監控和分析,再按照監控資料制定資源的彈性伸縮腳本或閾值。
目前為止,FIT2CLOUD 支援 AWS、阿裡雲和青雲。 後續還會支援其它雲服務,但由於現階段人力原因,他們暫時專注于完善現有服務當中。 對大中型企業而言,業務範圍增加帶來的虛機規模會讓運維管理變得龐雜,需要將這些資源按照應用場景或具體業務分類才能讓這些雲端資源變得有序。 IaaS 服務商開放的 API 讓這一切成為可能。
根據阮志敏的描述,FIT2CLOUD 的雲端資源管理服務看重的是市場區隔內的剛性需求:對個人使用者而言,虛機數量屈指可數,人工管理也無礙;對於大型企業來說,他們內部工程師擁有自己的工具和足夠運維能力 ;但對於越來越大的中小創業公司群體而言,一站式的自動化全生命週期管理服務能可觀減少他們在運維方面的壓力和支出,從而專注于開發和產品。
外有 RigntScale、SCALR,內有 FIT2CLOUD、融雲(有類似功能)等,這類雲端資源管理是有成為雲計算統一後端潛質的。 他們具備跨虛機服務商、單服務商內跨機房、跨虛機、跨應用的全域管理能力。 接下來,FIT2CLOUD 會深度整合 Docker,不僅讓一鍵多虛機升級、補丁成為可能,也讓多虛機一鍵生產環境、應用部署/管理變得便捷。
其實拿 FIT2CLOUD 和 Docker 相提並論是一種不甚嚴謹的做法,因為 Cloud Source Management 和 Docker 覆蓋的範疇不可同日而語。 FIT2CLOUD 的雲端管理涵蓋創建資源、伺服器自動化、混合雲管理、應用自動化和持續交付整個縱深。 而 Docker 因為運行于虛機之內,只能實現應用自動化和持續交付,且其功能可以被 FIT2CLOUD 的腳本或 Chef 集成取代。
幾乎在同一時間,「雲計算資源場景化」的需求變得普遍。 大而全的功能不免顯得繁複,需要根據需求重新組合、排列才能滿足大規模應用、管理的前提。