數位科技

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

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

人工智慧對數位轉型產生莫大衝擊以及推力。我想很少人會對這句話產生質疑… 人工智慧在圍棋上打敗人類後，想像空間與可能性便在不同領域持續發酵，彷彿電影內的情節就要活脫脫地呈現在日常生活中。根據市場的調查與推估，以亞太區為範圍的市場規模1 (含括硬體、軟體與服務) 就高達 624 億美元！這樣的趨勢仍以類似指數的曲線往上增長，預期 2027 年的亞太區規模將來到 7337 億美元。不管從個人發展或者從企業發展來看，這是多麼夢幻的成長空間呀！但不管多麼的夢幻，以實際的角度來看，更重要的是 — 你是否在這夢幻樂園內，並且實際從中獲得好處了嗎？ 預測與落地 按 Gartner2 所做出的預測，到 2022 年，只有 20% 左右的資料專案產生實際商業價值，而八成失敗的人工智慧專案有 96%3 的原因來自於資料品質、標記、模型建置。另外，再從 VentureBeat AI4 進一步可以發現 87% 所謂資料科學專案並未走進最後的正式環境，投入使用。

在自動化建置靜態網站基礎設施之一中，我們介紹了如何全面使用 Google 來打造靜態網站的基礎設施，但以一個單純作為靜態網站來說，起初的用戶量與使用情節必然是不太複雜，但全面使用 GCP 的解決方案也就代表了採用負載均衡與 CDN 等相關服務元件，而採用這些元件由於服務水準匹配的原因，也很難降低相關元件(e.g. 負載均衡)的等級，因此，即便流量再小，也必須支付一個月約莫 2x 美元的費用。因此，本文章將介紹利用 Cloudflare 來取代 GCP 的負載均衡與 CDN 相關服務，由於 Cloudflare 有提供免費級別的用量，這對於單純的初期靜態網站來說，應該十分夠用了！接下來，我們就來看看如何用 GCP + Cloudflare，並且基於 Pulumi 打造一個零元的靜態網站基礎設施吧！ 在開始之前 擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$ 建立一個具有合適權限的服務帳號 安裝 Google Cloud SDK，並且確認已經設定好 application-default Python 為 3.