是危機還是危言聳聽?
--- 面對瞬息萬變的資訊環境我們將何去何從
最近這一星期，對於資訊界來說可以說是相當不平靜! 先是 Kubernetes 宣布棄用 Dockershim 作為其 CNI 實作，人們還沒從這個既震撼又混淆的消息回過神來的時候，接著 Redhat 又宣布停止對 CentOS-8 的支援。
究竟這兩消息會對我們的資訊應用環境造成甚麼樣的衝擊呢? 是真的如傳聞那樣的恐怖還是只是蜻蜓點水而已? 兩件看似無關的事件是否存在著某些內在的關聯呢? 帶著這些疑問，我們不妨一起探究一下...
Docker 怎麼了嗎?
12 月 2 日隨著 Kubernetes 1.20 的發表資訊，鋪天蓋地看到的盡是"Docker is being deprecated(Docker將被棄用)!"等等聳動標題的文章。乍看之下，還以為 Docker 末日已經來臨了呢！
不過在仔細看過內容後，發現正確的說法是：Kubernetes 未來棄用的是作為 CRI 的 Dockershim，並不是棄用掉整組 Docker 服務棧。然而，很多人並不很了解 Dockershim 與 Docker 有甚麼不同？這正是造成消息混亂的根源！
那 Dockershim 又是什麼東西呢？簡單來說，他是 Kubernetes 的其中一種 CRI(Container Runtime Interface)。眾所周知，Kubernetes 是一套容器(container)的管理平台，具體是透過 kubelet 服務來控制容器的執行。雖然現階段的容器映像(image)大部分都使用 Docker 創建的，但在 Kubernetes 環境下卻不一定只能使用 Docker 來執行容器，只要容器映像是依循 OCI( Open Container Initiative)標準建置並符合 OCI 執行規範都能被 Kubernetes 驅動運行。
在進入更進一步的討論之前，我們必須要釐清一個誤區：
Docker 不等於 Container!
嚴格來說，Docker 是一整套技術棧(tech stack)，除了主要用來運行容器的服務行程之外，還包含了很多其他的面向使用者的服務介面與工具。
如果您偏好用 Docker 服務來運行容器的話，很不幸運的是 Docker 並不兼容於標準的 Kubernetes CRI。因此，Kubernetes 必須借助於另外一個稱為 Dockershim 的介面才能與 Docker 服務溝通。說好聽點是殺雞用牛刀，說難聽點則是脫褲子放屁！事實上，只要是 OCI 標準的容器，Kubernetes 都能透過其他更簡便、更高效的 CNI 來驅動運行。既然如此，幹嘛 Kubernetes 還要藉助於臃腫的 Docker 來運行容器呢？輕裝上路不是更好嗎？
沒錯！道理就是如此簡單。
我們還可以繼續使用 Docker 嗎？
Kubernetes 發布的消息只是將來不再使用 Dockershim 作為 CRI 來繞道 Docker 來運行容器而已，但其他更直接、更原生的 CRI 還是保留著，只要容器是符合 OCI 標準的話其實並不會受到影響。換句話說，我們還是可以用 Docker 來建置容器映像，也可以繼續用 Docker 來運行他們。但如果要交給 Kubernetes 管理這些容器的話，則不需要勞駕 Docker 了…
作為容器的建置工具，Docker 本身絲毫不受 Kubernetes 最新的政策影響。我們還是可以很快樂的編寫 Dockerfile，也可以用 docker build 或 docker-compose 來建置容器。我們還是依然可以很快樂的將容器上傳到 dockerhub 並在那裡發布並與社群分享，或是上傳到私人的容器倉庫... 這些與容器本身管理方面的操作，還是如常進行即可。
簡單而言，如果您是一位 Kubernetes 的使用者，您並不需要擔心 dockershim 被棄用的問題！或是，您是直接租用雲端服務業者提供的 Kubernetes 服務，也同樣不受影響，完全可以忽略這則新聞！
那麼，誰會受影響呢？
受影響的是 Kubernetes Cluster 的管理員而已。他們的工作，就是在 Kubernetes 新版本不再支援 dockershim 的時候(或提前)將 CRI 進行更換而已。這只是一個小手術，不需擔心。
還有另外一種情況，就是透過 Docker 在容器部署時想要運行其系統方面的管理或是在容器內部運行某些事務，或許會變得不起作用。前者可以 crictl 這類替代工具，後者可利用那些不需要 docker 並支援新的建置選項的替代方案，例如 img、 buildah、或是 kaniko 這些產品。
輪到 CentOS 怎麼了嗎？
近期另一件大事情就是 Redhat 在 12 月 8 號宣布 CentOS-8 提前於明年年底結束支援，而將改由另一個滾動發行版本 CentOS Stream 取而代之，並且以後也不再有 CentOS-9 這類緊隨 RHEL 發布的 CentOS 版本了！這個消息一出來便立即引起 Linux 社群的炸鍋！而且幾乎是毫無例外的負面評價。
為什麼社群的反映那麼大呢？要理解這個議題可能先要了解原始碼(Source Code)的源流(Stream)這一概念。簡單來說，Redhat 公司主導與資助的三大 Linux 發行套件分別是: Fedora、RHEL、CentOS。而三者之間分別可以理解為原始碼的上游(Upstream)、下游(Downstream)關係：
- Fedora 是 RHEL 的上游; RHEL 則是 CentOS 的上游
- Centos 是 RHEL 的下游; RHEL 則是 Fedora 的下游
我們可以這樣理解：新的功能會在 Fedora 先進行測試，等開發成熟後再納入 RHEL 的穩定版本中，然後 CentOS 則是移除 RHEL 中的封閉源始碼軟體再重新發行的社群版本。如果您是一位商人的話，會不會覺得這樣的發行很奇怪？為甚麼 Redhat 在銷售收費版本 RHEL 的同時又釋出免費的社群版本給企業免費使用呢？是啊，這的確是很令人費解之處！
要通盤說清楚這個怪誕的模式，恐怕不是三言兩語所能交代的，恐怕要從 CentOS 計畫的誕生歷史開始講起了。礙於篇幅，這裡只能簡單說個輪廓：
- Redhat 在2003年9月突然宣布自 Redhat 9.0 不再推出個人使用的發行套件而專注於發展企業版本(Red Hat Enterprise Linux)，與此同時用戶需要購買授權後才能取得相關的支援服務，包含編譯完成的二進位程式(Binary Code)也是服務的一部分。但基於 GPL 授權的保障，Redhat 依然會提供原始碼給大眾索取。
- CentOS 計畫依據 Redhat 所釋出的開放原始碼重新編譯，打造一套名為"社群企業作業系統"，亦即 CentOS 的名字來由：Community ENTerprise Operating System。CentOS 的做法是從 Redhat 網站下載所有原代碼回來，然後將 Redhat 商標有關的標識去除，同時針對已經發現的 RHEL 臭蟲進行修補並重新發行，被視為 RHEL 的翻版(之一)。基本上，我們可以透由 CentOS 獲得與 RHEL 幾乎同等穩定性的 Linux 作業系統，但卻不需要購買 Redhat 的授權。
- 2014年7月 Redhat 宣布與 CentOS 專案結盟，雙方共同打造新的 CentOS。Rehdat 除了保證 CentOS 專案的獨立性之外，更貢獻資源與專長協助 CentOS 設立正式的管理委員會。此舉雖然有人認為是 CentOS 專案發展過速導致社群過於分散而遭遇的瓶頸，而 Redhat 也可以將 CentOS 的既有用戶群導引到付費的 RHEL 版本、並抵禦其他竄起的 Linux 發行商。但 CentOS 的實質主導權落入 Redhat 手中則是不爭事實。
- IBM 在 2018年10月以340億美元的價格成功收購 Redhat，以拓展其雲端業務。雖然 IBM 重申 Rehdat 的開放與中立性不會改變，但社群上嗅覺敏銳的觀察者對此態度相當保留，並第一時間關注 CentOS、Fedora 的可能變動，同時也做出萬一發生變故轉向收費的調整建議。因為人們從 IBM 一貫的收購作風來看，似乎被收購對象的下場無一難逃"被消滅"的下場！
只能說，先知總是孤獨的！
無論是從社群的生態或是商業的經營角度來看，當 CentOS 被 Redhat "假結盟"的時候，就注定了其總將被消滅的命運！只是居然拖了那麼多年才噩夢成真也算有點意外了…
先讓子彈飛一會吧！
雖然不意外，但也來得有點突然！然而，我們從 Open Source 的角度審視不同的 Linux 發行版本之後，不難發現 GPL 授權條款真是金科玉律啊！只要原代碼一旦經由 GPL 授權的洗禮，那麼這些人類資產就不會被任何企業或個人所把持！
既然 CentOS 當初能從 Redhat 的手中取得開放原始碼並重新發行，我們相信再做一個輪子並不困難。或許過沒幾天，就有新的一個類 CentOS 的發行套件問世也說不定。我們要知道，開放原始碼的社群力量是難以估計的，只要有人願意奉獻心力就會有替代的產品出現。
只是，我們不禁要問的是：除了 Redhat 或是 Redhat Clone ，難道沒其他的 Linux 套件可用了嗎？我們有必要執著於某一個商業套件的發行版本嗎？這才是 CentOS 是否 again 的關鍵！
為避免落入業配的誤會，我們就不特別點名有哪些不錯的替代版本可用了。讀者請依據自己的偏好挑選就是了。
然而，真的那麼重要嗎？
不管是 Docker 被棄用亦或是 CentOS 被宣布終結，在接收第一波的震撼之後，不妨讓我們再冷靜思考一下：真的有那麼重要嗎？
話說，現在我們都已經邁入雲端時代了，IT 基礎結構早就悄悄地起了翻天覆地的變化！如果您還沒有感覺，只能說您的環境太封閉了！老實說，這幾年還有誰在意底層的 OS 是甚麼嗎？當大家都在談容器化、K8S、微服務、無伺服器、服務網格、等等新潮技術名詞的時候、當您的服務都在 AWS/GCP/Azure 上面運行的時候，您真的 care 底下 OS 使用哪家的嗎？
嘿老兄！今天您只是要一個網頁與一個資料庫，不就是起一兩個 pod 從 Dockerhub 上面拉 image下來、然後再從 Github 那邊拉 code 就好了嗎？隨著服務規模不斷成長，您需要的只是更彈性的資源與服務調度而非特定的作業系統啊。
- 作為開發者，您或許更關心 CI/CD pipeline 更甚於 K8S CRI 吧？您管它是 cri-o 還是 dockershim 幹嘛呢？
- 作為系統管理員，您或許更關心 API gateway 的穩定性與跨雲的資源管理，而不是去計較底下的 OS 是用 CentOS 還是其他發行版本。
- 作為管理層，您或許只過問您的商業邏輯如何落實、比競爭對手早多少時間搶占市場、用戶體驗是否更加完美。你根本就不需要浪費時間去了解 dockershim 與 CentOS 是甚麼東東！
接下來，您該關心甚麼？
既然上面的兩則新聞對我們的來說都沒啥好擔心的，那我們是否就都佛系就好？
現在，我們的 K8S 有了、映像庫有了、版控與CI/CD有了、雲端管理工具也有了… 請問資料呢都怎麼處理？都還是依賴傳統資料庫還是連資料庫都拆好拆滿了呢？那資料流呢？…
沒錯！這裡要提出的重點是"資料"。當今各大企業的 IT 都忙於技術轉型並紛紛著手微服務架構的導入，各種前端與後端技術紛沓而至，底層的作業系統逐漸變得沒那麼重要。然而大家一陣手忙腳亂之後才發現：真正要面對的"資料"卻沒有相應適當的技術配套來處理。這造成空有微服務的軀殼卻沒有其精髓！
所幸的是，寬橋公司推出的資料中台 Gravity 結合其網格控制器 Pilotwave 與微服務控制器 Twist 剛好能解決企業微服務導入時必須面對的"資料"相關的各項議題。
Gravity 是一個高效的資料快取與發布平台，除了能完整疏導企業業務中台所需的各類型資料之外，還能有效解決資料解偶與碎片化議題。在盡量減少原有資料架構變動的同時，向企業提供立即可用的解決方案並實現各種微服務設計模式及基本架構。基於穩定的軟體元件和平台，確定每個服務扮演的角色，並實作業務邏輯。以其低風險、高效能、高穩定性、可客製化與橫向擴展的產品特性，為企業提供一套部署即用、免開發、低延遲、高吞吐量並支援多種事件來源、通訊協定與異質平台的微服務資料中台。
寬橋公司 BROBRIDGE 著眼於雲端運算管理平台規劃、設計、及開發，以虛擬化、微服務、雲端自動化為主要核心能力。歡迎聯絡寬橋以獲取更多的產品資訊。
結論
把時間省下來吧，忘掉那些紛擾，專注於更需要面對的資料議題更加實際！有些人輸在起跑點，您可別輸在錯誤的方向即可。
