PaaS、DevOps、OpenShift與業務中台的實現

導讀:在激烈的市場競爭條件下,企業既要進行業內的競爭,還要防止跨界黑馬殺進來被升維打擊而造成利潤下降,這就需要保持競爭力,需要讓自己的客戶有更好的體驗。

企業在通過IT手段提升業務競爭力和客戶體驗的時候,需要選一些比較新的技術架構和工具。正是由於PaaS、DevOps、微服務可以直接為業務帶來收益,因此受到了企業極大的重視。

接下來,我們將討論企業數字化轉型的步驟。

作者:魏新宇、郭躍軍

來源:大數據DT(ID:bigdatadt)

01 企業數字化轉型之PaaS

PaaS的全稱為Platform-as-a-Service,平台即服務。在Docker出現以前,企業IT的建設更多是圍繞IaaS進行的。而IaaS的基礎包括計算虛擬化、網絡虛擬化、存儲虛擬化,在此之上構建雲管平台。

在虛擬化層面,最為著名的公司當屬VMware。傳統UNIX服務器的落幕、x86服務器的崛起,很大程度得益於VMware公司的vSphere虛擬化技術。虛擬化中的高可用(HA)、在線遷移(vMotion)等特性,很大程度上彌補了(與UNIX服務器相比)早期x86服務器的穩定性相對較差的缺點。

2010年1月,OpenStack第一個版本發佈,開啟了開源界私有雲IaaS建設的熱潮。但在2012年Docker出現後,很多IT企業和行業客戶將IT的重點迅速從OpenStack轉向Docker,原因何在?

不管是vSphere還是OpenStack,其面向對象都是虛擬機。對於企業而言,虛擬化實現了操作系統和底層硬件的松耦合,但虛擬機承載的是操作系統,我們依然需要在操作系統中安裝應用軟件。

而Docker可以在容器中直接運行應用(如Tomcat容器鏡像),這比虛擬機更貼近於應用,更容易實現應用的快速申請和部署,極大地促進了容器雲PaaS的迅速發展。

到目前為止,絕大多數的企業級PaaS產品是以Docker、Kubernetes為核心的,紅帽(Red Hat)的OpenShift3也是如此。OpenShift4更進一步引入了CRI-O,這樣OpenShift可以承載更多容器運行時:runc(由Docker服務使用)、libpod(由Podman使用)或rkt(來自CoreOS)。

2018年第四季度,全球著名的調研機構Forrester對企業容器平台(ECP)軟件套件進行了評估,並確定了全球最重要的8個企業容器平台提供商:Docker、IBM、Mesosphere、Pivotal、Platform9、Rancher Labs、Red Hat和SUSE,參見圖1-1。

▲圖1-1 Forrester諮詢公司2018年第四季度發佈的企業容器平台調研報告

紅帽的OpenShift整體表現是非常優秀的(Red Hat處於Leaders象限且Market presence較高)。

02 PaaS、DevOps與微服務的關係

PaaS、DevOps、微服務的概念很早就出現了。廣義上的微服務和DevOps的建設包含人、流程、工具等多方面內容。IT廠商提供的微服務和DevOps主要是指工具層面的落地和流程諮詢。

在Kubernetes和容器普及之前,我們通過虛擬機也可以實現微服務、DevOps(CI/CD),只是速度相對較慢,因此普及性不高(想像一下通過x86虛擬化來實現中間件集群彈性伸縮的效率)。而正是容器的出現,為PaaS、DevOps工具層面的落地提供了非常好的承載平台,使得這兩年容器雲平颱風生水起。

這就好比4G(2014年出現)和微信(2011年出現)之間的關係:在3G時代,流量費較貴,大家對於微信語音聊天、微信視頻也不會太感興趣。到了4G時代,網速提高而且收費大幅下降,像微信這樣的社交和互聯網支付工具才能興起和流行。

Docker使容器具備了較好的可操作性和可移植性,Kubernetes使容器具備企業級使用的條件。而IT界優秀的企業級容器雲平台——OpenShift,又成為DevOps和微服務落地的新一代平台。

OpenShift以容器技術和Kubernetes為基礎,在此之上擴展提供了軟件定義網絡、軟件定義存儲、權限管理、企業級鏡像倉庫、統一入口路由、持續集成流程(S2I/Jenkins)、統一管理控制台、監控日誌等功能,形成覆蓋整個軟件生命周期的解決方案。

所以說,OpenShift本身提供開箱即用的PaaS功能,還可以幫助客戶快速實現微服務和DevOps,並且提供對應的企業級服務支持。

