標題: 「如何判別到底要不要使用 Service Mesh」 類別: Network 連結: https://medium.com/google-cloud/when-not-to-use-service-mesh-1a44abdeea31

本篇文章是一個經驗探討文，想要探討近年來非常熱門的網路網格(Service Mesh) 到底導入時要怎麼抉擇與判斷。 Service Mesh 如果用得正確與適當，能夠為團隊帶來很多優勢，可以讓團隊更專注於軟體的服務上，讓 Service Mesh 幫忙提供各種方便的功能。 但是如果使用錯誤則可能只會造成整體架構更加複雜，同時也沒有解決什麼真的重點問題，一切只是疊床架屋的空殼而已。

1. 採用 Service Mesh 要儘早 作者認為到底要不要導入 Service Mesh 是一個專案初期就要決定的事情，即使 Istio 網站有特別教學如何將專案從 non-MTLS 給轉移到基於 Istio MTLS 的過程 但是作者說真的跑過這些流程就知道絕對不是官網寫的三言兩語這麼簡單，有太多額外的事情要考慮，譬如上層安裝的服務，網路分層設計等，這些會因為有沒有 Service Mesh 而有不同的決定

2. 不要當 Yes Man 作者體驗過最多的案例就是每個團隊看到下列問題都是不停的說 YES，然後最後就直接無腦導入 Service Mesh

3. 我們需不需要強化資安

4. 使用 mTLS 能不能強化資安

5. mTLS 是不是很難管理

6. Service Mesh 是不是可以讓 mTLS 便於管理

連續四個 YES 下來就直接無懸念的導入 Service Mesh，殊不知

因此作者接下來就列出幾個要導入 Service Mesh 前需要仔細思考過的問題

1. 是否有計畫於當下或是未來使用到 Serivce Mesh 的所有功能 Service Mesh 的功能除了 mTLS 外還有各式各樣跟流量有關的管理，譬如 A/B Testing, 金絲雀部署等。 透過 Service Mesh 能夠讓應用程式不需要實作這些功能而依然可以享有這些功能的好處。 所以作者認為團隊中的所有人都要仔細的注意，到底你們即將採用的 Service Mesh 有哪些功能可以用，這樣可以避免應用程式重複開發相同功能。 作者也提到不需要第一天就決定好要採用什麼功能，但是至少要仔細理解自己採用的解決方案到底有什麼功能，然後未來改善架構的時候可以即時的想起來這功能有提供

2. 團隊中是否有人對於 Service Mesh 有足夠的理論或是實戰理解？ 作者看到的非常多團隊很多人根本不理解 Kubernetes 以及 Service Mesh 但是就想要導入 Service Mesh。 由於對 Service Mesh 完全不理解，連其實作的概念都不同，所以當問題發生的時候就什麼都不能做，因為根本不懂也不知道該從何下手 請花時間學習與理解你要使用的專案，以確保你有足夠的背景知識去使用與除錯

除了問題之外，作者也認為要導入 Service Mesh 到生產環境並不是單純的建構一個 Hello World 這麼簡單，還有很多事情要考慮，譬如

1. 自動化
2. 監控與追蹤
3. 除錯與已難雜症排除

整篇文章非常的棒，有興趣的可以詳細閱讀

標題: 「透過 Helm 與 Terraform 來自動 Re-new Cloudflare origin CA」 類別: usecase 連結: https://awstip.com/auto-renew-cloudflare-origin-ca-with-terraform-and-helm-d28be3f5d8fa?source=linkShare-91a396987951-1645539866&gi=a18b2bbd9604

本篇文章是過工具介紹文，探討如何基於 Helm 與 Terraform 這兩個不同層級的工具來處理 Cloudflare 的憑證。

Why Cloudflare

根據 W3Techs 的調查顯示， 81.2% 的網站都使用 Cloudflare 來提升讀取速度或安全防護。 透過 CDN 的概念與機制，網站可以讓全球使用者有更快的讀取速度，此外也愈來愈多的網站會透過 Cloudflare 來處理如機器人, DDOS 之類的流量攻擊，畢竟要自己架設網站處理這些攻擊非常困難 因此讓 Cloudflare 這類型的網站來幫忙過濾與處理能夠讓團隊更專注於本身的業務開發與維運

Kubernetes

想要在 Kubernetes 內妥善管理所有使用的憑證其實也是一個麻煩事情，除了要能夠設置正確來創立憑證外，能夠於到期前自動 re-new 也是一個不可或區的功能。 Kubernetes 內跟憑證有關的最知名專案我想就是 Cert-Manager，而 Cloudflare 也基於此專案撰寫了相關的 Kubernetes Controller，如 Origin CA 等 因此本文使用的功能與示範都會基於 cert-manager 與 Cloudflare 的架構。

