借助新興科技的力量，在數位化新時代中贏得競爭力，已是各行各業正積極進展的策略目標，企業IT可說是轉型的重要舵手。
為了提高企業服務營運回應市場的速度，肩負重責大任的關鍵任務應用系統，開始從單體式逐步轉向微服務（Microservices）架構，讓業務功能獨立成為可自主執行的個體，同時搭配容器（Container）技術運行模式，藉此滿足特定服務因市場變化須頻繁改版所產生的資源調度與配置需求。
過去的開發架構，常是把內部應用系統或網站組合成龐大的怪獸，可能幾百種功能邏輯皆內建於單一系統，再建置以中介軟體串接來交換資料，例如商業版的WebSphere、WebLogic，抑或是開源陣營的Jboss、Tomcat等，藉以讓功能性之間緊密相依，優化整體運行效率，卻也變得複雜難以維護與擴充。
如今龐大的系統得以拆解成微服務架構，VMware副總經理暨技術長吳子強觀察，就概念上而言確實相當受歡迎，關鍵問題是應用系統的變更茲事體大，說是超級大工程亦不為過，必須要有明確的目標與決心，更重要的是取得管理高層與內部同仁的一致認同。以VMware自家為例，公司內部的IT應用系統大約耗費近七年時間轉型，目前有九成以上已是微服務架構，不限定運行在容器環境。
吳子強在協助客戶轉型過程中發現，愈是貼近市場的企業愈積極迎頭趕上新商機。事實上，近兩年本土企業較以往更關注新興應用技術，非僅限於遊戲、媒體等產業，過往相對保守的高科技製造業與金融業，絕大多數正在積極地進行內部系統轉型的驗證測試。只是現階段面臨最大挑戰是幾乎得重新撰寫應用程式，尤其是內部自主開發的系統，因此有能力提供解決方案的廠商，必須同時接觸開發與維運人員，以協助DevOps團隊邁進到數位化應用環境。
智慧製造全球布局多雲應用實踐轉型
目前較積極驗證測試微服務架構與容器運行環境的企業，根據IBM大中華區軟體研發中心應用及整合資深顧問陳怡良觀察，主要是金融保險、高科技製造、電信業，而非網路軟體服務業者。「很難想像，我兩年前推廣微服務時，第一套解決方案是高科技製造業的建置專案。」
眾所周知，製造業較擅長於實體設施的製造與製程能力，IT技術一向並非專長能力，更少有配置解決方案架構師。可是當工業4.0啟動後，各家製造業開始思考，透過智能化的方法加速製程優化。人工智慧融入到物聯網應用場域為多數企業重點策略，初期是在生產線環境，基於蒐集取得的大數據進行演算分析，預測即將發生的問題。
陳怡良進一步說明，當時承接的製造業客戶，正面臨的挑戰是既有IT應用架構為實體建置，一旦遇到系統版本更新，往往須耗費相當多時間，為了提高彈性與快速部署能力，導入建置Docker容器技術，把製程環境的物聯網應用系統全數模組化，嵌入到每個容器中運行，提高廠房應用系統的部署效率與監控能力。此外，該客戶基於全球布局的商業模式持續採納混合雲應用，除了總部的資料中心，亦逐步藉由IBM SoftLayer與Bluemix介接，提供北歐的外部據點應用服務，甚至其他外點區域則建置在AWS公有雲平台之上。
企業應用服務的部署模式，不論是基於業務發展或政策考量，皆無法僅選用單一公有雲服務供應商，勢必為多雲應用，差別只在於比例分配，他指出，例如IBM SoftLayer提供的裸機（Bare Metal）可實體擴充GPU，讓人工智慧應用須運行的深度學習演算法可藉由裸機提升效能；其他簡單的應用，則可建置於AWS雲端平台。
開放式銀行興起API介接交換資訊
目標客群為大眾消費者的企業，將應用服務轉型建置在微服務架構與容器環境，可獲得更直接的效益。陳怡良指出，典型的案例即為Netflix，整年度的網路流量在北美佔有三分之一，早在多年前就已把Java架構的系統予以拆分，初期先運行在虛擬主機，進而再演進到容器環境，藉此節省整體營運開支。另一個較有共鳴的案例是電商，因應雙11等特別節日舉辦促銷活動造成的瞬間流量，即使雲端架構底層採用虛擬技術已可實現彈性擴充，仍無法滿足突發性的存取量，此時即可感受到容器化的優勢，真正可達到秒級的方式橫向擴充。
至於銀行業，多數人認為主要是受限於高度監管，應用服務才無法上雲，陳怡良在實際接觸企業後卻發現，接受度才是最大障礙。「其實相較於創新，原先本土銀行業的當務之急在於節省成本、提升效率，同時得維持穩定運行。因此要等到從這三個面向切入，建置實驗環境證明可行性，才開始放心地在新的開發專案中採納微服務架構運行在容器環境。」
值得留意的是，正常運行中的內部核心系統，企業不可能毫無緣由的拆分轉型成為微服務架構。隨著數位化浪潮席捲而來，銀行業自2017年第三季開始突然大轉變，不論是商業或公有行庫，皆願意讓業務系統演進到微服務與容器環境。陳怡良指出，主要因素是以金融科技（Fintech）為目標發展的金融業，正積極發展開放式銀行（Open Banking），提供API打造生態鏈，即代表以往的經營模式已經面臨到轉變，既有的餘額查詢、繳稅、繳費、轉帳等功能，前端連線存取通路已不限定為網頁或App，可橫跨到例如KKBOX、便利商店等不同產業領域，運用銀行釋出的API，藉此建立異業結盟的通道。
問題是如此一來，存取流量勢必不再僅為固定操作模式，也可能出現瞬間爆量的狀況。銀行後端系統若仍維持原有的高可用性架構，即使是建置兩座大型主機也未必有能力支撐突如其來的存取量，不僅影響用戶體驗，還可能因違反通路夥伴保障服務水平協議而賠款。
「銀行的轉型與創新，除了利用新興技術來實現以外，還必須建立商業生態系統。因此微服務架構的興起，影響所及不僅是技術層面，更重要的是支持業務創新達到轉型目標，只有從這個角度切入，才得以取得高階管理層認同，加快數位化發展的速度。」陳怡良強調。
產業型態改變後，基於過去估算市場需求與擴充數量的方法已不可行，若採用微服務架構與容器技術，日後才有機會實現高度靈活性與敏捷性。當然，工作流程亦須隨之轉變，透過建立DevOps團隊與組織文化、導入敏捷式開發流程等方式，藉此控管端到端的生命週期，微服務架構的最終價值才得以展現。
數位達爾文逐步演進 實踐企業IT轉型
紅帽（Red Hat）資深解決方案架構師彭信忠同樣觀察到本土金融、電信、電商等不同產業，皆相當關注微服務應用發展趨勢，也已經嘗試性地測試研究，但是卻遲遲無法進一步上線運行，因為遭遇到的挑戰並非為技術問題，而是組織結構、工作方法、工具熟悉度等方面尚未準備好所導致。
應用系統架構欲演進到微服務，彭信忠以「數位達爾文」的六個實踐階段說明，首要即是先重組DevOps團隊、建立開發習慣與設計思維等觀念，此後才會進階到搭建起具備自助服務、自動化、持續整合（CI）與持續部署（CD）等機制的平台，藉此讓開發與維運人員建立合作關係，進而扭轉舊思維，改變以往根深蒂固的工作流程。
他進一步說明，以往的工作流程是開發者在自己環境中撰寫完成後，向維運者申請虛擬主機執行測試，經確認後再申請指定發布上線的平台，此後即交給維運者負責管理可用性。現代化雲端平台則並非如同以往專業分工方式，交由專職的DevOps團隊負責建構、測試、發布、維運等工作。
數位達爾文演進的最終目標是當業務服務產生新需求時，得以採用微服務來提供，並且藉由轉型過程中建立的自動化、開發與維運協同合作流程，來保障應用服務的可管理性、穩定性以及安全性。
彭信忠強調，這是個漸進的過程，絕非一蹴可幾。即便是從外部挖角組織成為DevOps，若只有該團隊運用新技術架構，其他既有的技術人員仍維持以往工作模式，概念上就如同委外開發，恐怕也難以達到轉型的目標。
架構師承上啟下溝通 傳達技術價值
現階段企業儘管已經開始接觸微服務架構，彭信忠從實際接觸客戶的經驗中發現，在尚未理解對於商業營運的助益之前，一旦貿然導入建置恐將成為新怪獸，日後也無力再進行變更。另一種類型是營運問題相當明確，經過實際測試微服務後才意識到距離上線運行的差距過大，因此放棄採用，轉向尋找其他技術或方法緩解現階段的問題。
 |