03 企業數字化轉型之DevOps

DevOps中的Dev指的是Development,Ops指的是Operations,用一句話來說,DevOps就是打通開發運維的壁壘,實現開發運維一體化。

1. 從瀑布式開發到敏捷開發

談到DevOps的發展史,我們需要先談一下敏捷開發。

軟件工程的方式有其優點,但也帶來了不少問題。最關鍵的一點是:軟件不同於工程。通過工程學建造的大橋、高樓在竣工後,人們通常不會對大橋或高樓的主體有大量使用需求的變更;但軟件卻不同。

對於面向最終用戶的軟件,人們對於軟件功能的需求是會不斷變化的。在瀑布式開發模式下,當客戶需求發生變化時,軟件廠商需要修改軟件,這將會使企業的競爭力大幅下降。

傳統的軟件開發流程是:產品經理收集一線業務部門和客戶的需求,這些需求可能是新功能需求,也可能是對產品現有功能做變更的需求。然後進行評估、分析,將這些需求制定為產品的路線圖,並且分配相應的資源進行相關工作。

接下來,產品經理將需求輸出給開發部門,開發工程師寫代碼。寫好以後,就由不同部門的人員進行後續的代碼構建、質量檢驗、集成測試、用戶驗收測試,最後交給生產部門。

這樣帶來的問題是,開發周期比較長,並且如果有任何變更,都要重新走一遍開發流程,在商場如戰場的今天,軟件一個版本推遲發佈,可能到發佈時這個版本在市場上就已經過時了;而競爭對手很可能由於在新軟件發佈上快了一步,而迅速搶佔了客戶和市場。

正是由於商業環境的壓力,軟件廠商需要改進開發方式。

2001年年初,在美國猶他州滑雪勝地雪鳥城(Snowbird),17位專家聚集在一起,概括了一些可以讓軟件開發團隊更具有快速工作、適應變化的價值觀的原則,制定並簽署了軟件行業歷史上最重要的文件之一:敏捷宣言。

敏捷宣言中的主要價值觀如下:

  • 個體和互動高於流程和文檔。
  • 工作的軟件高於詳盡的文檔。
  • 客戶合作高於合同談判。
  • 響應變化高於遵循計劃。

有了敏捷宣言和敏捷開發價值觀,必然會產生對應的開發流派。主要的敏捷開發流派有極限編程(XP)、Scrum、水晶方法等。至此,敏捷開發有理念、有方法、有實踐。隨着雲計算概念的興起以及雲計算的不斷落地,敏捷開發也實現了工具化。

2. 從敏捷開發到DevOps

談到了敏捷開發,那麼敏捷開發和DevOps有什麼關係呢?敏捷開發是開發領域裏的概念(上文已經介紹),以敏捷開發階段為基礎,有如下階段:

敏捷開發→持續集成→持續交付→持續部署→DevOps

從敏捷開發到DevOps,前一個階段都是後一個階段的基礎;隨着階段的推進,每個階段概念覆蓋的流程越來越多;最終DevOps涵蓋了整個開發和運維階段。正是由於每個階段涉及的範圍不同,因此每個概念所提供的工具也是不一樣的。具體內容參照圖1-2。

▲圖1-2 從敏捷開發到DevOps的進階

  • 持續集成(Continuous Integration):代碼集成到主幹之前,必須全部通過自動化測試;只要有一個測試用例失敗,就不能集成。持續集成要實現的目標是:在保持高質量的基礎上,讓產品可以快速迭代。
  • 持續交付(Continuous Delivery):開發人員頻繁地將軟件的新版本交付給質量團隊或者用戶,以供評審。如果通過評審,代碼就被發佈。如果未通過評審,那麼需要變更後再提交。
  • 持續部署(Continuous Deployment):代碼通過評審並發佈後,自動部署到生產環境,以交付最終用戶使用。

DevOps是一組完整的實踐,涵蓋自動化軟件開發和IT團隊之間的流程,以便他們可以更快、更可靠地構建、測試和發佈軟件。

04 企業數字化轉型的實現

1. 企業業務中台的建設

近兩年,很多國內的企業都在談業務中台建設。那麼,什麼是業務中台?實際上,業務中台是相對於「前台」和「後台」而言的。

前台由各類業務系統前端平台組成。每個前台系統就是用戶接入點,即企業的最終用戶直接使用或交互的系統。如網站、手機App、微信公眾號等。前台是以用戶為中心的互聯網敏態業務。互聯網公司先有前台業務,通過將通用業務下沉形成業務中台。

