花旗全球數位暨雲端科技董事總經理Brad MillerBrad Miller表示,舊有平臺龐大又封閉,必須打破此架構,走向微服務平臺。而他的做法是將系統拆解成UI層、服務層以及後端資料,先替微服務建立起邊界。圖片來源/Pivotal

天下大勢合久必分,分久必合,相同的典範轉移,也可以在企業IT架構看見。早期IT架構強調集中化管理,工作負載在各分支運算完畢,批次回傳至中樞管理機構。到了私有雲時代,以虛擬化技術為基礎,將運算資源抽象化成資源池,應用程式與底層基礎架構的相依性變得更低。

現在則是行動應用優先的時代,雲端技術愈發成熟,雲端原生應用程式成IT大廠的新寵兒,將應用程式的顆粒度切的更細緻,讓它適用雲端環境的水平擴充,應付突如其來的流量。再者,這些拆分如積木樂高般的應用程式,已經擺脫過去龐大單套式架構(Monolithic)架構,演化成微服務架構(Microservice)。

根據Gartner去年釋出的調查,微服務及容器共同被列入未來10大具有影響力的技術趨勢。確實,微服務的架構興起,也與容器技術的演進有著淵源。Gartner表示,容器技術讓開發者可以更容易隔離各程序的運作,「非常適合用於開發微服務」,而現代應用程式利用輕量級虛擬化容器技術的進展,打破底層基礎架構的相依性,因此提升了重複使用性。同時Gartner也認為:「微服務可以獨自管理、部署」,因此,仰賴容器技術的快速建置、派送的特性,使得微服務應用程式也能隨需擴充。

科技大廠也紛紛靠以微服務為中心,推出對應解決方案,像是Google、IBM及Lyft就在今年攜手發布了微服務管理平臺Istio;微軟則是主打Azure Fabric Service,讓開發者更容易建置、開發微服務;主打PaaS的紅帽跟Pivotal也支援Docker、Kubernetes,讓應用程式可以用容器型態部署、打包,派送至雲端執行;Mesosphere也推出資料中心作業系統DC/OS不僅可作為微服務執行平臺,而其本身就是以許多開源軟體組成的微服務架構。

力推微服務架構的廠商,恰好也跟原生雲端運算基金會(CNCF)的核心成員相當重疊。該基金會主導許多重要專案,包含容器調度工具Kubernetes、容器Runtime containerd及rkt。

而該理事會組主席是IBM開放技術副總裁Todd Moore,成員更有Google雲端平臺產品副總裁Sam Ramji、Kubernetes專案共同創辦人Craig McLuckie、紅帽副總裁暨首席技術專家Chris Wright。更甚,主導CNCF技術走向的技術委員會,當中也有許多業界的重量級人士,像是Docker技術長Solomon Hykes、Joyent技術長Bryan Cantrill,以及Mesosphere共同創辦人Benjamin Hindman。

各廠商分別調派人馬至雲端原生運算基金會,一同主導重要開源專案的走向,也可以觀察到容器技術的確對雲端原生運算有舉足輕重影響。再者,處在雲端原生時代,微服務是實現該架構的重要手段,在此卡位,更能早一步比其他廠商更洞悉未來市場動向,也能化被動為主動,左右微服務架構的發展。

不過,大型企業首要目標是力求營運穩定,也常導致一門新技術、新架構是叫好不叫座,是否有性質相同、規模相仿的企業使用,也變成公司高層是否導入這門新技術的決策判斷標準。

誠然,大型企業如Netflix、Uber、eBay或是Spotify都已率先導入微服務架構,不過其先天體質就是以提供網路服務為主,系統架構並不如一併提供實體服務、網路服務的業者複雜。

再者,其成立時間都相較老牌企業短,系統包袱較少,在架構調整上有著更大彈性及優勢。不過,這也不意味傳統企業就必須要坐以待斃,將既有打下的疆土拱手讓人。成立於1812年美國紐約州的花旗銀行(Citibank),已經營運超過200年,近年銀行業務也會碰上來自金融科技的挑戰,甚至遭受顛覆,複雜龐大的系統,讓開發團隊很難快速將產品推上市場。

200年銀行導微服務也不嫌晚