目的

本文的目的是希望能夠將過往手動的繁瑣步驟給自動化，讓 Kubernetes 可以獲得 Cloudflare 提供的好處，如憑證與相關域名等。 內文是基於 Terraform 作為出發點，然後透過 Kubernetes Provider 的方式來與之互動，一步一步的安裝各種資源最後成功於叢集內獲得相關域名的 SSL 憑證以及其他資源

標題: 「20年工程師生涯教會我的 20 件事情」 類別: others 連結: https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

本篇文章是作者談談自己工程生涯近 20 年的經驗，聊聊 20 個作者覺得很值得跟大家分享的一些想法與經驗。 開頭作者就說，所有的建議與經驗分享最重要的就是脈絡，沒有了脈絡所有的建議可能都沒有任何用處，甚至可能會對你有害 所以作者先表明自己的一些經驗，包含

1. 前半職業生涯作為一個小型公司與新創的軟體工程師。
2. 顧問人生同時加入規模非常大的公司
3. 創立 Simple Thread 這間公司從兩人團隊一路成長至今

這邊節錄幾個經驗，整體來說我認為全部都滿不錯的，都推薦當作心法去看待，甚至也可以作為一些討論的主題。

1. I still don’t know very much: 不知道你有沒有很常聽到別人說「你怎麼會不知道 BGP 怎麼運作？」「你怎麼沒有聽過 RUST ?」，軟體世界的有趣點不論你怎麼學習，每天都有會展新的技術被發展出來 你於你專精的領域努力了十年，對於其他人的領域你會發現還是有很大一片空白需要學習。 所以請認知這一點，軟體世界龐大本來就很容易有不知道的事情，然後保持謙虛的去面對這一切，不要用一種別人都是白癡的態度來質疑別人

2. The best software engineers think like designers 最好的軟體工程師其思路不單純只是滿足功能，而是如同一個設計師一樣，會去思考設計的這個軟體各種使用，包含外部 API的設計，使用者介面，甚至要去考慮 使用者會怎麼使用，使用者為什麼會想要用等，將使用需求放到開發的第一順位才能夠打造一款真的是很適合使用者使用的軟體。

3. Look for technological sharks 那些發展許久至今仍活躍的技術能夠於現在這個迭代快速的世代存活下來必定有其價值與原因，如果今天想要替換掉這些技術一定要有很好的理由與評估，不要單純冒然基於 新技術好像比較好就去替換。這些舊有的技術與工具也許用起來沒有現在這麼潮，但是其穩定性與良好的表現絕對能夠讓你晚上好好睡覺

4. Every system eventually sucks, get over it 軟體開發中沒有一個正確的架構，所有的人無時無刻都在處理相關的技術債，所有開發的介面過一段時間都會因為情境不同而需要改動與重寫，你撰寫的測試永遠都不足夠。 但是這些概念並不能當作一個不往前邁進的理由，相反的就是因為知道沒有一個完美的架構，所以才要更有系統地去持續精進整個架構，永遠都有值得改善與變好的地方 透過不停的循環這個開發流程才能夠讓整個軟體愈來愈好。

文章中還有其他 16 個非常實用的建議，非常推薦大家閱讀閱讀

標題: 「Kubernetes 紀錄片 」 類別: others 連結: https://thenewstack.io/a-kubernetes-documentary-shares-googles-open-source-story/

來自歐洲的 Honeypot.io 與 RedHat, Google 以及 CNCF 合作完成一個長達一小時的 Kubernetes 紀錄片，該紀錄片分成上下兩集，探討 Kubernetes 的發展及過程 被戲稱就像是給開發人員的 Netflix 影片 如果英聽還行的話，非常推薦當個小品影片去聽聽看 Kubernetes 的今生前後

標題: 「Golang 原始碼的的版本控制歷史」 類別: others 連結: https://research.swtch.com/govcs

本篇文章是 rsc 來仔細介紹 golang 的發展歷史，主要是針對整個開發過程的版本控制轉移以及一些有趣的 Commmit 舉例來說，如果你去看 golang 的 commit 會發現第一筆 commit 是 1972 年的內容，並且該 commit 增加了一個 src/pkg/debug/macho/testdata/hello.b 的檔案