後台是企業的核心業務系統,例如財務系統、倉庫物流管理系統等,這類系統構成了企業的後台。後台承載穩態業務。相比於互聯網公司,企業客戶先有傳統業務系統,後有互聯網+業務。由於後台更多的是保證核心業務的穩定運行,它並不能很好地支撐前台快速創新響應用戶的需求。

但在目前階段,對於企業而言,客戶的體驗又是非常重要的,因此企業通過建設中台解決前台的創新問題。通過構建中台,企業將後端業務資源服務化,用以支撐前端全渠道業務、互聯網業務和以客戶為中心的敏態業務,如圖1-3所示。

▲圖1-3 業務中台的實現方式

整個業務中台的全景圖,將包含PaaS平台、DevOps、微服務治理以及微服務API管理、分佈式集成與流程自動化,如圖1-4所示。

▲圖1-4 業務中台全景圖

接下來,我們介紹企業數字化轉型的步驟。

2. 企業數字化轉型步驟

筆者在日常工作中,接觸了大量企業客戶數字化轉型的案例,歸納整理出通常的轉型步驟,如圖1-5所示。

▲圖1-5 企業轉型步驟

圖中的縱坐標為業務敏捷性,企業業務敏捷性方面的轉型通常包含以下幾步:

  • 第一步:構建PaaS平台。PaaS平台為開發人員提供了構建應用程序的環境,旨在加快應用開發的速度,實現平台即服務,使業務敏捷且具有彈性。近幾年容器技術的崛起更是促進了PaaS的發展,紅帽OpenShift就是首屈一指的企業級容器PaaS平台。
  • 第二步:基於PaaS實現DevOps。PaaS平台是通過提高基礎設施的敏捷而加快業務的敏捷,而DevOps則是在流程交付上加快業務的敏捷。通過DevOps可以實現應用的持續集成、持續交付,加速價值流交付,實現業務的快速迭代。
  • 第三步:實現微服務治理。通過對業務進行微服務化改造,將複雜業務分解為小的單元,不同單元之間松耦合、支持獨立部署更新,真正從業務層面提升敏捷性。在微服務的實現上,客戶可以選擇採用Spring Cloud,但我們認為Istio是微服務治理架構的未來方向。
  • 第四步:實現微服務高級管理。在微服務之上實現API管理、微服務的分佈式集成以及微服務的流程自動化。通過API管理幫助企業打造多渠道的生態,最終實現API經濟。通過微服務的分佈式集成和流程自動化,企業可實現統一的業務中台。

圖中橫坐標是業務健壯性的提升,通常建設步驟為:

  • 第一步:建設單數據中心。大多數企業級客戶,如金融、電信和能源客戶的業務系統運行在企業數據中心內部的私有雲。在數據中心建設初期,通常是單數據中心。
  • 第二步:建設多數據中心。隨着業務規模的擴張和重要性的提升,企業通常會建設災備或者雙活數據中心,這樣可以保證當一個數據中心出現整體故障時,業務不會受到影響。
  • 第三步:構建混合雲。隨着公有雲的普及,很多企業級客戶,尤其是製造行業的客戶,開始將一些前端業務系統向公有雲遷移,這樣客戶的IT基礎架構最終成為混合雲的模式。

企業的IT基礎架構與業務系統是相輔相成的。在筆者看到的客戶案例中,很多客戶都是兩者同步建設,實現基於混合雲的PaaS、DevOps和微服務,並最終實現基於混合雲構建企業業務中台。

關於作者:魏新宇,現為紅帽資深解決方案架構師。在IaaS PaaS方面有豐富的經驗,致力於開源解決方案在企業中的推廣和應用。從售前角度主導了紅帽在金融 汽車行業PaaS多個項目。

郭躍軍,現為yamaxun AWS專業服務團隊雲架構諮詢顧問。在2019年4月之前任職於Red Hat,擔任PaaS諮詢顧問。從2015年接觸容器技術並開始學習OpenShift,參與了很多OpenShift項目的競標PoC 諮詢和落地實施,幫助很多企業實現了數字化轉型。

本文摘編自《OpenShift在企業中的實踐:PaaS DevOps微服務》,經出版方授權發佈。

延伸閱讀《OpenShift在企業中的實踐》

推薦語:多位全球知名企業IT負責人聯名推薦,兩位紅帽和AWS雲計算和微服務資深架構師和技術專家合著,從實戰角度全面剖析OpenShift和DevOps和微服務技術。適讀人群 :本書適用於有一定 OpenShift/Kubernetes 基礎的讀者、企業的架構師、IT 經理、應用架構師、開源技術愛好者。