標題: 「別人用 AWS 不代表你要用 AWS」
類別: usecases
連結: https://www.karlsutt.com/articles/you-should-not-be-using-aws/
本篇文章不是一個深度技術文，不過更像是一個文化潮流的省思文，文章中以 AWS 為範例去闡述現在的潮流就是「成功的人用，我也要用」的思維
文中提到「Just because Netflix, which accounts for about 15% of the global internet traffic, has built a complex architecture of custom software and microservices on top of a popular public cloud provider does not mean you absolutely, positively have to replicate their setup.」
想想你的應用規模跟架構，再想想 Netflix 跟你的差異，你真的覺得你需要一開始就打造跟 Netflix 一樣的底層架構嗎？
此外作者還提出一個迷思概念，很多使用最新技術的案例其實成功的原因不是「使用最新最潮的技術」，這些「最新最潮的技術」只是剛剛好被用到而已。
最後文末有三個概念提出分別是
1. Optimise for operational simplicity
2. Optimise for internal simplicity
3. Focus on delivering value to your users
有興趣的可以閱讀全文
類別: usecases
連結: https://www.karlsutt.com/articles/you-should-not-be-using-aws/
本篇文章不是一個深度技術文，不過更像是一個文化潮流的省思文，文章中以 AWS 為範例去闡述現在的潮流就是「成功的人用，我也要用」的思維
文中提到「Just because Netflix, which accounts for about 15% of the global internet traffic, has built a complex architecture of custom software and microservices on top of a popular public cloud provider does not mean you absolutely, positively have to replicate their setup.」
想想你的應用規模跟架構，再想想 Netflix 跟你的差異，你真的覺得你需要一開始就打造跟 Netflix 一樣的底層架構嗎？
此外作者還提出一個迷思概念，很多使用最新技術的案例其實成功的原因不是「使用最新最潮的技術」，這些「最新最潮的技術」只是剛剛好被用到而已。
最後文末有三個概念提出分別是
1. Optimise for operational simplicity
2. Optimise for internal simplicity
3. Focus on delivering value to your users
有興趣的可以閱讀全文
Karl Sutt
You should not be using AWS. Probably.
Why choosing a popular cloud service, like AWS or Google Cloud Platform, may be the wrong choice for you and what to do instead.
標題: 「從 SRE 的觀點來看，如何打造一個對開發也對維運都有好處的軟體服務」
類別: usecases
連結: https://www.willett.io/posts/precepts/
作者汲取這多年來參與不同規模團隊合作下的經驗，思考如何打造出一個更適合維運的應用服務，這些經驗的目的並不是打造一個 100% 完美絕對穩到炸不會出包的服務，相反的
更注重於「如何透過 20% 的努力來獲得 80% 的可靠性，同時開發人員也不會覺得窒礙難行」
文章主要分成四大項，分別是
Coding
Merging
Deploying
Operating
每大項內又有幾個小項目分別舉例，這邊稍微汲取幾個範例與想法，作者的每一個想法不一定適合每個團隊，不過可以聽取看看不同人的想法來想想這些提到的優缺點目前團隊工作流程是否有出現？ 有的話應該要怎麼解決？或是現有的解決方式是否有改進的空間？
# Coding
No in-code fallbacks for configs -> 如果你的應用程式運行初期讀取不到任何應該要讀到的設定時，就應該儘早死去來達成 fail fast, fail early 的概念， config 往往會決定應用程式的行為，不會動或是缺少設定的話就及早自殺，讓整個問題可以更快被發現，最害怕的就是明明少了一個重要的 config 結果該 config 相關的程式碼要到重要時刻才會被執行到，然後整個爆炸時間點就被延後，最後還要花費更多的時間與精力去找問題發生點
Avoid state like the plagu -> 有狀態的程式其管理複雜度不是無狀態程式可以比擬的，就算有了各種容器管理機制整體複雜度還是非常高，能的話將這些狀態都送往 DB/Cache 去處理，盡可能打造一個好維護的無狀態程式
Never give up on local testing -> 相較於 CI 等自動化測試等流程來說，本地測試所需的時間其實更少，從消耗時間來看是能夠提升開發者生產速度的，然而本地測試相對麻煩的就是環境的建置，因此有機會的，可以嘗試透過容器化的方式來系統化建置測試環境，讓開發者都可以一邊開發一邊本地測試。
# Merging
For infra changes, make plans extremely obvious -> 想辦法讓任何 infra 的改變是顯而易見可預料的，譬如使用 Terraform 進行管理的團隊最好將 terraform plan 的結果整合到 CI 與 Review 的過程中，這樣大家都可以一目瞭然到底這次的修改會產生什麼樣的變化，同樣的對於 Helm 應用來說，可以透過第三方plugin, Helm diff 來幫你檢視一下當前版本與即將升級版本的差異，到底有哪些資源會被創立哪些資源會被移除。
# Operating
Use Helm -> 使用 Helm 或是其他如 kustomize, jsonnet...etc 等工具來管理 Kubernetes 檔案，非特殊情況不要一直透過 kubectl apply/edit/delete 等來管理應用程式的部署狀況，所有的部署情況都應該可以被追蹤與管理
Avoid operators and CRDs -> Kubernetes 好棒棒，但是對於開發者來說，從 Container 到 Kubernters 的鴻溝太大，這中間的學習過程一旦扯入了 CRD 就會有更多未知的事情發生，所以作者認為能的話盡量讓事情保持簡單，減少用 operators 等機制這些增加複雜性的東西
類別: usecases
連結: https://www.willett.io/posts/precepts/
作者汲取這多年來參與不同規模團隊合作下的經驗，思考如何打造出一個更適合維運的應用服務，這些經驗的目的並不是打造一個 100% 完美絕對穩到炸不會出包的服務，相反的
更注重於「如何透過 20% 的努力來獲得 80% 的可靠性，同時開發人員也不會覺得窒礙難行」
文章主要分成四大項，分別是
Coding
Merging
Deploying
Operating
每大項內又有幾個小項目分別舉例，這邊稍微汲取幾個範例與想法，作者的每一個想法不一定適合每個團隊，不過可以聽取看看不同人的想法來想想這些提到的優缺點目前團隊工作流程是否有出現？ 有的話應該要怎麼解決？或是現有的解決方式是否有改進的空間？
# Coding
No in-code fallbacks for configs -> 如果你的應用程式運行初期讀取不到任何應該要讀到的設定時，就應該儘早死去來達成 fail fast, fail early 的概念， config 往往會決定應用程式的行為，不會動或是缺少設定的話就及早自殺，讓整個問題可以更快被發現，最害怕的就是明明少了一個重要的 config 結果該 config 相關的程式碼要到重要時刻才會被執行到，然後整個爆炸時間點就被延後，最後還要花費更多的時間與精力去找問題發生點
Avoid state like the plagu -> 有狀態的程式其管理複雜度不是無狀態程式可以比擬的，就算有了各種容器管理機制整體複雜度還是非常高，能的話將這些狀態都送往 DB/Cache 去處理，盡可能打造一個好維護的無狀態程式
Never give up on local testing -> 相較於 CI 等自動化測試等流程來說，本地測試所需的時間其實更少，從消耗時間來看是能夠提升開發者生產速度的，然而本地測試相對麻煩的就是環境的建置，因此有機會的，可以嘗試透過容器化的方式來系統化建置測試環境，讓開發者都可以一邊開發一邊本地測試。
# Merging
For infra changes, make plans extremely obvious -> 想辦法讓任何 infra 的改變是顯而易見可預料的，譬如使用 Terraform 進行管理的團隊最好將 terraform plan 的結果整合到 CI 與 Review 的過程中，這樣大家都可以一目瞭然到底這次的修改會產生什麼樣的變化，同樣的對於 Helm 應用來說，可以透過第三方plugin, Helm diff 來幫你檢視一下當前版本與即將升級版本的差異，到底有哪些資源會被創立哪些資源會被移除。
# Operating
Use Helm -> 使用 Helm 或是其他如 kustomize, jsonnet...etc 等工具來管理 Kubernetes 檔案，非特殊情況不要一直透過 kubectl apply/edit/delete 等來管理應用程式的部署狀況，所有的部署情況都應該可以被追蹤與管理
Avoid operators and CRDs -> Kubernetes 好棒棒，但是對於開發者來說，從 Container 到 Kubernters 的鴻溝太大，這中間的學習過程一旦扯入了 CRD 就會有更多未知的事情發生，所以作者認為能的話盡量讓事情保持簡單，減少用 operators 等機制這些增加複雜性的東西
Brandon Website
How to Build Software like an SRE
I’ve been doing this “reliability” stuff for a little while now (~5 years), at companies ranging from about 20 developers to over 2,000. I’ve always cared primarily about the software elements I describe as living “outside” the application – like, how does…
標題: 「由 Google 開發的 Kubernetes Queue 開源方案: Kueue」
類別: Kubernetes
連結: https://kubernetes.io/blog/2022/10/04/introducing-kueue/
本篇來自官方部落格的文章要介紹的是由 kubernetes-sig 底下所開發的專案, Kueue 是一套專門針對 Kubernetes Job 的 Queue 管理開源解決方案
Job queueing 是一個不論是地端或是雲端都可以用到的功能，將 Kubernetes Job 給進行佇列排程確保當前有限的系統資源可以依序的被這些 Job 存取
而 Kueue 則是基於 Job 這個運算單元上提供了 Job queueing 的功能，可以決定哪些 Job 要馬上執行，哪些要等待以及哪些資源要被這些 Job 給存取。
文章提到幾個 Job queueing 希望達到的功能有
1. 多租戶環境下希望每個租戶的能夠使用的資源是公平分配的，譬如不活躍租戶底下的資源可以暫時借給其他活躍的租戶去運行
2. Job 可以彈性的根據不同環境來配置不同的資源用量，譬如 spot/on-demand，或是有不同型號的 CPU/GPU 等
3. 能夠根據資源的配置而自動擴展
原生的 Kubernetes 的 Job/Cronjob 功能非常單純，所以需求都要仰賴其他解決方案，而 Kueue 認為這些解決方案的問題都是他們都必須要替換掉現存穩定的 kube-scheudler/job-controller，這些可能會造成
維運上的問題甚至是造成 job APIs 的複雜化，所以如果可以從原生內部直接支援，對於所有使用者來說則是會更好的使用方式
有興趣的可以閱讀全文來研究看看這個開發中的專案
類別: Kubernetes
連結: https://kubernetes.io/blog/2022/10/04/introducing-kueue/
本篇來自官方部落格的文章要介紹的是由 kubernetes-sig 底下所開發的專案, Kueue 是一套專門針對 Kubernetes Job 的 Queue 管理開源解決方案
Job queueing 是一個不論是地端或是雲端都可以用到的功能，將 Kubernetes Job 給進行佇列排程確保當前有限的系統資源可以依序的被這些 Job 存取
而 Kueue 則是基於 Job 這個運算單元上提供了 Job queueing 的功能，可以決定哪些 Job 要馬上執行，哪些要等待以及哪些資源要被這些 Job 給存取。
文章提到幾個 Job queueing 希望達到的功能有
1. 多租戶環境下希望每個租戶的能夠使用的資源是公平分配的，譬如不活躍租戶底下的資源可以暫時借給其他活躍的租戶去運行
2. Job 可以彈性的根據不同環境來配置不同的資源用量，譬如 spot/on-demand，或是有不同型號的 CPU/GPU 等
3. 能夠根據資源的配置而自動擴展
原生的 Kubernetes 的 Job/Cronjob 功能非常單純，所以需求都要仰賴其他解決方案，而 Kueue 認為這些解決方案的問題都是他們都必須要替換掉現存穩定的 kube-scheudler/job-controller，這些可能會造成
維運上的問題甚至是造成 job APIs 的複雜化，所以如果可以從原生內部直接支援，對於所有使用者來說則是會更好的使用方式
有興趣的可以閱讀全文來研究看看這個開發中的專案
Kubernetes
Introducing Kueue
Whether on-premises or in the cloud, clusters face real constraints for resource usage, quota, and cost management reasons. Regardless of the autoscalling capabilities, clusters have finite capacity. As a result, users want an easy way to fairly and efficiently…
標題: 「Istio Ambient Mesh 初體驗」
類別: Netowrks
連結: https://medium.com/@ridgway2/trying-istios-ambient-mesh-3497949aba46
不久前 Istio 宣佈一個基於 sidecarless 的全新實作專案 Ambient Mesh，而本篇文章就是嘗試玩看看 Ambient Mesh 的一些踩雷心得。
Ambient Mesh 的目標就是透過 Daemonset 來取代過往每個服務獨立配置一個 sidecare 的架構，透過該 daemonset 來處理所有的流量並提供過往的如 mTLS, traffic engineering 等功能。
從好處來想系統資源量會獲得大量的釋放，不需要為每個 sidecar 提供相對應的 CPU/Memory，但是單一節點是否會有額外的效能瓶頸以及 Signle Point of Failur 則是另外一個隱憂
該 Ambient Mesh 專案現階段還屬於開發測試中，所以單純玩玩還不要著急上到任何正式環境，有興趣的就多給一些時間並且長期關注即可
本篇文章提到如何透過 KIND 搭建一個測試環境，並且於該環境上去部署 Ambient Mesh 並且部署測試用服務
對於 Ambient Mesh 想要玩玩的也許可以參考這篇文章快速搭建環境，並且實際觀察一下系統差異以及針對兩種架構設計一致的實驗環境，這樣更可以比較出兩種的差異性
類別: Netowrks
連結: https://medium.com/@ridgway2/trying-istios-ambient-mesh-3497949aba46
不久前 Istio 宣佈一個基於 sidecarless 的全新實作專案 Ambient Mesh，而本篇文章就是嘗試玩看看 Ambient Mesh 的一些踩雷心得。
Ambient Mesh 的目標就是透過 Daemonset 來取代過往每個服務獨立配置一個 sidecare 的架構，透過該 daemonset 來處理所有的流量並提供過往的如 mTLS, traffic engineering 等功能。
從好處來想系統資源量會獲得大量的釋放，不需要為每個 sidecar 提供相對應的 CPU/Memory，但是單一節點是否會有額外的效能瓶頸以及 Signle Point of Failur 則是另外一個隱憂
該 Ambient Mesh 專案現階段還屬於開發測試中，所以單純玩玩還不要著急上到任何正式環境，有興趣的就多給一些時間並且長期關注即可
本篇文章提到如何透過 KIND 搭建一個測試環境，並且於該環境上去部署 Ambient Mesh 並且部署測試用服務
對於 Ambient Mesh 想要玩玩的也許可以參考這篇文章快速搭建環境，並且實際觀察一下系統差異以及針對兩種架構設計一致的實驗環境，這樣更可以比較出兩種的差異性
Medium
Trying Istio’s Ambient Mesh
Link: Ambient Mesh
標題: 「SOPS 一套讓你肉眼即所得的 Secret 編輯器」
類別: Tools
連結: https://medium.com/4th-coffee/a-comprehensive-guide-to-sops-managing-your-secrets-like-a-visionary-not-a-functionary-9ceefee917d
不知道你是否曾經因為某些條件與情境，想要將一些機密資訊放到 git 等相關可以供團隊共同使用的環境下?
Kubernetes 中的 secret 物件可以透過 sealedsecret 的方式對齊加密，但是這類型的用法只限定於 Kubernetes 應用
想要更常態性的加解密支援可能就會出現如 Git-Crypt 這類型的專案，與 Git 整合透過 GPG Key 針對特定檔案加密，只有被設定相關 GPG 的使用者才有辦法解開這些內容來進行讀取。
這類型的工具操作通常加解密都需要兩個步驟
編輯檔案內容 -> 加密
解密->閱讀檔案內容
該兩步驟乍看之下沒有任何問題，但是對於某些極度資安管理的環境就有可能會有小漏洞，譬如某使用者閱讀完檔案內容後忘了加密回去，導致系統掃到某人資料夾下有些機密資訊，最後觸發相關安全性警告
而本文的 SOPS (Secret OPerationS) 就是由 Mozilla 所開發的替代工具，將上次兩個步驟給整合，是一個可以針對檔案內容去加解密的工具。
跟 Git-Crypt 直接將整個檔案進行加解密完全不同， SOPS 加解密的目標則是 YAML/Json 內的欄位，這意味對於使用者來說你可以明確知道該欄位的 Key 是什麼，而 Value 則會被進行加密處理。
整個使用邏輯非常簡單，當該檔案被 SOPS 進行加密後，接下來所有指令去閱讀檔案都會得到加密後的內容，只有透過 SOPS 的內建編輯器去讀取才可以得到解密的結果，這意味者就算將該檔案給放到 Git 上，使用者看到的是針對"Value"加密後的結果，相對 git-crypt 是整個檔案加密， SOPS 的方式會適當的揭露該檔案格式與用法(好壞不一定)。
此外 SOPS 除了基本的 GPG Key 加密方式外，還支援不同服務，如
1. AWS KMS
2. GCP KMS
3. Azure Key Vault
4. HashiCorp Vault
基本上三大公有雲外加知名度超高的 HashiCorp Vault 都有支援，所以如果環境中本來就有使用這些服務的話，使用者就可以更輕易去整合與管理使用的 Key
文章基本上就是介紹這個工具並且示範跟上述每個類別的使用方式與整合，如果對於這個專案覺得有點興趣的，可以快速看一下本篇文章該工具是什麼以及怎麼使用
類別: Tools
連結: https://medium.com/4th-coffee/a-comprehensive-guide-to-sops-managing-your-secrets-like-a-visionary-not-a-functionary-9ceefee917d
不知道你是否曾經因為某些條件與情境，想要將一些機密資訊放到 git 等相關可以供團隊共同使用的環境下?
Kubernetes 中的 secret 物件可以透過 sealedsecret 的方式對齊加密，但是這類型的用法只限定於 Kubernetes 應用
想要更常態性的加解密支援可能就會出現如 Git-Crypt 這類型的專案，與 Git 整合透過 GPG Key 針對特定檔案加密，只有被設定相關 GPG 的使用者才有辦法解開這些內容來進行讀取。
這類型的工具操作通常加解密都需要兩個步驟
編輯檔案內容 -> 加密
解密->閱讀檔案內容
該兩步驟乍看之下沒有任何問題，但是對於某些極度資安管理的環境就有可能會有小漏洞，譬如某使用者閱讀完檔案內容後忘了加密回去，導致系統掃到某人資料夾下有些機密資訊，最後觸發相關安全性警告
而本文的 SOPS (Secret OPerationS) 就是由 Mozilla 所開發的替代工具，將上次兩個步驟給整合，是一個可以針對檔案內容去加解密的工具。
跟 Git-Crypt 直接將整個檔案進行加解密完全不同， SOPS 加解密的目標則是 YAML/Json 內的欄位，這意味對於使用者來說你可以明確知道該欄位的 Key 是什麼，而 Value 則會被進行加密處理。
整個使用邏輯非常簡單，當該檔案被 SOPS 進行加密後，接下來所有指令去閱讀檔案都會得到加密後的內容，只有透過 SOPS 的內建編輯器去讀取才可以得到解密的結果，這意味者就算將該檔案給放到 Git 上，使用者看到的是針對"Value"加密後的結果，相對 git-crypt 是整個檔案加密， SOPS 的方式會適當的揭露該檔案格式與用法(好壞不一定)。
此外 SOPS 除了基本的 GPG Key 加密方式外，還支援不同服務，如
1. AWS KMS
2. GCP KMS
3. Azure Key Vault
4. HashiCorp Vault
基本上三大公有雲外加知名度超高的 HashiCorp Vault 都有支援，所以如果環境中本來就有使用這些服務的話，使用者就可以更輕易去整合與管理使用的 Key
文章基本上就是介紹這個工具並且示範跟上述每個類別的使用方式與整合，如果對於這個專案覺得有點興趣的，可以快速看一下本篇文章該工具是什麼以及怎麼使用
Medium
A Comprehensive Guide to SOPS: Managing Your Secrets Like A Visionary, Not a Functionary
Have you heard of SOPS? If you are in a situation where you needed to share sensitive information with your teammates, this is for you.
標題: 「以 kube-bench/kubescape 為基準示範如何用逐步打造 DevSecOps 」
類別: Tools
連結: https://medium.com/@sdevsecops/how-to-implement-devsecops-in-a-kubernetes-cluster-environment-github-actions-and-azure-devops-522bdd121e34
這年頭除了 DevOps 外，愈來愈多的變形名詞被發明出來，當然每個名詞背後都有自己想要解決的問題，特別是當整個生態環境都往自動化與容器化發展後，整個 SDLC(Software Development Life Cycle) 也必須要因應而變，而其中 DevSecOps 這個名詞也是逐漸浮上檯面。
其中很多文章都會提到所謂的 Software Supply Chain，當整個環境架構整合到 Kubernetes 或是相關容器化平台時，整個軟體供應鏈的長度就愈來愈長，從應用程式本身的測試與編譯，到相關 Container Image 的建立，到相關 YAML/JSON 資源狀態的敘述與安裝最後到目標平台運行起應用程式。
每個階段除了基本目標外，還有如相依性軟體本身的安全性，平台面對使用者的權限操作等各種安全性議題要探討，所以要真正實作一個完整的 DevSecOps 沒有這麼簡單也不是一兩個工具就可以搞定的，就跟所有的架構開發一樣，都是由小出發，慢慢根據需求進行改良與調整。
本文前面探討了些關於安全的一些議題，提到了由 CIS 所制定的資安相關 benchmark，以及示範的相關工具，分別是 kube-bench 以及 kubescape，至於後半部分如何使用這套工具於
Github action 則不是太重要。
Kube-bench 則是一套以 go 撰寫且基於 K8s CIS benchmark 的掃描工具，該專案目前星星數也有5.3k左右，至少可以說明關注度不太低，至於該工具到底檢查哪些設定這部分則要直接去看 CIS Benchmark，該網站內有針對 kubernetes 去進行探討什麼樣的設定是安全，什麼樣是不安全。
kubescape 則是希望針對目標 kubernetes cluster 提供一套更為清晰的分析工具，包含
1. 運行的容器是否有潛藏的 vulnerability
2. 視覺化當前叢集中 RBAC 的設定
3. 相關資安設定是否符合標準
而實作方面可以針對當前運行的 kubernetes cluster 進行掃描分析，也可以針對如 YAML/HELM 等檔案進行掃描，然後根據如 NSA-CISA, MITRE ATT&CK 等框架的內容去判別哪些設定是不適當的，可能會有安全疑慮的。
透過這些工具能夠盡可能提早的於 CI/CD 階段先行找出一些不夠安全的設定，避免這些設定被套用到正式生產的 cluster 上
對於這兩套工具的可以花點時間研究看看是否能夠幫助團隊解決一些問題
類別: Tools
連結: https://medium.com/@sdevsecops/how-to-implement-devsecops-in-a-kubernetes-cluster-environment-github-actions-and-azure-devops-522bdd121e34
這年頭除了 DevOps 外，愈來愈多的變形名詞被發明出來，當然每個名詞背後都有自己想要解決的問題，特別是當整個生態環境都往自動化與容器化發展後，整個 SDLC(Software Development Life Cycle) 也必須要因應而變，而其中 DevSecOps 這個名詞也是逐漸浮上檯面。
其中很多文章都會提到所謂的 Software Supply Chain，當整個環境架構整合到 Kubernetes 或是相關容器化平台時，整個軟體供應鏈的長度就愈來愈長，從應用程式本身的測試與編譯，到相關 Container Image 的建立，到相關 YAML/JSON 資源狀態的敘述與安裝最後到目標平台運行起應用程式。
每個階段除了基本目標外，還有如相依性軟體本身的安全性，平台面對使用者的權限操作等各種安全性議題要探討，所以要真正實作一個完整的 DevSecOps 沒有這麼簡單也不是一兩個工具就可以搞定的，就跟所有的架構開發一樣，都是由小出發，慢慢根據需求進行改良與調整。
本文前面探討了些關於安全的一些議題，提到了由 CIS 所制定的資安相關 benchmark，以及示範的相關工具，分別是 kube-bench 以及 kubescape，至於後半部分如何使用這套工具於
Github action 則不是太重要。
Kube-bench 則是一套以 go 撰寫且基於 K8s CIS benchmark 的掃描工具，該專案目前星星數也有5.3k左右，至少可以說明關注度不太低，至於該工具到底檢查哪些設定這部分則要直接去看 CIS Benchmark，該網站內有針對 kubernetes 去進行探討什麼樣的設定是安全，什麼樣是不安全。
kubescape 則是希望針對目標 kubernetes cluster 提供一套更為清晰的分析工具，包含
1. 運行的容器是否有潛藏的 vulnerability
2. 視覺化當前叢集中 RBAC 的設定
3. 相關資安設定是否符合標準
而實作方面可以針對當前運行的 kubernetes cluster 進行掃描分析，也可以針對如 YAML/HELM 等檔案進行掃描，然後根據如 NSA-CISA, MITRE ATT&CK 等框架的內容去判別哪些設定是不適當的，可能會有安全疑慮的。
透過這些工具能夠盡可能提早的於 CI/CD 階段先行找出一些不夠安全的設定，避免這些設定被套用到正式生產的 cluster 上
對於這兩套工具的可以花點時間研究看看是否能夠幫助團隊解決一些問題
Medium
How to implement DevSecOps in a Kubernetes cluster environment-Github Actions and Azure DevOps
Before diving into DevSecOps implementation for a kubernetes cluster, let us understand a bit on what is kubernetes. Kubernetes is an open…
標題: 「Kubernetes 1.25 簡單介紹 」
類別: Tools
連結: https://medium.com/@i191693/major-changes-in-kubernetes-version-1-25-f29974a7aa57
今年 8月23日釋出的 Kubernetes 1.25 除了眾多的 bug 修復外，也帶來了將近 40 項的改正，大部分都是一些功能的階段演進，譬如下列功能就正式進入到 Stable 階段
- Ephemeral Containers
- Local Ephemeral Storage resource Management
- CSI Ephemeral Volumes
- CSI Migration-Core
- CSI Migration-AWS
- CSI Migration-GCE
- DaemonSets Support MaxSurge
- cgroups version 2
- Pod Security Admission
- Add minReadySeconds to Statefulsets
- Identify windows pods at API admission level authoritatively
- Network Policy Port Range
- Graduate the kube-schedular ComponentConfig to GA
講到 CSI 也要特別注意所有 in-tree 的支援度，譬如這次就標示 GlusterFS 於 in-tree 的功能為 depreciated，這也意味如果本身沒有特別安裝 CSI Driver 的 GlusterFS 使用者不要貿然升級到未來幾個版本，不然可能一升級就發現儲存功能直接炸了。
另外講了很久的 PSP (Pod Security Policy) 自從 1.21 被標示為 depreciated 後正式於 1.25 正式移除， PSP 本身立意良好，無奈其架構與使用方式並不討喜，更麻煩的是每次 PSP 的更新都只會針對之後運行的 Pod 進行控管，並沒有辦法對已經運行的 Pod 去處理，這使得使用上帶來些許不便。
因此 1.25 移除的同時也將 Pod Security Admission 這個替代品提升為 stable 的階段，PSA 內建三種不同層級的設定，並且可以以 namespace 為單位去設定與控管，對於團隊來說可以減少各種重複的安全性設定，直接以 namespace 為基礎去處理。
除了 PSP 外，官網也推薦其他三種替代 PSP 的解決方案，如 Kubewarden, Kyverno 以及 OPA Gatekeeper
類別: Tools
連結: https://medium.com/@i191693/major-changes-in-kubernetes-version-1-25-f29974a7aa57
今年 8月23日釋出的 Kubernetes 1.25 除了眾多的 bug 修復外，也帶來了將近 40 項的改正，大部分都是一些功能的階段演進，譬如下列功能就正式進入到 Stable 階段
- Ephemeral Containers
- Local Ephemeral Storage resource Management
- CSI Ephemeral Volumes
- CSI Migration-Core
- CSI Migration-AWS
- CSI Migration-GCE
- DaemonSets Support MaxSurge
- cgroups version 2
- Pod Security Admission
- Add minReadySeconds to Statefulsets
- Identify windows pods at API admission level authoritatively
- Network Policy Port Range
- Graduate the kube-schedular ComponentConfig to GA
講到 CSI 也要特別注意所有 in-tree 的支援度，譬如這次就標示 GlusterFS 於 in-tree 的功能為 depreciated，這也意味如果本身沒有特別安裝 CSI Driver 的 GlusterFS 使用者不要貿然升級到未來幾個版本，不然可能一升級就發現儲存功能直接炸了。
另外講了很久的 PSP (Pod Security Policy) 自從 1.21 被標示為 depreciated 後正式於 1.25 正式移除， PSP 本身立意良好，無奈其架構與使用方式並不討喜，更麻煩的是每次 PSP 的更新都只會針對之後運行的 Pod 進行控管，並沒有辦法對已經運行的 Pod 去處理，這使得使用上帶來些許不便。
因此 1.25 移除的同時也將 Pod Security Admission 這個替代品提升為 stable 的階段，PSA 內建三種不同層級的設定，並且可以以 namespace 為單位去設定與控管，對於團隊來說可以減少各種重複的安全性設定，直接以 namespace 為基礎去處理。
除了 PSP 外，官網也推薦其他三種替代 PSP 的解決方案，如 Kubewarden, Kyverno 以及 OPA Gatekeeper
Medium
Major Changes In Kubernetes version 1.25
Kubernetes version 1.25 was released on August 23, 2022. It came with many bug fixes and 40 new enhancements in different areas among which…
標題: 「kubeshark: 一套整合 chrome dev tool + tcpdump + wireshark 的 k8s 專屬工具 」
類別: Tools
連結: https://github.com/kubeshark/kubeshark
kubeshark 提供視覺化的方式去檢視 k8s 叢集中 Pod 相關的 API 流量，基本上看了 README 的範例大概就可以知道這個工具的用途了
如果整體的資源消耗不大同時使用簡單的話，也許對於開發者來說是一個福音，能夠用最簡易的方式去觀察與除錯想要對付的 Pod/Container
類別: Tools
連結: https://github.com/kubeshark/kubeshark
kubeshark 提供視覺化的方式去檢視 k8s 叢集中 Pod 相關的 API 流量，基本上看了 README 的範例大概就可以知道這個工具的用途了
如果整體的資源消耗不大同時使用簡單的話，也許對於開發者來說是一個福音，能夠用最簡易的方式去觀察與除錯想要對付的 Pod/Container
GitHub
GitHub - kubeshark/kubeshark: eBPF-powered network observability for Kubernetes. Indexes L4/L7 traffic with full K8s context, decrypts…
eBPF-powered network observability for Kubernetes. Indexes L4/L7 traffic with full K8s context, decrypts TLS without keys. Queryable by AI agents via MCP and humans via dashboard. - kubeshark/kubes...
標題: 「Netflix 經驗分享: 從 cache 觀察到的效能問題」
類別: Tools
連結: https://netflixtechblog.com/seeing-through-hardware-counters-a-journey-to-threefold-performance-increase-2721924a2822
Netflix 官方不定時都會分享非常多有趣且技術深度足夠的文章，本篇文章主要是探討將機器強度給調整後整個系統效能卻不如預期增長然後除錯找到問題點的故事。
今日的主角是一個用 java 寫成的應用程式，透過 AWS 的 ASG (Auto Scaling Group) 根據 CPU 用量來動態調整服務的數量，同時前方透過 rounb-robin 的 load-balancer 來平均分散流量到後方。
該服務原本是部署到 m5.4xl (16 vCPU) 的機器上，根據需求調整到 m5.12xl (48 vCPU) 的機器人，本來預計整體的效能能夠如線性般的三倍成長，結果整體表現非常的糟。
從效能來看，整體 throughput 平均只有提升 25%，此外更糟糕的是整個 latency 卻提升了將近 50%
提升機器等級提供更多 CPU 結果 latency 大幅度增長，這個結果實在是非常奇怪，所以團隊馬上開始研究來探索到底發生什麼事情。
首先，由於所有的流量都是透過 load-balancer，所以本來也預期這個問題應該是所有節點都有的，結果又發生更神秘的狀況，只有大概 12% 的節點是如預期般成長，剩下 88% 的節點幾乎都有這種效能下降的情況。
團隊的第一步驟就是透過火焰圖來比較看不同表現結果的節點會有什麼差異，接者又從 JVM 出發去看看從 JVM 是否有什麼直得注意的現象。
團隊從 app, JVM 到 OS 層級都嘗試找尋問題，但是還沒有辦法得到一個非常篤定且合理的答案，這時候開始懷疑可能是更底層的問題造成的，因此這時候決定使用 PerfSpect 此工具來觀察不同節點的現象。
該工具列出兩個節點運行上有一個顯著的數值差異，CPI (Cycles Per Instruction) 有將近三倍的差異，此外也觀察到節點上 L1 Cache 關於 MACHINE_CLEARS 的執行次數也有四倍差異。
仔細研究後觀察到這些參數會跟一個名為 "false sharing" 的狀況所導致的，而 false sharing 的意思是當有兩個 Core 嘗試從一個相同的 L1 cahce line(類似 memory page) 上讀取一個不相干的變數時造成的效能減損。
每個 Core 基本上都有屬於自己的 private cache，兩個 core 所屬的 cache 是來自於相同的 memory page，這個限制使得各自 cache 必須要維持一致，也就是這個維持一致的要求導致了問題發生。
舉例來說當 Thread A 嘗試寫入一個 Red 變數到 cache line 中，這時候系統會將 Thread A 底下的 cache 標示為 "moodified"，同時將 Thread B 底下的 cache 標示為 "invalidated".
接者當 Thread B 嘗試讀取一個名為 blue 的變數，理想狀況來說，兩個 thread 用到的變數不同，所以其實 Thread B 直接讀取自己的 cache 結果論來說是沒有問題，但是因為共享 memory page 的原因，所以系統這時候會強迫同步彼此的 cache 得資料讓 Thread B 上的 cache 先更新接者才讀取。 就是這個舉動操作使得整個效能大幅度下降。
團隊接者使用 Intel vTune 的工具來進行更底層的分析來觀察這類型的 false sharing 問題到底發生到哪，最後得出一個結論
Cache line 的大小是 64 bytes，然而使用的 pointer 是 8 bytes，所以有 8/64(12.5%) 的機會是正常使用，而有 56/64(87%) 的機會會產生 false sharing 的情形，此外這個數字也跟前述的節點分佈比例也幾乎一樣。
文章內有針對這個 vTune 的工具以及分析有更清楚的介紹，後半部分還有另外一個 true sharing 的問題，同時文章內也都有介紹這兩個問題的解法以及最後修改後的效能增長。
有興趣的可以閱讀全文
類別: Tools
連結: https://netflixtechblog.com/seeing-through-hardware-counters-a-journey-to-threefold-performance-increase-2721924a2822
Netflix 官方不定時都會分享非常多有趣且技術深度足夠的文章，本篇文章主要是探討將機器強度給調整後整個系統效能卻不如預期增長然後除錯找到問題點的故事。
今日的主角是一個用 java 寫成的應用程式，透過 AWS 的 ASG (Auto Scaling Group) 根據 CPU 用量來動態調整服務的數量，同時前方透過 rounb-robin 的 load-balancer 來平均分散流量到後方。
該服務原本是部署到 m5.4xl (16 vCPU) 的機器上，根據需求調整到 m5.12xl (48 vCPU) 的機器人，本來預計整體的效能能夠如線性般的三倍成長，結果整體表現非常的糟。
從效能來看，整體 throughput 平均只有提升 25%，此外更糟糕的是整個 latency 卻提升了將近 50%
提升機器等級提供更多 CPU 結果 latency 大幅度增長，這個結果實在是非常奇怪，所以團隊馬上開始研究來探索到底發生什麼事情。
首先，由於所有的流量都是透過 load-balancer，所以本來也預期這個問題應該是所有節點都有的，結果又發生更神秘的狀況，只有大概 12% 的節點是如預期般成長，剩下 88% 的節點幾乎都有這種效能下降的情況。
團隊的第一步驟就是透過火焰圖來比較看不同表現結果的節點會有什麼差異，接者又從 JVM 出發去看看從 JVM 是否有什麼直得注意的現象。
團隊從 app, JVM 到 OS 層級都嘗試找尋問題，但是還沒有辦法得到一個非常篤定且合理的答案，這時候開始懷疑可能是更底層的問題造成的，因此這時候決定使用 PerfSpect 此工具來觀察不同節點的現象。
該工具列出兩個節點運行上有一個顯著的數值差異，CPI (Cycles Per Instruction) 有將近三倍的差異，此外也觀察到節點上 L1 Cache 關於 MACHINE_CLEARS 的執行次數也有四倍差異。
仔細研究後觀察到這些參數會跟一個名為 "false sharing" 的狀況所導致的，而 false sharing 的意思是當有兩個 Core 嘗試從一個相同的 L1 cahce line(類似 memory page) 上讀取一個不相干的變數時造成的效能減損。
每個 Core 基本上都有屬於自己的 private cache，兩個 core 所屬的 cache 是來自於相同的 memory page，這個限制使得各自 cache 必須要維持一致，也就是這個維持一致的要求導致了問題發生。
舉例來說當 Thread A 嘗試寫入一個 Red 變數到 cache line 中，這時候系統會將 Thread A 底下的 cache 標示為 "moodified"，同時將 Thread B 底下的 cache 標示為 "invalidated".
接者當 Thread B 嘗試讀取一個名為 blue 的變數，理想狀況來說，兩個 thread 用到的變數不同，所以其實 Thread B 直接讀取自己的 cache 結果論來說是沒有問題，但是因為共享 memory page 的原因，所以系統這時候會強迫同步彼此的 cache 得資料讓 Thread B 上的 cache 先更新接者才讀取。 就是這個舉動操作使得整個效能大幅度下降。
團隊接者使用 Intel vTune 的工具來進行更底層的分析來觀察這類型的 false sharing 問題到底發生到哪，最後得出一個結論
Cache line 的大小是 64 bytes，然而使用的 pointer 是 8 bytes，所以有 8/64(12.5%) 的機會是正常使用，而有 56/64(87%) 的機會會產生 false sharing 的情形，此外這個數字也跟前述的節點分佈比例也幾乎一樣。
文章內有針對這個 vTune 的工具以及分析有更清楚的介紹，後半部分還有另外一個 true sharing 的問題，同時文章內也都有介紹這兩個問題的解法以及最後修改後的效能增長。
有興趣的可以閱讀全文
Medium
Seeing through hardware counters: a journey to threefold performance increase
By Vadim Filanovsky and Harshad Sane
標題: 「Syzygy-Ai 新創公司的技術發展之路」
類別: Usecase
連結: https://betterprogramming.pub/architecture-of-modern-startup-abaec235c2eb
本篇文章是由 Syzygy-Ai 的 CTO 分享的一篇技術文，探討該公司的技術架構是如何發展與演變的。
對於一個新創公司來說，當釐清公司的產品面貌後，接下來就是要選擇合適的技術架構，如何選擇技術架構不單是一個技術層面的問題，也是一個哲學問題。
隨者科技的發展，愈來愈多的程式語言，框架與相關函式庫被創造，這些工具可以讓開發者更加便利，但是這中間的學習曲線也是一個不能忽視的問題。
對於新創公司來說，選擇一個工具就要去思考該工具是不是初期使用？會不會太大材小用？這工具從團隊的角度來看，容易找到熟悉的開發者？還是學習曲線不高容易上手？
除了開發之外，考慮到測試，維運等各類用途，每個工具的選擇就是個艱難的決定。
從維運角度來看，最明顯也最常見的問題就是 kubernetes 萬用論，不論應用程式性質與用途，一切都上 kubernetes，很多時候可能一台 VM + Docker-compose 就可以搞定初期流量的架構，結果上了 kubernetes 發現有更多的眉眉角角需要人花時間去學習，反而使得有限的開發人力變得沒有辦法就新創的角度去挑戰市場。
除了基本的工具選擇外，團隊的開發流程也有很多東西直得探討，譬如 git 的管理方式，是要使用 PR-Based 的方式還是要使用 Trunk-Based？ 甚至不同的 git/github/gitlab flow 都有各自適合的場景。
作者從最初期不到 12 名工程師的團隊下出發，去探討要包含 前後端 + 手機端 的開發部署流程下是怎麼選擇工具，接者導入 docker-compose 協助 mobile 開發人員能夠更順利地進行開發測試並且將這些前置作業也整合到自動化測試中，逐漸完善整個流程。
隨者團隊擴張與架構發展，AWS 上的設定增多且繁瑣，愈來愈多 ”沒人知道這個設定是什麼時候為了什麼目的由誰設定的“ 設定出現，因此團隊就開始探索 IaC 的可能性，是否可以經由 IaC 補足當前這塊的不足
接下來就是因應各種需求而開始接觸各種新工具
1. Secret 的管理
2. Kuberentes
3. Helm Charts
4. Observability
5. Multi Cloud (Azure/GCP)
6. Staging/Production
本篇文章內文算長，但是滿寫實的描述從一個什麼都沒有的新創到有相對穩定產品過程中間的技術變化，這中間完全體現了沒有一個技術可以用一輩子，不同的環境下都有各自適合的工具，適時的淘汰與切換並不是什麼不好的事情。
此外這個內容也滿呼應這段時間一些團隊的心得，許多員工一加入就要大刀闊斧，什麼都想要用最新最潮的架構，一下 K8s，一下 Service Mesh，一下 eBPF，看不喜歡的東西就大喊我要 Rust 重寫，殊不知沒有辦法提出一個合理且現實的規劃，譬如導入工具解決什麼問題，會要花多少人日時間，帶來成效是什麼，畢竟商場上最重要的不是“滿足你個人的架構癖好”而是公司有辦法穩定營運發展與活下去。
類別: Usecase
連結: https://betterprogramming.pub/architecture-of-modern-startup-abaec235c2eb
本篇文章是由 Syzygy-Ai 的 CTO 分享的一篇技術文，探討該公司的技術架構是如何發展與演變的。
對於一個新創公司來說，當釐清公司的產品面貌後，接下來就是要選擇合適的技術架構，如何選擇技術架構不單是一個技術層面的問題，也是一個哲學問題。
隨者科技的發展，愈來愈多的程式語言，框架與相關函式庫被創造，這些工具可以讓開發者更加便利，但是這中間的學習曲線也是一個不能忽視的問題。
對於新創公司來說，選擇一個工具就要去思考該工具是不是初期使用？會不會太大材小用？這工具從團隊的角度來看，容易找到熟悉的開發者？還是學習曲線不高容易上手？
除了開發之外，考慮到測試，維運等各類用途，每個工具的選擇就是個艱難的決定。
從維運角度來看，最明顯也最常見的問題就是 kubernetes 萬用論，不論應用程式性質與用途，一切都上 kubernetes，很多時候可能一台 VM + Docker-compose 就可以搞定初期流量的架構，結果上了 kubernetes 發現有更多的眉眉角角需要人花時間去學習，反而使得有限的開發人力變得沒有辦法就新創的角度去挑戰市場。
除了基本的工具選擇外，團隊的開發流程也有很多東西直得探討，譬如 git 的管理方式，是要使用 PR-Based 的方式還是要使用 Trunk-Based？ 甚至不同的 git/github/gitlab flow 都有各自適合的場景。
作者從最初期不到 12 名工程師的團隊下出發，去探討要包含 前後端 + 手機端 的開發部署流程下是怎麼選擇工具，接者導入 docker-compose 協助 mobile 開發人員能夠更順利地進行開發測試並且將這些前置作業也整合到自動化測試中，逐漸完善整個流程。
隨者團隊擴張與架構發展，AWS 上的設定增多且繁瑣，愈來愈多 ”沒人知道這個設定是什麼時候為了什麼目的由誰設定的“ 設定出現，因此團隊就開始探索 IaC 的可能性，是否可以經由 IaC 補足當前這塊的不足
接下來就是因應各種需求而開始接觸各種新工具
1. Secret 的管理
2. Kuberentes
3. Helm Charts
4. Observability
5. Multi Cloud (Azure/GCP)
6. Staging/Production
本篇文章內文算長，但是滿寫實的描述從一個什麼都沒有的新創到有相對穩定產品過程中間的技術變化，這中間完全體現了沒有一個技術可以用一輩子，不同的環境下都有各自適合的工具，適時的淘汰與切換並不是什麼不好的事情。
此外這個內容也滿呼應這段時間一些團隊的心得，許多員工一加入就要大刀闊斧，什麼都想要用最新最潮的架構，一下 K8s，一下 Service Mesh，一下 eBPF，看不喜歡的東西就大喊我要 Rust 重寫，殊不知沒有辦法提出一個合理且現實的規劃，譬如導入工具解決什麼問題，會要花多少人日時間，帶來成效是什麼，畢竟商場上最重要的不是“滿足你個人的架構癖好”而是公司有辦法穩定營運發展與活下去。
Medium
The Architecture of a Modern Startup
Hype wave, pragmatic evidence vs the need to move fast
標題: 「Helm 小技巧，如何參考 values 檔案中的其他變數」
類別: Tools
連結: https://medium.com/itnext/reference-other-values-in-helm-chart-values-file-19d44d9276c7
常玩 Kubernetes 的玩家鐵定對 Helm 這個套件管理並不陌生，透過 template + value 的方式讓使用者可以根據不同環境客製化不同的參數。
現實中有時候會遇到一種情況， value file 裡面有些欄位彼此其實有依賴性，譬如
host: xxxxx
APIv1: xxxxxx/v1
APIv2: xxxxxx/v2
直接寫的情況使用上完全沒問題，只是當未來要 host 的資料的時候就需要一次修改所有欄位，因此很多人會就嘗試是否可以透過
host: xxxxx
APIv1: {{ .values.host }}/v1
APIv2: {{ .values.host }}/v2
上述這種方式來參考其他檔案內的變數，然而 helm 的運作邏輯是不會針對 value 的檔案去執行 template 相關的渲染。
本篇文章就針對這個問題探討如何使用 helm 內建的 tpl 函式來處理，同時也介紹潛在的問題以及最後的解法
類別: Tools
連結: https://medium.com/itnext/reference-other-values-in-helm-chart-values-file-19d44d9276c7
常玩 Kubernetes 的玩家鐵定對 Helm 這個套件管理並不陌生，透過 template + value 的方式讓使用者可以根據不同環境客製化不同的參數。
現實中有時候會遇到一種情況， value file 裡面有些欄位彼此其實有依賴性，譬如
host: xxxxx
APIv1: xxxxxx/v1
APIv2: xxxxxx/v2
直接寫的情況使用上完全沒問題，只是當未來要 host 的資料的時候就需要一次修改所有欄位，因此很多人會就嘗試是否可以透過
host: xxxxx
APIv1: {{ .values.host }}/v1
APIv2: {{ .values.host }}/v2
上述這種方式來參考其他檔案內的變數，然而 helm 的運作邏輯是不會針對 value 的檔案去執行 template 相關的渲染。
本篇文章就針對這個問題探討如何使用 helm 內建的 tpl 函式來處理，同時也介紹潛在的問題以及最後的解法
Medium
Reference Other Values in Helm Chart Values File
Templating variables in Helm’s values.yaml
標題: 「網路技術文，探討 Kubenet, Azure CNI 與 Azure CNI(Overlay) 的差異」
類別: Networking
連結: https://medium.com/@inder-devops/aks-networking-deep-dive-kubenet-vs-azure-cni-vs-azure-cni-overlay-a51709171ce9
作為一個 AKS (Azure Kubernetes Service) 的使用者，創建時可能都會觀察到有所謂的 network model 可以選擇，而這個 network model 實際上就是對應到 Kubernetes CNI 的範疇，預設情況下是採用 kubenet 這套解決方案來處理 CNI 的需求。
本篇文章首先先以簡單的概念描述 Azure 的網路概念，與多數的 Cloud Provider 一樣，基本上都會有所謂的 VPC + Subnet 的概念，同時因應 (Kubernetes Service) 都可能配置的 NodePool 來探討一下這些 IP 的基本關係。
接者從 Kubernetes 出發，探討所謂的 PodCIDR, ServiceCIDR 這些實際上跟 Kubernetes 有直接相關的 IP 分配與使用
有了上述的基本概念後再來看接下來的 Kubenet/Azure CNI 的比較才會有更深的體悟實際上的差異是什麼
以下簡單記錄一下每個 CNI 的特性
Kubenet
1 Nodes 會從 Azure virtual network subnet 獲取 IP
2 Pod 會獲得一個全新的虛擬網段，該網段由 kubenet 維護
3 Pod 如果要對外存取服務，需要透過 SNAT 來進行轉換，且轉換後的 source IP都是 Node IP
Azure CNI
1 Node 會從 Azure virtual network subnet 獲取 IP
2 Pod 與 Node 一樣，會從一樣的 Azure virtual network subnet 獲取 IP
1 為了實作此功能，每個節點除了主要 IP 外，還會掛載更多網卡來處理 Node 上 Pod 的IP與相關存取
3 Cluster 上 Pod 的數量規模會取決於當前 Azure virtual network subnet 分配的網段大小，太小則沒有辦法分配適當的 IP 給 Pod
Azure CNI Overlay
1 運作模式類似於 Kubenet， Pod 都會用新創的虛擬 IP
2 效能相對於 Kubenet 更好
從功能面來看 Azure CNI 與 AWS CNI 類似，都是以 VPC 的角度打出一個大一統的網路平面來給所有的 k8s node, k8s pod 去使用，好處就是 IP 攤平的情況下減少溝通成本同時也能夠透過既有的 network firewall 等進行處理與觀察，但是壞處就是 IP 分配數量直接影響 Pod 的數量，這變成架構設計時就要先想好到底要如何分配
詳細比較圖文可參考內文
類別: Networking
連結: https://medium.com/@inder-devops/aks-networking-deep-dive-kubenet-vs-azure-cni-vs-azure-cni-overlay-a51709171ce9
作為一個 AKS (Azure Kubernetes Service) 的使用者，創建時可能都會觀察到有所謂的 network model 可以選擇，而這個 network model 實際上就是對應到 Kubernetes CNI 的範疇，預設情況下是採用 kubenet 這套解決方案來處理 CNI 的需求。
本篇文章首先先以簡單的概念描述 Azure 的網路概念，與多數的 Cloud Provider 一樣，基本上都會有所謂的 VPC + Subnet 的概念，同時因應 (Kubernetes Service) 都可能配置的 NodePool 來探討一下這些 IP 的基本關係。
接者從 Kubernetes 出發，探討所謂的 PodCIDR, ServiceCIDR 這些實際上跟 Kubernetes 有直接相關的 IP 分配與使用
有了上述的基本概念後再來看接下來的 Kubenet/Azure CNI 的比較才會有更深的體悟實際上的差異是什麼
以下簡單記錄一下每個 CNI 的特性
Kubenet
1 Nodes 會從 Azure virtual network subnet 獲取 IP
2 Pod 會獲得一個全新的虛擬網段，該網段由 kubenet 維護
3 Pod 如果要對外存取服務，需要透過 SNAT 來進行轉換，且轉換後的 source IP都是 Node IP
Azure CNI
1 Node 會從 Azure virtual network subnet 獲取 IP
2 Pod 與 Node 一樣，會從一樣的 Azure virtual network subnet 獲取 IP
1 為了實作此功能，每個節點除了主要 IP 外，還會掛載更多網卡來處理 Node 上 Pod 的IP與相關存取
3 Cluster 上 Pod 的數量規模會取決於當前 Azure virtual network subnet 分配的網段大小，太小則沒有辦法分配適當的 IP 給 Pod
Azure CNI Overlay
1 運作模式類似於 Kubenet， Pod 都會用新創的虛擬 IP
2 效能相對於 Kubenet 更好
從功能面來看 Azure CNI 與 AWS CNI 類似，都是以 VPC 的角度打出一個大一統的網路平面來給所有的 k8s node, k8s pod 去使用，好處就是 IP 攤平的情況下減少溝通成本同時也能夠透過既有的 network firewall 等進行處理與觀察，但是壞處就是 IP 分配數量直接影響 Pod 的數量，這變成架構設計時就要先想好到底要如何分配
詳細比較圖文可參考內文
Medium
AKS Networking Deep Dive: Kubenet vs Azure-CNI vs Azure-CNI (overlay)
Kubernetes networking enables you to configure communication within our k8s network. When deploying a AKS cluster, there are three…
標題: 「CNCF 2022 專案回顧」
類別: Networking
連結: https://medium.com/dev-genius/cncf-2022-graduated-projects-year-end-review-part-one-95d27c77983c
2022 依然是 Cloud Native 生態系蓬勃發展的一年，以 CNCF 所託管的 157 個專案中，就有超過來自 189 個國家共 178,000 的貢獻者。
同時，直到 2023 年底，CNCF 中共有 20 個畢業專案，畢業的意思就是該專案已經足夠穩定，有來自不同地方的貢獻者共同維護該專案生態系同時該專案也被證明能夠於正式部署環境使用的。
作者特別整理這些畢業的專案，本篇文章只是上篇，因此只有收錄十個畢業專案
對於使用者來說，選擇畢業專案除了技術上的考量，有時候也是一個政治上的考量，基於 CNCF 的畢業標準作為背書來表示為什麼要使用此專案相對於其他的專案會更有說服力，畢竟使用開源專案除了功能面之外，生態系的活躍也是後續維護與找尋臭蟲的一個重要關鍵點。
目前畢業的 20 個專案分別有
1 ArgoCD
2 Containerd
3 CoreDNS
4 Envoy
5 etcd
6 fluentd
7 flux
8 Harbor
9 Helm
10 Jaeger
11 Kubernetes
12 Linked
13 Open Policy Agent
14 Prometheus
15 Rook
16 Spiffe
17 Spire
18 TUF
19 TiKV
20 Vitess
因此本篇專案就是針對前 10 個進行簡單介紹，從分類來說大抵上可以看成
GitOps -> Argo/Flux
Observability -> Fluentd, Jaeger
Container Related -> Containerd, Harbor
Networking -> Envoy, CoreDNS
DB -> etcd
K8s Application Management -> Helm
類別: Networking
連結: https://medium.com/dev-genius/cncf-2022-graduated-projects-year-end-review-part-one-95d27c77983c
2022 依然是 Cloud Native 生態系蓬勃發展的一年，以 CNCF 所託管的 157 個專案中，就有超過來自 189 個國家共 178,000 的貢獻者。
同時，直到 2023 年底，CNCF 中共有 20 個畢業專案，畢業的意思就是該專案已經足夠穩定，有來自不同地方的貢獻者共同維護該專案生態系同時該專案也被證明能夠於正式部署環境使用的。
作者特別整理這些畢業的專案，本篇文章只是上篇，因此只有收錄十個畢業專案
對於使用者來說，選擇畢業專案除了技術上的考量，有時候也是一個政治上的考量，基於 CNCF 的畢業標準作為背書來表示為什麼要使用此專案相對於其他的專案會更有說服力，畢竟使用開源專案除了功能面之外，生態系的活躍也是後續維護與找尋臭蟲的一個重要關鍵點。
目前畢業的 20 個專案分別有
1 ArgoCD
2 Containerd
3 CoreDNS
4 Envoy
5 etcd
6 fluentd
7 flux
8 Harbor
9 Helm
10 Jaeger
11 Kubernetes
12 Linked
13 Open Policy Agent
14 Prometheus
15 Rook
16 Spiffe
17 Spire
18 TUF
19 TiKV
20 Vitess
因此本篇專案就是針對前 10 個進行簡單介紹，從分類來說大抵上可以看成
GitOps -> Argo/Flux
Observability -> Fluentd, Jaeger
Container Related -> Containerd, Harbor
Networking -> Envoy, CoreDNS
DB -> etcd
K8s Application Management -> Helm
Medium
CNCF 2022 Graduated Projects Year-End Review, Part One
CNCF 2022 graduated project updates
標題: 「ssh-tunnel 詳細教學」
類別: tools
連結: https://iximiuz.com/en/posts/ssh-tunnels/
ssh 對許多人來說並不陌生，但是對於一些稍微繁雜的環境很多時候就會使用 ssh tunnel 來進行一些反向代理或是不同的處理，複雜的可能還會搭配 .ssh/config 來簡化多節點的跳躍與存取。
此外也有部分人會使用如 sshuttle 之類的工具來簡化操作讓一切更為簡單
而本篇文章則是專注於 ssh tunnel 的介紹，其介紹非常詳細，從指令的用法到圖解整個運作與流程都包含，對於 ssh tunnel 不熟或是想要複習的讀者非常推薦閱讀這一篇文章，能夠幫助你重新理解 ssh tunnel 的流程與用法
類別: tools
連結: https://iximiuz.com/en/posts/ssh-tunnels/
ssh 對許多人來說並不陌生，但是對於一些稍微繁雜的環境很多時候就會使用 ssh tunnel 來進行一些反向代理或是不同的處理，複雜的可能還會搭配 .ssh/config 來簡化多節點的跳躍與存取。
此外也有部分人會使用如 sshuttle 之類的工具來簡化操作讓一切更為簡單
而本篇文章則是專注於 ssh tunnel 的介紹，其介紹非常詳細，從指令的用法到圖解整個運作與流程都包含，對於 ssh tunnel 不熟或是想要複習的讀者非常推薦閱讀這一篇文章，能夠幫助你重新理解 ssh tunnel 的流程與用法
iximiuz Labs
A Practical Guide to SSH Tunnels: Local and Remote Port Forwarding | iximiuz Labs
SSH port forwarding explained in a clean and visual way. How to use local and remote port forwarding. What sshd settings may need to be adjusted. How to memorize the right flags.
標題: 「ssh-jump 教學」
類別: tools
連結: https://www.tecmint.com/access-linux-server-using-a-jump-host
上週分享了關於 ssh tunnel 的用法，而本篇文章介紹的則是另外一個常用功能, SSH Jump Server。
基於安全與其他考量，很多時候目標伺服器本身都沒有辦法直接存取，都會透過 bastion host/jump server 的概念來保護，因此如何快速的存取後端被保護的 server 則是一個需求。
從概念上來看非常簡單，就是先從使用者的電腦存取到 jump server 接者再從 jump server 存取到後端的伺服器。而 SSH 的指令中可以透過 -J 的方式來描述要如何存取 jump server。
當基本 ssh 沒問題的時後，可能就會開始考慮 SCP 與 SSH Tunnel 等相關用法該怎麼整合到 Jump Server 中，為了避免整個指令愈來愈龐大與難以管理，這時候都會推薦透過 ssh config 的方式來設定每個 host 存取的方式
文章中有介紹如何透過 ssh config 來描述 jump server 的用法，可以針對不同的機器採用不同的 username/key 等方式分別認證
類別: tools
連結: https://www.tecmint.com/access-linux-server-using-a-jump-host
上週分享了關於 ssh tunnel 的用法，而本篇文章介紹的則是另外一個常用功能, SSH Jump Server。
基於安全與其他考量，很多時候目標伺服器本身都沒有辦法直接存取，都會透過 bastion host/jump server 的概念來保護，因此如何快速的存取後端被保護的 server 則是一個需求。
從概念上來看非常簡單，就是先從使用者的電腦存取到 jump server 接者再從 jump server 存取到後端的伺服器。而 SSH 的指令中可以透過 -J 的方式來描述要如何存取 jump server。
當基本 ssh 沒問題的時後，可能就會開始考慮 SCP 與 SSH Tunnel 等相關用法該怎麼整合到 Jump Server 中，為了避免整個指令愈來愈龐大與難以管理，這時候都會推薦透過 ssh config 的方式來設定每個 host 存取的方式
文章中有介紹如何透過 ssh config 來描述 jump server 的用法，可以針對不同的機器採用不同的 username/key 等方式分別認證
How to Access a Remote Server Using a SSH Jump Host
How to Set Up an SSH Jump Server in Linux
A jump host is an intermediary host or an SSH gateway to a remote network, through which a connection can be made to another host in a dissimilar security zone.
標題: 「Chick-fil-A Edge 端 Kubernetes 多年經驗回顧」
類別: usecase
連結: https://medium.com/chick-fil-atech/enterprise-restaurant-compute-f5e2fd63d20f
Chick-flt-A 於 2018 年的時候的有發表過一篇如何於分店都透過少量機器搭建一台地端的 Kubernetes 叢集來提供服務，而這些概念也實實在在地跑了四年，
整個專案名稱為 Restaurant Edge Compute platform，其目的是希望為每一個餐廳打造一個穩健的平台讓 DevOps 團隊能夠順利的去管理與部署各種應用程式來幫助餐廳的營運，從供應鏈，餐廳管理到面對客服的服務
打造平台前首先必定要執行的就是審視當前的工具，團隊發現大部分的工具都是跟 Cloud 息息相關，反而有資源考量的 Edge 端沒有太多的關注點，此外有些商業工具不是沒有辦法大規模部署(上千k8s叢集)不然就是對方的授權模式與公司需求不和，因此最後的決定就是由 Chick-flit-A 自己動手來管理與維護這些 k8s 叢集。
#硬體
最初的設計是使用 Intel NUCs 作為餐廳內的小型伺服器，以三台 NUCs 為基準搭建一個 k8s 叢集來提供基本的 HA 概念，而這個設計直到現在依然繼續採用
#OS
最初的設計是透過 Ubuntu 作為基底 OS 並且搭配一些 script 來處理自動化的部分，此外希望可以達到一個隨插即用的等級，也就是 Intel NUCs 送到餐廳後就可以無腦開機自動設定完畢，不希望餐廳內還有任何手動設定的步驟。
#Kuberentes
一切的設計與操作都希望跟者業界標準去執行，因此團隊選擇了由 Rancher 所開發與維護的 K3s 作為 Kubernetes 版本，同時因為需求是地端而非雲端上面的各種整合功能，k3s 的設計恰恰的符合需求，因此團隊目前沒有任何計畫去改用其他的 k8s 版本
文章後面還有介紹很多如 GitOps/RollOut/API...等各種議題的反思與學習
類別: usecase
連結: https://medium.com/chick-fil-atech/enterprise-restaurant-compute-f5e2fd63d20f
Chick-flt-A 於 2018 年的時候的有發表過一篇如何於分店都透過少量機器搭建一台地端的 Kubernetes 叢集來提供服務，而這些概念也實實在在地跑了四年，
整個專案名稱為 Restaurant Edge Compute platform，其目的是希望為每一個餐廳打造一個穩健的平台讓 DevOps 團隊能夠順利的去管理與部署各種應用程式來幫助餐廳的營運，從供應鏈，餐廳管理到面對客服的服務
打造平台前首先必定要執行的就是審視當前的工具，團隊發現大部分的工具都是跟 Cloud 息息相關，反而有資源考量的 Edge 端沒有太多的關注點，此外有些商業工具不是沒有辦法大規模部署(上千k8s叢集)不然就是對方的授權模式與公司需求不和，因此最後的決定就是由 Chick-flit-A 自己動手來管理與維護這些 k8s 叢集。
#硬體
最初的設計是使用 Intel NUCs 作為餐廳內的小型伺服器，以三台 NUCs 為基準搭建一個 k8s 叢集來提供基本的 HA 概念，而這個設計直到現在依然繼續採用
#OS
最初的設計是透過 Ubuntu 作為基底 OS 並且搭配一些 script 來處理自動化的部分，此外希望可以達到一個隨插即用的等級，也就是 Intel NUCs 送到餐廳後就可以無腦開機自動設定完畢，不希望餐廳內還有任何手動設定的步驟。
#Kuberentes
一切的設計與操作都希望跟者業界標準去執行，因此團隊選擇了由 Rancher 所開發與維護的 K3s 作為 Kubernetes 版本，同時因為需求是地端而非雲端上面的各種整合功能，k3s 的設計恰恰的符合需求，因此團隊目前沒有任何計畫去改用其他的 k8s 版本
文章後面還有介紹很多如 GitOps/RollOut/API...等各種議題的反思與學習
Medium
Enterprise Restaurant Compute
by the CFA Enterprise Restaurant Compute Team
標題: 「手把手教你系統設計」
類別: others
連結: https://www.hiredintech.com/system-design
今天介紹的這個網站是一個非常適合練習與學習系統設計的網站，該網站探討了系統設計於實務上的範疇，搭配些許影片進行一系列的介紹，此外除了基本的系統設計外，也探討了 Scalability 這個非常重要的概念，特別是若要設計一個有此特性的系統時有哪些點需要考慮
最後以搭建一個簡易版本的 Twitter 為範例開始逐步探討，包含
1 釐清問題與需求
2 High-Level 設計
3 Low-Level 的潛在問題
4 其他如 DB, Traffic 等延伸議題
對於想要練習系統設計相關題目的人非常值得花點時間跑完該網站
類別: others
連結: https://www.hiredintech.com/system-design
今天介紹的這個網站是一個非常適合練習與學習系統設計的網站，該網站探討了系統設計於實務上的範疇，搭配些許影片進行一系列的介紹，此外除了基本的系統設計外，也探討了 Scalability 這個非常重要的概念，特別是若要設計一個有此特性的系統時有哪些點需要考慮
最後以搭建一個簡易版本的 Twitter 為範例開始逐步探討，包含
1 釐清問題與需求
2 High-Level 設計
3 Low-Level 的潛在問題
4 其他如 DB, Traffic 等延伸議題
對於想要練習系統設計相關題目的人非常值得花點時間跑完該網站
Goldydocs
System Design
A Docsy example site
標題: 「Podman v4.4.0 將逐漸拋棄CNI作為其底層網路架構」
類別: tools
連結: https://github.com/containers/podman/releases/tag/v4.4.0
Podman 本週正式釋出其 v4.4.0 版本，其 release note 裡面有一個改動非常有趣
「CNI is being deprecated from Podman and support will be dropped at a future date. Netavark is now advised and is the default network backend for Podman.」
簡單來說，過去 Podman 使用的是 CNI 的架構來為其 container 提供網路功能，而從這個版本開始就正式標示為 deprecated 的版本並且於未來的版本將不再繼續支援
由於 Podman 本身就是一個本地開發測試用的軟體，同時本身也沒有透過 CRI 介面去支援 Kubernetes，因此這個改動對於 Kubernetes 本身沒有任何影響，單純是 Podman 自己生態系的改動。
取而代之的則是由另外一個專門為了 Podman 生態而開發的底層網路架構, Netavark(https://github.com/containers/netavark)。
其官網敘述非常直白
「Netavark is a rust based network stack for containers. It is being designed to work with Podman but is also applicable for other OCI container management applications.」
基於 Rust 開發並且以 Podman 為主不過其他 OCI 相容的容器也可以使用。
至於為什麼 Podman 要切換過去，我認為主要有以下幾個原因
1 CNI 的發展目的更適合 Kubernetes 這種多節點的叢集架構，Podman 的目標則是單一節點上的容器管理系統
2 隨者使用者的使用環境愈來愈複雜，CNI 有時候很難輕易地達成環境架設，特別是想要讓容器運行到多層網路之中，譬如多網卡等情境，可以弄但是就麻煩
3 CNI 是純框架設計，功能全部仰賴各種 Plugin，如 Flannel,Calico,Cilium…etc，所以各種功能都還要仰賴第三方 Plugin 去實作，不然就需要自己完整實作一套 CNI Plugin
相對於 CNI 來說 Netavark 的特色有
1 不仰賴各種 Plugin，本身就將過往所有網路功能都直接實作掉，也意味者所有的網路功能都直接實作於 Netavark 中，沒有其他 Plugin 的需求
2 不同於 CNI 各種串接來串接去的 Plugin 方式， Netavark 單一工具的執行方式其實可以用更短的時間去設定完成整個容器網路，對於單一節點的應用上可以榨取更多時間
如果本身是一個 Podman 愛好者的話，可以花些時間去看一下 Netavark 以及其 DNS 夥伴 Aardvark 的相關文章以方便未來更加了解 Podman 的使用與除錯
類別: tools
連結: https://github.com/containers/podman/releases/tag/v4.4.0
Podman 本週正式釋出其 v4.4.0 版本，其 release note 裡面有一個改動非常有趣
「CNI is being deprecated from Podman and support will be dropped at a future date. Netavark is now advised and is the default network backend for Podman.」
簡單來說，過去 Podman 使用的是 CNI 的架構來為其 container 提供網路功能，而從這個版本開始就正式標示為 deprecated 的版本並且於未來的版本將不再繼續支援
由於 Podman 本身就是一個本地開發測試用的軟體，同時本身也沒有透過 CRI 介面去支援 Kubernetes，因此這個改動對於 Kubernetes 本身沒有任何影響，單純是 Podman 自己生態系的改動。
取而代之的則是由另外一個專門為了 Podman 生態而開發的底層網路架構, Netavark(https://github.com/containers/netavark)。
其官網敘述非常直白
「Netavark is a rust based network stack for containers. It is being designed to work with Podman but is also applicable for other OCI container management applications.」
基於 Rust 開發並且以 Podman 為主不過其他 OCI 相容的容器也可以使用。
至於為什麼 Podman 要切換過去，我認為主要有以下幾個原因
1 CNI 的發展目的更適合 Kubernetes 這種多節點的叢集架構，Podman 的目標則是單一節點上的容器管理系統
2 隨者使用者的使用環境愈來愈複雜，CNI 有時候很難輕易地達成環境架設，特別是想要讓容器運行到多層網路之中，譬如多網卡等情境，可以弄但是就麻煩
3 CNI 是純框架設計，功能全部仰賴各種 Plugin，如 Flannel,Calico,Cilium…etc，所以各種功能都還要仰賴第三方 Plugin 去實作，不然就需要自己完整實作一套 CNI Plugin
相對於 CNI 來說 Netavark 的特色有
1 不仰賴各種 Plugin，本身就將過往所有網路功能都直接實作掉，也意味者所有的網路功能都直接實作於 Netavark 中，沒有其他 Plugin 的需求
2 不同於 CNI 各種串接來串接去的 Plugin 方式， Netavark 單一工具的執行方式其實可以用更短的時間去設定完成整個容器網路，對於單一節點的應用上可以榨取更多時間
如果本身是一個 Podman 愛好者的話，可以花些時間去看一下 Netavark 以及其 DNS 夥伴 Aardvark 的相關文章以方便未來更加了解 Podman 的使用與除錯
GitHub
Release v4.4.0 · containers/podman
Features
Introduce Quadlet, a new systemd-generator that easily writes and maintains systemd services using Podman.
The podman kube play command now supports hostPID in the pod.spec (#17157).
The ...
Introduce Quadlet, a new systemd-generator that easily writes and maintains systemd services using Podman.
The podman kube play command now supports hostPID in the pod.spec (#17157).
The ...
標題: 「利用 ChatGPT 來提高團隊 Kubernetes 除錯效率」
類別: tools
連結: https://medium.com/dev-genius/k8s-chatgpt-bot-for-intelligent-troubleshooting-36e0a4a071c5
隨者 ChatGPT 最近的爆紅，愈來愈多行業與領域都嘗試透過 ChatGPT 來提升整體效率，雖然有使用過的人就知道很多時候 ChatGPT 沒有辦法就問題給予非常精準的答案甚至給予錯誤的答案，但是大部分時候都可以幫忙省去 Google 的時間
今天這篇文章作者想要分享一個透過 ChatGPT 來查詢 K8s issue 的小專案，該專案中 ChatGPT 會搭配 AlertManager 一同使用，將 Alertmanager 送來的錯誤訊息轉送到 ChatGPT 中讓其提供一些基本的概念以及除錯方式，最後將這個專案給整合到 Slack 中。
雖然該專案不一定可以輕易導入，但是可以看到愈來愈多人用不同的方式來使用 ChatGPT，花點時間玩看看這個工具，看看如何可以用其為自己的日常工作提供不同面向的變化吧
類別: tools
連結: https://medium.com/dev-genius/k8s-chatgpt-bot-for-intelligent-troubleshooting-36e0a4a071c5
隨者 ChatGPT 最近的爆紅，愈來愈多行業與領域都嘗試透過 ChatGPT 來提升整體效率，雖然有使用過的人就知道很多時候 ChatGPT 沒有辦法就問題給予非常精準的答案甚至給予錯誤的答案，但是大部分時候都可以幫忙省去 Google 的時間
今天這篇文章作者想要分享一個透過 ChatGPT 來查詢 K8s issue 的小專案，該專案中 ChatGPT 會搭配 AlertManager 一同使用，將 Alertmanager 送來的錯誤訊息轉送到 ChatGPT 中讓其提供一些基本的概念以及除錯方式，最後將這個專案給整合到 Slack 中。
雖然該專案不一定可以輕易導入，但是可以看到愈來愈多人用不同的方式來使用 ChatGPT，花點時間玩看看這個工具，看看如何可以用其為自己的日常工作提供不同面向的變化吧
Medium
K8s — ChatGPT Bot For Intelligent Troubleshooting
An interesting ChatGPT bot project for K8s
標題: 「讓 ChatGPT 考看看 AWS 證照?」
類別: others
連結: https://medium.com/@miguelsalva/chatgpt-goes-certified-aws-82747a2e4619
隨者 ChatGPT 的橫空出世，作者想要試試看這類型的服務是否有辦法通過各種 AWS 的相關證照，由於考試規則的限制與規範，並沒有辦法直接將 ChatGPT 套用到正式考試中，因此作者就透過 AWS 所公開的示範考試題目來逐一測試 ChatGPT
作者總共嘗試了 12 個不同的 AWS 證照，包含
1 CLF-C01: AWS Certified Cloud Practitioner
2 SAA-C03: AWS Certified Solutions Architect — Associate
3 DVA-C01: AWS Certified Developer — Associate
4 SOA-C02: AWS Certified SysOps Administrator — Associate
5 SAP-C02: AWS Certified Solutions Architect — Professional
6 DOP-001: AWS Certified DevOps Engineer — Professional
7 ANS-C01: AWS Certified Advanced Networking — Specialty
8 DAS-C01: AWS Certified Data Analytics — Specialty
9 DBS-C01: AWS Certified Database — Specialty
10 MLS-C01: AWS Certified Machine Learning — Specialty
11 SCS-C01: AWS Certified Security — Specialty
12 PAS-C01: AWS Certified: SAP on AWS — Specialty
每個證照都列出考試分數(滿分1000)以及通過的門檻分數。 最後 ChatGPT 順利的通過四個 Pass(No 1,3,4,11) ，其中有三個 Fail (2, 8, 12)的分數差一點就可以通過了。
根據證照的難易度來看的話， ChatGPT 通過了基礎等級的認證，兩張 Associate 的相關證照，一個 Specialty 等級的證照，而沒有通過半張 Professional 等級的證照
從這個角度來看，繼續追求證照作為條件的市場會不會受到影響?
類別: others
連結: https://medium.com/@miguelsalva/chatgpt-goes-certified-aws-82747a2e4619
隨者 ChatGPT 的橫空出世，作者想要試試看這類型的服務是否有辦法通過各種 AWS 的相關證照，由於考試規則的限制與規範，並沒有辦法直接將 ChatGPT 套用到正式考試中，因此作者就透過 AWS 所公開的示範考試題目來逐一測試 ChatGPT
作者總共嘗試了 12 個不同的 AWS 證照，包含
1 CLF-C01: AWS Certified Cloud Practitioner
2 SAA-C03: AWS Certified Solutions Architect — Associate
3 DVA-C01: AWS Certified Developer — Associate
4 SOA-C02: AWS Certified SysOps Administrator — Associate
5 SAP-C02: AWS Certified Solutions Architect — Professional
6 DOP-001: AWS Certified DevOps Engineer — Professional
7 ANS-C01: AWS Certified Advanced Networking — Specialty
8 DAS-C01: AWS Certified Data Analytics — Specialty
9 DBS-C01: AWS Certified Database — Specialty
10 MLS-C01: AWS Certified Machine Learning — Specialty
11 SCS-C01: AWS Certified Security — Specialty
12 PAS-C01: AWS Certified: SAP on AWS — Specialty
每個證照都列出考試分數(滿分1000)以及通過的門檻分數。 最後 ChatGPT 順利的通過四個 Pass(No 1,3,4,11) ，其中有三個 Fail (2, 8, 12)的分數差一點就可以通過了。
根據證照的難易度來看的話， ChatGPT 通過了基礎等級的認證，兩張 Associate 的相關證照，一個 Specialty 等級的證照，而沒有通過半張 Professional 等級的證照
從這個角度來看，繼續追求證照作為條件的市場會不會受到影響?
Medium
ChatGPT goes Certified: AWS
You have probably already read and heard many many things about ChatGPT, so I won’t bother repeating them here. In case you you’ve been…
標題: 「Tinder 為何以及如何打造屬於自己的 API GW」
類別: usecase
連結: https://medium.com/tinder/how-we-built-the-tinder-api-gateway-831c6ca5ceca
這篇Medium上的文章講述了Tinder是如何建立其API Gateway的，為了解決之前客戶端直接向Tinder的主應用伺服器發送請求的問題，Tinder創建了自己的API Gateway，API Gateway採用了微服務架構，這使得Tinder可以更輕鬆地管理其API Gateway，並支持更快的開發和部署。
Tinder的API Gateway是由Java撰寫，並使用Netflix的Zuul框架構建。Zuul是一個網關服務，允許開發人員建立反向代理和路由器，這些路由器可以將請求路由到網絡上的其他服務。Zuul還提供了一些內置的功能，如路由、過濾和反向代理，這些功能使Tinder可以更輕鬆地管理其API Gateway。
Tinder的API Gateway還具有一些特殊的功能，如基於用戶的路由、可靠的請求/回應記錄和指標追蹤等。基於用戶的路由允許Tinder根據用戶屬性（例如，使用語言、地理位置等）將請求路由到相應的伺服器。請求/回應記錄可以使開發人員更輕鬆地追蹤數據，並定位潛在的問題。指標追蹤允許Tinder監控API Gateway的性能和可用性。
總之，這篇文章介紹了Tinder是如何建立其API Gateway的過程和一些特殊功能，API Gateway的構建使Tinder可以更輕鬆地管理其API，實現更快、更安全和更有效的API管理和開發。閱讀這篇文章可以讓讀者對於如何構建API Gateway有更深入的了解，同時可以學習到一些關於微服務架構的知識。
類別: usecase
連結: https://medium.com/tinder/how-we-built-the-tinder-api-gateway-831c6ca5ceca
這篇Medium上的文章講述了Tinder是如何建立其API Gateway的，為了解決之前客戶端直接向Tinder的主應用伺服器發送請求的問題，Tinder創建了自己的API Gateway，API Gateway採用了微服務架構，這使得Tinder可以更輕鬆地管理其API Gateway，並支持更快的開發和部署。
Tinder的API Gateway是由Java撰寫，並使用Netflix的Zuul框架構建。Zuul是一個網關服務，允許開發人員建立反向代理和路由器，這些路由器可以將請求路由到網絡上的其他服務。Zuul還提供了一些內置的功能，如路由、過濾和反向代理，這些功能使Tinder可以更輕鬆地管理其API Gateway。
Tinder的API Gateway還具有一些特殊的功能，如基於用戶的路由、可靠的請求/回應記錄和指標追蹤等。基於用戶的路由允許Tinder根據用戶屬性（例如，使用語言、地理位置等）將請求路由到相應的伺服器。請求/回應記錄可以使開發人員更輕鬆地追蹤數據，並定位潛在的問題。指標追蹤允許Tinder監控API Gateway的性能和可用性。
總之，這篇文章介紹了Tinder是如何建立其API Gateway的過程和一些特殊功能，API Gateway的構建使Tinder可以更輕鬆地管理其API，實現更快、更安全和更有效的API管理和開發。閱讀這篇文章可以讓讀者對於如何構建API Gateway有更深入的了解，同時可以學習到一些關於微服務架構的知識。
Medium
How we built the Tinder API Gateway
Authored by: Vijayvangapandu Vijaya Vangapandu Distinguished Software Engineer