近年來IT應用環境因應數位化時代掀起轉型聲浪，隨著容器（Container）、開放API、微服務等開放陣營發展的技術影響力日益強大，尤其是Google自2015年貢獻Kubernetes容器調度工具給雲端原生運算基金會之後，國際IT大廠IBM、VMware、Microsoft、Red Hat等，皆陸續整合納入自家平台，如IBM設計提供的ICP落地型解決方案，可建置容器即服務以承載微服務架構，其搭配的調度工具即是K8S。
近年來IT應用環境因應數位化時代掀起轉型聲浪，隨著容器（Container）、開放API、微服務（Microservices）等開放陣營發展的技術影響力日益強大，尤其是Google自2015年貢獻Kubernetes（K8S）容器調度工具給雲端原生運算基金會（CNCF）之後，國際IT大廠IBM、VMware、Microsoft、Red Hat等，皆陸續整合納入自家平台，如IBM設計提供的ICP（IBM Cloud Private）落地型解決方案，可建置容器即服務（CaaS）以承載微服務架構，其搭配的調度工具即是K8S。
IBM的公有雲服務針對IaaS提供的是SoftLayer，具備網路、儲存、運算以及Hypervisor；在PaaS平台方面是Bluemix，運行作業系統、中介軟體、Runtime環境；至於SaaS則是於IaaS與PaaS平台之上再增加資料、應用程式。從2018年起統稱為IBM Cloud。但是只靠公有雲無法完整滿足企業應用需求，畢竟過去投入大量資源建置的資料中心難以就此廢除，雲端服務未來亦可能須遷移回到地端，對此IBM即是提供ICP來協助建置CaaS，搭配基於K8S調度能力所設計的多雲管理（Multicloud Manager）操控平台，並設計以儀表板（Dashboard）方式呈現狀態分析資訊，輔助DevOps團隊協同工作。
運用多雲管理操控平台，負責維運CaaS入口網站的技術人員，便可依據工作流程配置優先執行順序與控管政策，IBM大中華區軟體研發中心應用及整合資深顧問陳怡良指出，甚至可針對不同時間點的雲端服務收費規則先行試算，例如開發單位申請容器環境的時間點，可能碰到自家平台資源吃緊，則必須轉向選用外部公有雲服務。
然而公有雲服務收費模式最小單位可為每小時，但在同樣時間點，選擇澳洲、東京、倫敦的資料中心，價格可能完全不同，企業自行搜尋網路標價進行估算往往不夠準確，因此主流的公有雲服務供應商皆有針對計價功能提供API，讓管理軟體呼叫擷取最新收費準則。企業只要事先跟IBM、AWS、Azure、Google等公有雲服務供應商簽訂協議，便可選擇以儲值方式，用多少扣多少，抑或是月結收費。只要簽訂協議後，供應商通常都願意提供定價模式資訊，或經由API擷取，如此一來，DevOps團隊即可藉此機制掌握開支。
容器技術的五大特性贏得企業青睞
就容器技術的特性來看，陳怡良說明，主要具備了Portable（可攜性）、Performance（效能性）、Visibility（可視性）、Immutable（不變性）、Composibility（組合性）等五大特性。Docker Engine實作Image程式為可攜性，呼叫原生平台的系統核心即可運行，較Hypervisor層建置Guest OS模式來得更輕量，效能自然更高，也因此可達到秒級的啟動速度。
「可視性方面是把以往系統安裝、操作程序、輸入的環境參數設定等工作流程，按照執行步驟撰寫為Dockerfile，只要檔案未經修改，皆可原封不動地重建程式運行環境。不可變性則指的是Image本身封裝的系統函式庫無法被修改，一旦Pull（下載）指令執行後，啟用的容器環境會回復到初始狀態，即使原本攻擊程式已成功滲透也因此失效。」陳怡良說。
組合性是透過Docker Compose技術，把多個Dockerfile組合繪製拓樸圖，例如依序指定配置為前端網頁、商業邏輯、資料庫運行環境，以建置完整的商業應用系統。當企業有多網站與資料庫應用需求，只要Pull所需的Image檔案，經由Docker Compose組合後即為可運行的應用系統。
當存取流量超過資源承載，可彈性執行橫向擴充（Scale-out）。以往實體伺服器的建置架構，面對資源吃緊必須進行垂直擴充（Scale-up），例如把記憶體提升到32G等級，伺服器勢必得先關機，也代表所有應用服務必須中斷；進展到Hypervisor環境時，便於橫向擴充的能力吸引企業青睞，問題是虛擬主機檔案從遷移到啟動上線運行，至少得花費五分鐘，且可能重新派發IP位址，網路控管政策亦須調整設定；如今到容器環境，不僅垂直擴充無須停機可立即生效，若需要橫向擴充，只要設定條件值，亦可自行延伸與縮回。
此外，容器環境並非採用IP位址溝通，而是透過Overlay架構，自成一套網路運行環境，藉由DNS服務解析，因此可掌握整個容器環境運行狀態，以便提供微服務使用。
應用系統先容器化再拆解轉成微服務
 |
