靖本

作為基礎設施的編撰工具，Pulumi 額外提供了基於屬性測試 (Property testing) 概念的 Policy as Code 工具 (“CrossGuard”)。基於這個工具，專案團隊或者是組織可以為所有採用 Pulumi 所撰寫的基礎設施程式，建立獨立於所有 IaC 專案的普遍規則 (比方說資源區域、數量、網路設定、IAM 等)，團隊亦可基於此再添加關於專案的額外限制。透過建立完成的可測試規則，開發者可以在本地端、持續整合流水線、以及在最後佈署前(已經產生基於各公雲或基礎設施服務的組態檔時)進行測試確認，避免需要透過人工檢閱比對，或者是已經佈署完畢後再進行確效，所產生的人力或資源的浪費。 本篇文章作為 Policy as Code 系列文章的起頭，會採用 Python 建立一個簡單的 Policy as Code 專案，為稍後建立基礎設施全面性的規則作暖身。 在開始之前 擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$ 安裝 Google Cloud SDK，並且確認已經設定好 application-default Python 為 3.

去年底公佈 CentOS Stream 來替代 CentOS1，也就是說原先的 CentOS 的發佈版本終於迎來它的終焉之時。 簡言之，CentOS 原先作為 RHEL 釋出後的開源版本，如今將重新定位在 Fedora 與 RHEL 釋出之間，成為 RHEL 釋出前的版本，也因為這樣的位置重置，讓原先 CentOS 的用戶立馬就吵翻了天。 不開心! 為何? 先不論是否背叛了開源社群，或者是因為誰而促使這樣的狀況發生。造成這樣的不適感，筆者認為最大的原因有二： 已如理所當然的長期免費資源，如今不再這樣可口。 除 CentOS 6 與 CentOS 7 仍按照原先生命週期外，CentOS 8 並不會按照原先預期的約定，直接改止於 2021 年底。這讓已經投入 CentOS 8 轉換且以此展開產品發展計劃的個人或企業，直接面對這突如其來的變化，反應可想而知不會太好。 關於第二點，雖說按目前軟體發展的模式，尤其紅帽這類大型公司，在持續測試整合上的能力已經相當成熟，不管是相容性與主次版本的相關測試案例，應該都能提供對應的保障，但是一聽到是先於企業版本的發展版本時，誰又願意進一步嘗試或者是相信呢？CentOS Stream 並非突然在 2020 拔地而出，而是在 2019 年時便已經問世，開源使用者固然有關注的義務，然而突如其然的轉換聲明，使用者溝通上顯然不足。不過說到此處，基於第一點，說實在很難找到兩全的方法。或許紅帽能為一些先於RHEL釋出的新功能，提供一些開關，讓使用者對於過新的變化至少有個簡便濾除能力。

General Electric (奇異公司,以下會統一使用GE2來稱呼) 為一個跨國且跨不同產業領域的產業巨擘，2008 年，在 Jeff Immelt3 的支持下開始了轉型之旅，期間各種閃耀的成果與報導不斷，是討論轉型時不能錯過的案例，尤其在討論仍處於熱潮的工業 4.0 時，更應該看看他們的歷程與故事。或許屬於 GE 的最終烏托邦尚未浮現，然而它們的故事仍會繼續，並且探索新的價值。 紀事 2013 年, GE 開始使用自家所打造的工業物聯資料分析平台,Predix，來分析運行於實際場域的機器。 2014 年, GE 聲稱透過 Predix 平台實現了超過 10 億美元利潤4，並且在同年，Jeff 於推特上的一則發文，開始了它們更加積極的數位轉型之旅。 "If you went to bed last night as an industrial company you're going to wake up a software & analytics company.

微服務所帶來的彈性，以及它與CI/CD，與敏捷等所帶來的效率，讓你心動不已嗎？ 微服務和容器、CI/CD、Kubernetes、敏捷等概念有著互相增強彼此所帶來效益的能力。這幾年伴隨著各類技術的發展，台灣自然也沒少了這股熱潮，而這樣的趨勢仍然還在沸騰中。身為一個技術工作者，或許早已看不慣公司裡陳年的大系統，正想一展長才，響應潮流，而管理者或許因為數位轉型與創新的壓力，開始希望從這熱潮中，找尋成功的方程式。 微服務並不是去年才出來的概念，而自家的系統也不是今天才開始運行。先想想「值得嗎？」 微服務是首要之務嗎？ 重構系統將其微服務化是一件極大的工程。相信大家對於微服務所帶來的好處朗朗上口，然而分散式系統的管理複雜度和資源的額外開支，在朗朗上口之餘，也必須認真對待。另外，在過程中可能帶來的業務穩定性衝擊與業務發展資源不足的問題。更重要的是，它所帶來的效益不見得如你所想像的!這幾年穿梭在各類系統架構中，常常必須苦惱不已地進行抉擇，分享幾個思考點，或許能夠在大家踏上旅程前，先想想是否已經可以無悔走上重構： 原先系統的狀態 向原先系統磨刀霍霍之前，先想想「目前原先系統修改的需求高，修改頻繁的發生嗎？」、「大多數新的實作是否仍然增加在原先系統，還是其他服務裡？」如果，原先系統已經處在維護狀態，或者是新的實作大都與原先系統無關，那麼或許更重要的是在流程或其他面向上的優化。 系統已經可預期或已出現容量瓶頸 原先的設計已經限制住系統本身處理當前或者是未來的使用量。如果時常進行尖峰調度，而且調度應變困難，抑或者調度也很難再處理使用量的增長。那麼首要之務，找出瓶頸的服務接口與對應功能類別。作為之後，首要改善之所。 工程資源 任何的改善變更都需要人。如果工程人員已經吃緊，而又另外增加重構改善等任務，那麼下場很可能是不減反增的技術債、業務進展發生開發瓶頸、與惡化的勞動條件。人永遠不是資源，而是企業成長的夥伴！持續性地超支所衍生的代價，恐怕會降低重構的成功機率，以及削減重構所帶來的效益。 原始設計是否良善 單體式(Monolith)架構其實也沒什麼罪惡。如果原始設計已經維持著良好結構，也能正確體現低耦合與高凝聚等特性。那麼它的後續維護其實不見得比較難。難以維護往往是因為求快的實作，導致軟體內部設計耦合度過高，牽一髮動全身，發生問題還無處找之類的狀況。因此，不管在任何時候都好好設計軟體，會讓自己後顧之憂少許多。一個隨便實作的微服務，其實也沒比良善實作單體服務高明到哪？更甚而是不僅要面對可怕的設計外，還要負擔分散式管理的複雜，恐怕問題只是雪上加霜。 如果面對一個既有系統時，已經發生容量問題，設計又差，時常又要新增功能，往往耗損在應對，而非新發展，那麼或許重構是幾乎是你首選了，盤點一下人力狀況和工作配比，為自己重構之路爭取一些支援，反而是你現在該煩惱的，而非是要重構或不重構了。 然而，世事總是讓人陷入兩難，大多數情況都是有點糟，但不是太糟，那麼？