整合Kubernetes（K8S）調度工具發展的平台，無法避免必須跟進社群快速地發布新版本，但多數企業應用環境根本難以支應如此頻繁的異動，因此能否讓原生社群發布的K8S版本無縫銜接到既有應用服務，對於企業用戶來說至關重要，以免隨需遷移到異質平台時出現阻礙。
「Red Hat發展的理念是以社群為核心方向，在不更動原生技術的原則下補強企業所需的功能性。」台灣紅帽軟體（Red Hat）解決方案架構師孫翊軒強調。其次重點則是容器環境的Linux作業系統，這本來就是Red Hat擅長的技術，藉此進行權限切割、User Namespace等機制。至於安全性的配置，以及相關的監控能力、日誌分析與偵測、負載平衡等，Red Hat則是基於既有的Linux核心整合開源社群的技術堆疊提供。
對於不以IT技術為核心優勢的物流、醫療等多數產業，根本無力自行維護龐大的平台，採用PaaS至少可專注在發展新商業模式所需的邏輯，而非投入維持基礎架構的可用性，如此一來，才得以讓IT技術連結商業價值。
「兩個披薩」應用規則提高上線效率
雲端原生開發應用服務關注的12-Factor（12要素），早期是由Heroku提出的開發原則，K8S與容器基於此概念實作搬移。對此，企業應用關注要點不僅為確保正常運行，同時要能夠掌握服務失效、連線行為等，然而這些卻非K8S涵蓋的範疇。因此要由PaaS基於K8S補強所需的能力，例如針對開發者可提供持續整合／持續發布（CI/CD），應用運行時亦得確保網路存取行為、存放映像檔區域等安全性，這些技術皆可建立在PaaS平台。若定位為CaaS平台，則適用於IT技術已有一定基礎者，例如獨立軟體開發商，可藉此發展解決方案來提供服務。
符合雲端原生開發應用服務關注的12-Factor，需搭配微服務架構擴展。最早實作微服務架構的Amazon，初期是為了解決單體式網站系統，由不同技術團隊各自部署、維運，當時提出相當有名的兩個披薩（Two Pizza）團隊原則，旨在避免服務上線時，要幾百人嚴陣以待，兩個披薩就能餵飽的原則只要6到8人即可完成。基於此概念，後續發展出微服務架構，至於容器環境是Linux核心提供的控制群組（Control Group）、用戶空間（User Space）等機制實作切割，讓容器環境獨立運行，也就是Role-Based權限控管（RBAC），基於這些技術才讓微服務架構擴充性得以實踐。
Red Hat希望提供穩定的PaaS平台，讓開發者自助完成所需的工作，例如微服務擴展。孫翊軒說明，首先是Service Mesh，近期開源社群對於實作方式有諸多討論，Red Hat是基於Istio開源工具，更早以前則是Spring Cloud生態鏈架構，控管不同單體式應用系統進行溝通時Time Out、熔斷機制（Circuit Breaker），以避免單一服務發生故障時仍可維持正常運行。Spring Cloud本就已經具備完整的應用層微服務控管技術，Service Mesh則是把這些控管機制抽離，不希望應用程式每次上線部署新服務時都得先定義控管機制被觸發的參數，也希望得以藉由可視化操作介面來掌握分散部署的服務狀態。
平台啟用封裝檔 即可擴充支援
若以傳統IT部門的分工來看，Service Mesh設計的功能有助於IT維運人員深入到微服務架構內部，可藉由拓樸圖方式掌握相關動態；開發人員也無需在每次上線時都得依據底層環境調整程式碼，或是運用平台功能取代自行撰寫連線接取的判斷規則。這讓企業得以實現微服務架構來設計新型態應用，同時無需增添更多成本。假設應用情境中有五種不同型態的服務相互串接，一旦無法正常運作時要即時地發現，同時掌握單點故障時狀態，皆必須可在平台上處理。
另一個面向是PaaS平台上的Runtime、網頁應用服務，可藉此採用不同程式語言開發，包含Java生態系的Spring Boot、Node.js驗證過的Runtime，Openshift已內建提供，才可以讓DevOps團隊便於選用。「我們已經把Runtime、網頁應用，這類通用性較高的服務封裝成映像檔，當開發人員程式碼撰寫完成，接下來需要有Spring Boot執行環境，只要在Opneshift平台上啟用該映像檔即可整合運行，而且是已經通過Red Hat驗證通過，可確保安全性。」
舉例來說，程式開發語言種類相當多元，相對應的Runtime也有不同選擇，對開發人員而言，這方面的技術掌握度較低，以往都是維運人員負責，但是維運人員也不可能每種網頁應用服務與Runtime都懂，Red Hat提供的方式是啟用時已具備基本設定，無須介入配置。
DDD依據業務流程來分析系統架構
近期本土保險業正在積極發展核心應用系統瘦身計畫，孫翊軒指出，等同於近幾年談的「大中台、小核心」的概念，大中台來自阿里巴巴推廣，OpenShift的定位是提供中台層，可能有幾種實作方式，首先是企業尚未準備好大量程式碼的盤點與確認，但是要實施容器環境的部署時，可選擇把原本虛擬主機或實體機運行的系統直接封裝，遷移到平台層，成為容器化應用模式。
在容器化之後，企業逐漸理解掌握運作邏輯與執行方式，便可著手調整程式碼，這也是企業最難跨越的環節。接著是梳理服務的工作流程，Red Hat主要是推廣DDD（Domain Driven Design）方法論，孫翊軒以實際案例的國泰世華銀行來說，希望做到以服務顧客為導向，DDD就是依據業務流程來分析系統架構，而非傳統按照技術的角度，先把資料庫正規化之後，才開始設計邏輯程式。
台灣紅帽軟體（Red Hat）解決方案架構師孫翊軒提醒，微服務架構的後端資料庫若未能拆分，實務上無法發揮效益，在切分業務領域時，可明確定義產生的資料，並且把資料統整在獨立的資料庫，避免跟其他資料庫勾稽，才可真正隔離。
DDD方法論是基於營運業務服務領域進行切分，透過中台層跟前端應用串連後提供，由此可理解整個服務的流程，以決定轉換到容器環境運行的優先順序，畢竟並非每個服務都有必要在同一個時間點上雲平台。雲平台的好處是加速開發迭代、建立自動化測試，可能是網路銀行等客戶導向的應用服務較為優先，假設是內部應用例如人資系統，便無需快速迭代，部署到容器環境的商業效益並不大，除非是對外應用服務才需要重塑，透過DDD可以清楚定義領域分界，再運用Spring Boot框架轉換為輕量化架構。
Spring Boot可說是近年來Java領域最為流行的框架，不過Openshift 4.4也可提供採用Knative框架的Quarkus，典型的應用即為門票預購系統，過去通常是在爆量時觸發擴增Pod，Serverless則可在服務尚未被存取時，完全不佔用資源，以免浪費公有雲成本開支，待顧客存取時亦可在毫秒等級的時間啟動。先行掌握平台層的技術能力與限制，才得以逐階段執行核心瘦身，達到最終目的。
註：本文因受訪者口誤，第4段原提及12-Factor開發原則由Pivotal提出，正確應為「12-Factor（12要素）早期是由Heroku提出的開發原則」，已予更正。