當前位置:
首頁 > 知識 > K8s有多熱?傳統銀行轉型擁抱Kubernetes案例

K8s有多熱?傳統銀行轉型擁抱Kubernetes案例

Kubernetes已經成為標準的基礎設施API,像Red Hat、Mesosphere(現在的D2IQ)和Pivotal等供應商都無法避免。如果您希望使企業能夠合理構建應用程序,那麼Kubernetes是最佳選擇。

CNCF在2018年的一項調查中發現,在實際生產中使用Kubernetes的企業佔40%。剩下60%沒有使用Kubernetes的企業中,有部分是追求極高安全性並且厭惡高風險的銀行業。作為垂直行業,傳統銀行不像它們的對沖基金和兄弟交易公司那樣不斷尋求優勢,除非迫不得已,否則它們一般不會跨越技術鴻溝,目前很多銀行仍然在30年前的大型機技術上運行他們的ATM網路。

Kubernetes正在改變這一點。曾經有ING擁抱Kubernetes,但是該用例遵循了DevOps社區中其他早期採用者的做法。容器和編排對於改進CI/CD非常有效,但是傳統的銀行會在這項年輕的技術上運行其真正的核心業務嗎?

K8s有多熱?傳統銀行轉型擁抱Kubernetes案例

打開今日頭條,查看更多圖片

似乎是為了印證Kubernetes變得炙手可熱,有家義大利銀行正在嘗試使用Kubernetes。或許我們可以從中看到Kubernetes為什麼這樣受企業青睞。

數字化改造的方式

Banca Intesa Sanpaolo是在2007年通過Banca Intesa和Sanpaolo IMI的合併而成立,是義大利最大的銀行,也是歐洲最大的銀行之一,市值340億美元。該銀行總部位於都靈,擁有5000多個分支機構,為歐洲和中東十幾個國家的約1900萬客戶提供服務,並在全球超過25個國家和地區提供支持。

2018年,該銀行啟動了一項戰略性數字化轉型計劃,稱為「通過創新進行數字架構再造工程」。 該策略是採用微服務和容器架構,並從單片應用程序遷移到多層應用程序。目標是加快開發周期,縮小應用程序以獲得更大的靈活性,並提高可擴展性和可靠性。該銀行的IT部門正在轉變為一家基於現代CI / CD實踐的軟體公司。

該計劃的核心是運行由Kubernetes管理的容器挑戰。

該銀行首先通過在其傳統虛擬機(VM)基礎架構上運行試驗容器項目來對其進行測試。 那些飛行員是成功的,但銀行想看看它是否可以在裸機上運行Kubernetes和容器。 它是否可以利用性能優勢並避免支付VM許可證的開銷?

這並不是一個小決定,因為裸機和Kubernetes通常意味著需要DIY。Banca Intesa Sanpaolo不是從頭開始構建,而是採用Diamanti開發的設備方法。Diamanti系統是預裝了普通Linux和Kubernetes的商用x86伺服器設備,但添加了卡以克服網路和存儲中的I / O挑戰,可以削弱Kubernetes部署到生產環境的挑戰。

扼殺舊式應用程序

從軟體的角度來看,這種方法意味著銀行可以專註於Kubernetes和容器策略。 同時,底層基礎架構層還可以滿足其對存儲和網路虛擬化的所有要求,並具有高性能級別以滿足業務單元SLA。 Diamanti的管理軟體為銀行提供了跨多區域和多站點集群的高可用性,並為不同應用程序提供了不同業務關鍵性的服務質量保證。

目前,該銀行運行了3000多份業務。其中超過120個正在使用新的微服務架構進行生產,包括銀行核心的10個業務中的兩個。

銀行希望在微服務上運行哪些類型的應用程序?從一開始,該團隊就專註於兩類應用程序:新的和單一的應用程序,所有新應用程序都立即使用微服務方法構建。

對於現有的單一應用程序,銀行遵循所謂的扼殺應用程序模式。隨著新功能被添加到任何遺留應用程序中,每個新功能都被添加為一個新的microservices迷你應用程序。遺留應用程序和微服務應用程序並行運行,直到最終遷移到一個新應用程序中,在這個新應用程序中,舊的整體在生命結束時被「扼殺」。

軟體開發不再是所有參與者都堅持使用單一管道的場景,在這種場景中,單個提交可能導致構建失敗,並導致開發、測試和部署過程停滯。這個過程變成了這樣一個過程:每個參與者都有自己的開發流程來開發每個專用組件。

這一更改使操作更容易地擴展應用程序團隊對其特定基礎設施的需求,是一個很好的解決方案。應用程序的每個組件都依賴於一個可以水平伸縮的專用容器。通過避免多米諾骨牌效應,可靠性顯著提高。新方法實現了自動化,消除了開發人員和操作人員在推出新應用程序時的許多手工步驟,這在總體上提高了代碼質量。

K8s有多熱?傳統銀行轉型擁抱Kubernetes案例

處理殘餘挑戰

雖然向容器、Kubernetes和微服務體系結構的轉變在可伸縮性、可靠性以及開發和部署的速度方面帶來了數量級的改進,但該銀行也面臨著巨大的管理挑戰。

規模調整:第一個挑戰是準確調整運行微服務架構所需的底層基礎架構,因為它基於新的範例。 銀行過去用於傳統單片應用的規則需要進行改進。微服務應用程序的行為方式與單片程序不同,並且它們不會消耗相同數量的資源。

流程:使微服務與現有數據中心生態系統協同工作是銀行構建和實施應用程序,以及為底層基礎架構提供資源的方式的根本變化。 該團隊發現使用容器平台和Diamanti技術在此過程中非常有效,但從應用程序的角度來看,無論新建應用程序多麼簡單,都需要為成千上萬的應用程序做大量的工作。

文化挑戰:DevOps的概念和開發人員與運營之間的心態具有很大的差異,需要一種新的思維方式來創建和部署應用程序。

最後一點是最容易被忽視的,但對於企業來說也是在實際工作中最難的。

喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 IT168企業級 的精彩文章:

盤點 | 近期網路安全領域的7次重大收購
華為推出「小而美」輕量級解決方案,助力廣東政企行業煥發新貌

TAG:IT168企業級 |