而以實際狀況來說，前面四筆都是假的 commit，第五筆 commit 才是 golang 開發的第一筆 commit，這之間的緣由牽扯到版本控制的轉變。 以 Golang 來說，其經歷了四次轉變化，從最初的 Subversion 到 Perforce 到 Mercurial 到 Gerrit

其中 golang 正式對外公開是發生於 Mercurial 的過程中，而這些假的 commit 也是這個時間點由 rsc 自己產生的，當作一個復活節彩蛋的概念 有興趣的可以閱讀全文

標題: 「大家總是喜歡誇大自己的工作時數」 類別: other 連結: https://drmaciver.substack.com/p/people-dont-work-as-much-as-you-think

本篇是一個心態探討文，作者探討了到底一天的有效工作時間有多少，並且認為人們宣稱的工作時間通常都不准，很多時候只是一種想要讓人看到自己工作很久的心態而已。 從作者的經驗來說，作者認為軟體開發，作家，顧問等行業都會有這類型的特性，一個有效率的工作者其實根本不可能一整天連續工作八小時。 一開始作者先列舉自己一天可以達到的事情有哪些(可達到不代表全部都會做)

1. 1-2 小時的重度耗腦力工作，如果事情沒有太複雜有時候可以到三小時左右。
2. 不太動腦 code review 或是閱讀不會花費太多精力，整體來說算可以輕鬆進行
3. 4 小時的面對面教學與指導
4. 4-6 小時左右的常規工作，譬如重構程式碼
5. 4-6 小時左右的沈浸式工作，譬如研究一個困難的 Bug。這類型的工作通常需要當天身心狀況良好同時也沒有人會一直打斷你，通常一年中發生的次數不太高。

總體來說，作者一天認真工作的時間大概就是四小時左右，當然有需求時當然可以提升整體的工作量，不過作者認為這會影響身心健康，所以不是很喜歡。作者也認為「愈需要創作的工作其實真正工作的時間愈少」 很多工程師看起來工時很長其實有時候上班也都在滑 Twitter, Reddit 等各種網站，真正的工作時長其實都不如自己宣稱的。因為每個人的精力有限，不可能長時間執行高度專心的工作，很多時候花一堆時間去拼工作量結果得到的是每件事情都辦不好， 與其如此不如找到一個適合自己的工作方式，讓自己能夠有效率地去做好每件事情。

這邊要特別注意的是

1. 請評估自己每天到底可以工作多少小時，然後不要嘗試工作超時
2. 不要因為自己的精力與工作時數多寡而感到羞愧，好好面對自己
3. 不要為了那些會打破你上述規則的工作而加班

如果今天有人要丟工作給你，請友善禮貌地回答「我很願意幫忙你，不過我目前手頭上正在忙 XYZ，你想要做的事情優先度有比較高嗎？」

最後作者針對工程師列出一個不同類型工作的適合工作時數

1. 1-2 小時的專注工作，如 coding, debugging
2. 1-2 小時的無腦工作，如參加會議， code review
3. 1-2 小時的"可被找到"的時間，譬如 Slack 上可以被找到，可以回答各種問題
4. 結論來說一天工作不會超過四小時

標題: 「ClickHouse 與 Elasticsearch 的比較」 類別: other 連結: https://developer.aliyun.com/article/783804

這篇文章內容非常精彩，從不同層面去探討 Elasticsearch 與 ClickHouse 這兩套解決方案的差異，探討了包含

1. 分散式架構
2. 儲存架構，包含寫入資料的設計，底層 Segment 與 DataPart 的差異以及 Schemaless 特性帶來的影響
3. 查詢架構，包含底層引擎是如何計算使用者的輸入
4. 效能測試，針對不同的場景來比較效能

文章很長且滿多技術坑，適合對於 Elasticsearch 有維運與管理有經驗的使用者

標題: 「Paypal 如何調整 Kubernetes 讓其規模達到四千節點，20萬個 Pod」 類別: usecase 連結: https://medium.com/paypal-tech/scaling-kubernetes-to-over-4k-nodes-and-200k-pods-29988fad6ed

摘要: Paypal 過去一直都使用 Apache Mesos 來運行其大部分的服務，而其最近正在針對 Kubernetes 進行一個評估與測試，想瞭解如果需要轉移到 Kubernetes 會有哪些問題需要挑戰與克服。 本篇文章著重的是效能問題，原先的 Apache Mesos 可以同時支持一萬個節點，因此 Kubernetes 是否可以拿到相同的效能 而本文節錄的就是擴充 Kubernetes 節點中遇到的各種問題以及 Paypal 是如何修正與調整讓 Kubernetes 可能容納盡可能更多的節點。

Cluster Topology