因此,花旗消費者銀行業務執行長Stephen Bird就承諾花旗必須轉型,他表示,為了讓花旗能持續成長,除了必須保持開放,不停學習新事物外,「必須願意快速地經歷失敗(fail fast and fail small),這是花旗企業文化中的重要核心,不僅能激起創新,還能更即時地交付價值給用戶。」因應執行長所喊出的轉型願景,執掌花旗雲端平臺的花旗全球數位暨雲端科技董事總經理Brad Miller,在2016年開始推動花旗IT架構微服務化的大轉型,「花旗是家從事銀行業的科技公司,從客戶角度出發思考,而非依循傳統的銀行業思維。」

「我正面臨一個大(Monolithic)問題!」Brad Miller的一語雙關,正點出單套式(Monolithic)架構是企業轉型碰上的大麻煩,而花旗銀行的包袱不只如此,像封閉式基礎架構、步調緩慢瀑布式開發,還有面對改變的內部阻力,「只因為某些實施超過25年不變的規定,許多人也不願改變現狀。」這些老舊包袱讓開發團隊痛苦不堪,想要推出更多新功能,「一年只能發布4次。」

而Brad Miller所提出的轉型總共鎖定三大目標:人、維運工作方法以及技術平臺。 「銀行組織很大,別認為轉型可以一次到位」,反之,Brad Miller先成立了一個創新團隊,部署了76名開發人員,負責開發全新的應用程式,在2016年底,該團隊負責的資產管理系統也已經上線。他表示,這個團隊的目的就是挑戰內部既有規則,「為花旗打造新輪子,繼續向前進。」

同時,Brad Miller也大幅調整正職員工、約聘員工的比例。在2016年,他領導的團隊總共有80%為約聘人員,但他計畫在2017年要讓正職員工占其中80%,「雖然風險很高,但是得要讓開發團隊有自主權,從錯誤中學習,藉此建立更強大的團隊。」

第二個轉型目標則是導入敏捷維運工作,改變現有維運工作模式。Brad Miller表示,讓敏捷開發團隊與該業務系統負責人一同工作,直接溝通系統相容性、資安要求、法規,「藉此程式碼的交付速度可以快上57%。」不過他表示,現階段CI/CD流程還未建置完畢,而花旗銀行的下個計畫,就是要導入開發維運一體化的DevOps。

系統架構健全才能享受雲端的優點

而重頭戲就是花旗銀行老舊平臺的重整任務,不僅龐大又封閉,「我們要打破如此架構,走向微服務平臺,加速產品交付速度」,Brad Miller的計畫,就是將系統拆解成UI層、服務層以及後端資料,先替微服務畫起各服務邊界。不過他提醒,許多企業的應用程式平臺架構不良,即使把平臺切成微服務架構,「搬上雲端也不會讓系統變得更好」

而平臺重構的策略,Brad Miller分別從業務端、開發端兩頭一起並進。他解釋,從業務切入是一種由上而下(Top-down)的策略,重新建立投資、信用卡、銀行的業務模型。反之,開發端則是由下而上(Bottom-up),讓開發團隊重構(Refactoring)既有程式碼。

再來,就是根據需求開發新業務應用程式,「其中很重要的是建立服務代辦清單(Service Catalog)」,Brad Miller表示,花旗銀行在全世界都有開發團隊,在推動微服務架構轉型時,必須要讓各地團隊都清楚彼此的開發進度,「不能出現冗贅、重複的應用程式。」

在推展微服務的同時,Brad Miller也要整併花旗銀行既有的多層式架構應用程式,首要任務就是讓後端系統解耦合(Decouple),並且建立新前端服務,「擺脫不重要的後端服務,讓重要的新服務可以快速上線。」

從2016年初推行轉型,8個月後,花旗銀行享受到豐厚的果實。原本每季只能發布一個新版本,已經進步到每個月都釋出新版,「相比同年,交付速度快了3倍。」Brad Miller更表示,因應數位轉型的需求,原本規模300人的敏捷團隊,從2016年8月起,更要擴編至1,200位開發者。

速度,不再只是新創公司的專利,連花旗銀行這家成立2世紀的老牌銀行,以微服務架構為基礎,重新翻轉自己,順利展開數位轉型,也能像新興科技公司那樣,不斷快速嘗試創新,找出銀行業務的新出路。


Advertisement

更多 iThome相關內容