| ▲ IBM大中華區軟體研發中心應用及整合資深顧問陳怡良觀察，近十年來IT廠商獨家的技術陸續釋出到開放陣營，技術發展速度比自家研發更快，IT人員也開始參與學習到實用性高的技能，讓開放社群的力量日漸壯大。 |
K8S最小單位為Pod，可包含多個容器，較Docker以容器為單位不同。以技術來看，陳怡良說明，過去透過Docker Swarm來解決資源調度（Scheduler）與編排（Orchestration）的複雜度，可適用於大約100個容器數量的測試、研究等環境，問題是企業應用服務所須配置的容器，可能多達成千上萬，則必須採用Google釋出的K8S工具來實作控管。同類型的開源工具還有Apache Mesos，過去Hadoop分散式架構主要便是運用Mesos實作資源調度與編排工作，在容器技術興起後，Mesos也延伸提供支援，只是近年來採用者數量遞減，聲勢也較薄弱。
如今K8S雖已為主流，仍有小型的DevOps團隊偏好採用Docker Swarm，若不需要複雜的架構，安裝建置Docker Swarm只要五分鐘即可配置完成。相較於K8S，安裝可能需要超過一個小時，畢竟應用規模較大、複雜度較高，除了網路層配置，作業系統核心也須先行更新修補程式，再部署應用服務。所幸可自行撰寫安裝配置檔案，大約九成的設定操作可自動化執行，實際上需人力介入的時間大約只有一成。
就網路銀行應用服務來看，通常整合相當多的功能模組，在龐大的系統中提供個人銀行常用的餘額查詢、繳費、衍生性金融商品等服務項目。陳怡良指出，在微服務架構與容器環境導入之前，網路銀行主要是以單一應用系統來提供所有服務，並建置兩台大型伺服器以建立高可用性。
多數企業IT轉型的開始是先採以容器化方法，也就是直接把整個應用系統封裝在兩個容器環境中運行，藉由實機測試驗證技術後，才全面性地採用。「現階段我們已經開始基於方法論來協助拆解應用系統功能項目，依據功能項目轉化成微服務架構嵌入到容器環境，針對較多人使用的微服務，配置多個容器來支持運行。至於其他較少存取量的微服務，可能只須配置一個容器即可。」陳怡良說。
完成微服務的拆解之後並非就此結束，關鍵是得依據不同通道（Channel）盤點出共用模組，必須予以抽離統一集中存放。各行業核心的大型應用系統，或多或少有共用模組平台，經過拆解成微服務後，統一存放於特定區域，再開放給不同通道呼叫使用，讓開發人員只要維運共用模組程式即可支應各自獨立運行的微服務。
至於既有的EAI（企業應用整合）／ESB（企業服務匯流排），則是在共用模組後端，畢竟仍舊必須藉由EAI介接後端封閉的帳務主機系統，把資訊轉換成為開放格式，只不過以往是直接提供給各式存取管道，如今則是透過共用模組平台存放區來串接整體應用服務。
微服務本身特性是須透過API運行，API必須經過註冊後統一控管，主要是因為，共用模組平台運行環境可能由多個容器所組成，彼此間透過API溝通。問題是，該怎麼掌握企業內部所有的API服務？以前大多只透過Excel檔案記錄，相信現階段仍有企業沿用此方式，但是由於API數量過多，人工記錄效率低落且容易出錯，因此必須得透過API服務註冊中心，也就是企業所有微服務的API，必須上架到註冊中心。前端系統可先行查找所需的API服務，以便藉此拋送資料到後端處理回傳。「此機制就必須透過K8S才得以做到，解決資源與服務的控管、調度，所以當應用系統轉換到微服務後，多數會搭配K8S來執行控管。」
善用既有投資轉型到雲端原生應用
以往商業應用軟體少見納入整合開放社群的工具，但K8S卻是在短短兩年內，幾乎全數IT廠商皆發布整合運行的解決方案，即代表K8S確實可解決新興應用架構的問題。畢竟對於商業營運環境而言，穩定性可說是天條，僅仰賴Docker Swarm恐無法支應，K8S本身是由Google研發設計並且實際驗證過的工具，自然更具信心可大量採用於商業環境。
IBM ICP便是基於K8S發展補強功能性，使解決方案較完整並得以確保應用環境的穩定與安全。陳怡良舉例，ICP內建的Vulnerability Advisor（VA）功能是IBM所增添自家擅長的資安領域技術，以確保新興應用環境的安全性。IT人員可能自行封裝Image檔案啟用，也可選擇從外部GitHub等平台下載，但萬一埋有攻擊程式碼，未經過工具檢驗之前根本無從得知，恐將因此為企業帶來災害。藉由ICP VA則可掃描Image檔案與容器運行環境，補足原生K8S未具備的檢測能力。
「必須強調的是，IBM認為必須尊重或善用企業既有的投資，針對已經導入建置中介軟體的IT應用環境，設計提供Transformation Advisor工具，不論內部既有系統為IBM、Oracle、Red Hat等中介軟體皆可藉此工具進行轉換評估。若最終目標是轉型成雲端原生應用程式，亦可提出建議應該執行的工作項目。」陳怡良說。
畢竟企業IT即使組織DevOps團隊，恐怕也無力把既有應用系統的程式碼逐條予以容器化，並搬移到雲端原生環境。因此IBM設計Transformation Advisor工具，只要提供原始程式碼、原本運行的環境、移轉的目標，工具會自行評估計算出轉移所需的執行工作項目，甚至亦可藉由工具介面快速執行特定工作。
為了讓客戶善用既有投資，IBM提供移轉的路徑與工具讓企業得以參考，加快轉型到雲端原生應用環境的速度，另一方面，也設計提供IBM Microclimate開發環境，基於瀏覽器操作介面，即可運用支援微服務所須的IDE開發環境，廣泛地支援Java、Node.js等雲端原生應用程式碼，完成後亦可直接線上測試，無須額外準備測試環境立即可實作，之後Check-in到Git版本控管平台，經過持續整合（CI）之後，再把程式碼從Git平台Check-out，綁定在內含有應用伺服器版本的Image，之後執行持續測試，此時即是在容器環境中執行，確認問題都已排除後，最後予以整合發布到線上環境。
「這整條流水線（Pipeline），包含Check-in/Check-out、Build Image等工作流程，即可透過Microclimate來實作，讓開發與維運建立一致性工作程序。」陳怡良強調。