| ▲Red Hat提出數位達爾文的微服務轉型六階段，首要組建DevOps團隊，進而搭建具備自助服務、自動化、CI/CD等機制的平台架構，藉此讓開發與維運人員建立合作關係，進而扭轉舊思維，改變以往根深蒂固的工作流程。（資料來源：Red Hat） |
「畢竟傳統IT部門較為封閉，尤其是台灣企業，大多是透過廠商介紹說明後，才知道外界環境的轉變。當然，現在年輕工程師自學的比例也不低，可惜普遍只熱衷於技術。事實上，導入微服務的組織必須要由懂技術的人來說清楚商業價值所在，把技術能力轉化連結策略營運，才能讓高階管理層理解，達到數位化目標。」彭信忠說。
其實即便是面對數位化轉型的變革，就高階管理層而言，關注的重點仍不外乎用最少成本做最多的事，其次是以最快的速度回應競爭對手，第三點則是法規遵循能力，必須有能力因應市場需求、國際形勢變化而調整。這三個管理層面的議題欲連結到實作技術，勢必得透過居中協調的架構師，既掌握產業運作特性，同時具備IT技術的背景，在學習新技術時，得以快速消化並且判斷適合應用的場域，而不是僅把高階管理層設定的績效指標直接連結到技術。
經歷過大型主機時代的IT管理者，對於應用系統的思維是以穩定性為核心，並非為追求創新、引領企業開拓新業務。更何況由於開放原始碼工具是由社群推動，版本變動性過大，管理者沒有時間隨時關注、了解開放陣營的技術發展。在高階管理層與第一線技術人員之間，則可借助架構師的溝通能力，適時向下傳達危機，讓埋首於技術工作的成員理解社群發展現況，亦可向高階管理層清楚描繪開源技術的商業價值。