坊間講到從單體系統轉移到微服務架構的書，特別是歐萊禮出的，有不少轉移的典範，比如：金絲雀佈署、藍綠佈署等。但是對客戶而言，有以下困境：
1.錢的問題：建置k8s環境如OpenShift等，infrastructure(基礎建置)需要大筆預算。
2.IT的問題：對長期負責老系統維運的IT來說，即使docker容器化技術行之有年，對他們來說還算是新的概念，他們更習慣用服務控管系統維運，不管是Linux的systemctl還是Windows的services.msc。
3.資安的問題：包括不能用root權限運行，網路防火牆設定等問題。
4.遷移的風險：單體系統與微服務架構可以說是兩種不同的維運生態，一旦進行遷移，對負責的IT來說不知會踩到什麼雷，承擔怎樣的技術債。如同慣於辦桌的總舖師一向由自己掌握火候、溫度，忽然一下子在西式餐飲的廚房面臨一系列的電子化廚具，不知怎麼出菜。

RedHat推出podman替代Docker，主打就是用rootless運行容器，解決上述第三個問題：資安。然後到podman 4.4版開始，提供了quadlet功能，將容器轉換成RedHat服務，讓甲方IT還能用自己熟悉的systemctl來維運，解決上述第二個問題，不過這只限於Linux，特別是RedHat，Windows沒這個優待，連帶也解決第一個問題：錢，在既有主機或VM上可以安裝podman，資源不足再編預算擴充硬體資源。
第四個問題涉及一個現實的狀況，大部份需求單位不會冒險一下子從單體系統跳到微服務架構，可能經過若干年後，Podman Quadlet已運行上線的容器可以用最少成本遷移到k8s環境，IT及開發商也在這些年理解微服務架構運行方式，將技術債平均分攤。但也可能運作太穩定了，IT還是習於用systemctl管控服務，就持續使用Podman Quadlet。
就個人感受，如同賈伯斯初推平板時，被訕笑是較大的iPhone還是較小的MacBook，現在已是新的3C用品分類，而Podman Quadlet固然可以作為從單體系統到微服務架構的過渡時期的維運架構，但本體也是個穩定的維運架構，不必然用於過渡。

Podman Quadlet在國內算少見，當時研究至少耗一個多月，若拿來參加鐵人賽，內容可能不用廿天就交待了七八成常用的功能，雖想過捨棄這個主題，不過既然有機會可以讓讀者節省很多摸索的路徑，也可以讓業務面對客戶猶豫在單體系統或微服務的解決方案中多一個選項，那就能寫多少算多少。
所以寫作的方向是從單體系統角度切入看待容器化服務，包成容器的技術以Spring Boot為主，也有Nginx，所以會相關的程式設計及配置設定。使用的筆電作業系統是MacOS，CPU是Apple M4，必須說CPU是x86還是其它種類還真的有所有影響。