1. 三個 Master 節點與三個獨立的 ETCD 叢集，所有服務都運行於 GCP 上。
2. 工作節點與控制平面的服務都運行於相同的 GCP Zone 上。

Workload

效能測試方面是基於 k-bench 去開發的測試工具，基於平行與依序等不同方式來創建 Pod/Deployment 兩種資源。

Scale

1. 測試初期先以少量的節點與少量的 Pod 開始，接者發現還有提升的空間就會開始擴充 Pod 與節點的數量。
2. 測試的應用程式是一個要求 0.1m CPU 的無狀態應用程式。
3. 最初的工作節有點 4 個 CPU，根據測試可以容納大概 40 Pod 左右。 接者就是不停地擴充數量，先從一千個節點開始，接者調整Pod 的數量直到 32,000 個 Pod。最後擴充到 4,100 個節點並且配上 200,000 個 Pod. 過程後期有調整節點的 CPU 數量讓其能夠容納更多的 Pod 數量

文章接下來開始針對 API Server, Controller Manager, Scheduler, ETCD 元件遇到的問題並且如何解決，中間提到了不少參數，這部分應該是大部分使用者都比較不會去研究與使用的參數 因此我認為本篇文章非常值得閱讀。 ETCD 的部分遇到很嚴重的效能問題，作者團隊觀察到大量的 Raft 溝通失敗個訊息，觀測到跟硬碟寫入速度有關，然而 GCP 沒有辦法單純增加效能，必須要同時提升硬碟空間，所以使用上彈性不變。 不過就算採用 1TB 的 PD-SSD ，當 4 千個節點同時加入到 Kubernetes 時依然會遇到效能上的問題，團隊最後決定使用本地端的 SSD 來想辦法改善寫入速度，結果又遇到 ext4 的一些設定 過程很多問題也很多解決方式。

結論來說: k8s 複雜

標題: 「macOS 的 fsync 實作其實跟大家想像的完全不同 」 類別: others 連結: https://mobile.twitter.com/marcan42/status/1494213855387734019?t=TyXUEg-2LcbNiKkv0JVOsg&s=09

以下節錄自該留言串 「As it turns out, macOS cheats. On Linux, fsync() will both flush writes to the drive, and ask it to flush its write cache to stable storage.

But on macOS, fsync() only flushes writes to the drive. Instead, they provide an F_FULLSYNC operation to do what fsync() does on Linux.」

簡單來說就是 Linux 的 fsync 會執行兩次動作，最終讓當次修改給寫回到底層儲存設備，而 macOS 的版本卻不會真的確認寫回硬碟，所以這個導致很多仰賴 fsync 的應用程式就會有一些不預期的行為，這也是為什麼首篇發文的內容 「Well, this is unfortunate. It turns out Apple's custom NVMe drives are amazingly fast - if you don't care about data integrity.

If you do, they drop down to HDD performance. Thread.」

標題: 「 取代 Docker Desktop 的高效率開發環境」 類別: Container 連結: https://medium.com/partoo/replacing-docker-desktop-with-a-more-efficient-development-environment-582c61c50984

作者認為 Docker Desktop 是一個非常好的開發環境工具，能夠簡化很多設定讓開發者更容易的開發應用程式，但是對於 Windows/Mac 的使用者來說 Docekr Desktop 實際上也是先運行一個基於 Linux 的 VM 並且於其中運行 Docker Container。這種架構實際上帶來了一些使用上的缺陷，包含

1. FileSystem 的處理效能非常不好，不論是使用 cahced 或是 gRPC-fuse 檔案系統還是沒有辦法得到很好的效能。
2. 資源使用有問題不如預期，作者設定希望最多使用 6GB 結果最後卻使用到了 15GB，幾乎吃光系統所有記憶體
3. 官方幾乎沒有文件去探討該 VM 的存取方式(雖然滿多人會用 nsenter 進入)，所以很難把一些本地檔案給直接放到 VM 內來提昇儲存相關的問題，變成所有的儲存都只能用 docker volume 來處理。

作者的公司 Partoo 採取了 VM + Vagrant + Ansible 的方式來創建開發者環境，讓每個加入團隊的開發者都可以輕鬆簡單的建設期開發環境 並且文章中也探討如何於本地端使用 Vistual Studio Code, PyCharm 來編輯 VM 的檔案並且順利的進行應用程式開發。

從效率來看，相對於直接使用 Dodcker Desktop 來看，作者團隊的測試程式基於自己的 VM 提升了將近 30% 的效能，主要的問題就是儲存系統與 Docker Container 之間的掛載關係差異。