當云計算走向原生需求 IT基礎架構該如何升級?
云原生已成為企業在部署業務時的主要選擇之一,其好處在于應用可以直接基于云架構設計和開發,像12原則(The Twelve-Factor App)在基準代碼、端口服務、流程日志等方面也為云原生下了進一步的定義。不過從另一方面看,云原生也不是絕對的一本萬利,其仍有一些成本因素是不容忽視的。
云原生是Pivotal負責架構的全球CTO Matt Stine在2013年提出的概念,當時的判斷像DevOps、微服務、敏捷交付等技術至今都已成為趨勢。當時Matt Stine認為,如果用新的一體性架構去取代現有的一體性架構,只是把復雜性從一端轉移到了另一端,這也是傳統SOA的尷尬之處,“從運維的角度來看,實際上什么都沒做。”對于企業來說,有必要對舊有的業務進行重構。
根據CNCF的定義:云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中,構建和運行可彈性擴展的應用,容器、服務網格、微服務、不可變基礎實施和聲明式API……都是云原生的代表性技術,其優勢在于可以很好地構建容錯性好、易于管理、便于觀察的松耦合系統。結合可靠的自動化手段,云原生技術使工程師能夠輕松對系統作出頻繁、可預測的重大變更。
2020云棲大會期間,阿里巴巴就宣布成立了云原生技術委員會, 此次委員會的成立,也意味著阿里已經將云原生升級為新的技術戰略方向。阿里巴巴認為,云原生是一種新型技術體系,被視為云計算未來的發展方向。云原生應用也就是面向“云”而設計的應用,在使用云原生技術后,開發者無需考慮底層的技術實現,只需做好自己的業務,就可以充分發揮云平臺的彈性+分布式優勢,實現快速部署、按需伸縮、不停機交付等。
事實上,早在2018年4月敲下第一行代碼開始,KubeSphere的定位就是一個面向云原生設計的開源項目,在主流容器調度平臺Kubernetes之上構建的分布式多租戶容器管理平臺,提供簡單易用的操作界面以及向導式操作方式,在降低用戶使用容器調度平臺學習成本的同時,大幅降低開發、測試、運維的日常工作的復雜度。
如今,應用現代化是IT部門的首要任務,紅帽OpenShift基于現代化應用基礎架構的事實標準Kubernetes構建,為這一轉型過程提供了強大且可擴展的平臺。正如物理管理工具及流程不適用于虛擬化環境,專為虛擬機管理而設計的工具也不適用于當今的云原生、容器化世界。用于Kubernetes的紅帽高級集群管理能夠很好地滿足這一需求,其為云原生環境量身定制的新一代管理能力,能夠幫助企業利用紅帽OpenShift做更多事情。
無論是剛剛開始探索云原生計算的企業,還是已在生產環境中運行下一代工作負載的企業,用于Kubernetes的紅帽高級集群管理都能為他們提供支持跨集群進行容器化應用部署的工具。它可以滿足企業在容器化進程中的現有需求,幫助解決企業管理多個集群的迫切問題,同時提供策略執行和治理控制等未來就緒的能力。
與此同時,IT基礎架構也在面臨著升級。通過與不少行業客戶接觸,他們的多數新應用都是在云中構建,而且這些企業可能是IT互聯網、金融、教育、工業、交通運輸等領域,可見云原生在各行各業的普遍性。有一項調查顯示,在已經部署云原生的公司中,基于云來構建的應用比例會在近幾年攀升到70%-80%,而背后的一大顧慮就是安全性。這意味著,如果是自行從零構建云原生架構是有不少成本的,因此企業客戶多數會選擇與云服務商合作。
一些報告顯示,規模越大的企業通常更傾向于選擇云原生,但有意思的一點是像那些營收超過200億美元的更大型的企業,往往會比較保守,他們使用云原生的比例甚至不到25%。這一現象與企業上云的思路類似,即對數據丟失、系統故障等問題的擔心,包括受限于監管因素只得將關鍵業務應用放在私有環境。
除了安全性,企業在將業務遷移上云的過程中也會遇到其他的“額外”成本,例如可能會需要對應用進行部分或完全重構,以調用完整的云原生功能,這種重構不僅涉及重寫,還會有后續一系列的測試、上線、交付,以及工具調用,這些往往加起來會超過企業最初的預算。
由此可以引申的一點是,云原生架構與行業是具有一定相關性的。例如金融行業,異地多活、無損容災、開放的API都是必備要素,可以方便客戶進行二次開發。這一過程中,需要金融服務商提供一些定制化的能力,像螞蟻金服的SOFA——金融級中間件產品技術和演進式架構轉型服務體系,而且該體系內的各個組件都是向社區開源的。
無論是云原生、DevOps還是微服務和容器,都是在為業務上云時提供的敏捷手段,而背后所涉及的現代化IT基礎架構升級,則會讓企業收益持續實現最大化。