本文延續前篇效能校正的經驗談，上篇文章探討了關於Locality與中斷中可以最佳化的部分，。本篇文章將繼續剩下最佳化步驟的探討。


The Case of the Nosy Neighbor
從前述最後的火焰圖中，作者觀察到幾個跟網路有關的 kernel call，譬如 dev_queue_xmit_nit 以及 __netif_receive_skb_core 等有可能有成長的空間，於是輾轉前往這邊去研究。
作者觀察到 packet_rev 這個函式有不少的比例，而該函式的意思是有人嘗試透過使用 AF_PACKET 等方式開啟了 RAW socket 來處理封包。透過 ss 這個指令，作者觀察到系統中有其他的應用程式透過 AF_PACKET/SOCKET_RAW 也在處理封包，最後輾轉發現原來是系統上的 dhclient。

DHCP Client 必須要在系統有 IP 以前就有收送封包的能力，所以使用 AF_PACKET 也滿合理的。作者思考是否有辦法可以讓 DHCP Client 拿到 IP 之後就關閉 AF_PACKET，改使用純 UDP 的方式來進行後續的 DHCP Renewal 功能，可惜這個方向沒有辦法達成。

根據 AWS 的官方文件，當一個 IP 被分配到一個機器後，這個 IP 會跟該機器同生死，因此這種情況下 其實不需要透過 DHCP Renewal 來反覆取得 IP，只要取得一次 IP 即可。

作者變修改相關腳本，當 DHCP 取得 IP 後關閉 dhclient，此外還必須要記得去修改網卡層級關於該 IP 的記憶，預設期間是一小時，作者將其修改為永遠。

透過這樣簡單的設定，整體的效能又再度提升了 6%，從 1.06M req/s 提升到 1.12M req/s

The Battle Against the Spin Lock
作者陳述自己花了非常多時間與 Spin Lock(作者心魔的大白鯨) 奮戰，幾乎是茶不思飯不想的滿腦都在思考如何加速，然後再經歷過反反覆覆的失敗後，作者最後決定還是要寫出一些關於 Spin Lock 的嘗試與研究心得，算是一個很精彩的踩雷心得。

這部分的篇幅很長，而且內容也滿深的，最後的解決方式也只有提升 2%左右的效能，所以對這部分有興趣的讀者再自行閱讀囉

This Goes to Twelve
終於來到最後的最佳化步驟了，這個步驟中的範疇都只能勉強壓榨出些許的效能，包含了關閉 GRO, TCP壅塞控制以及靜態中斷處理。


(Generic Receive Offload)GRO 是一個網路相關的功能，目的是用來將 Kernel 層級的封包給聚合起來變成一個大封包，而 Kernel 收到這個封包後會把該大封包重新組合變成本來的小封包，對於使用者的應用程式來說不會有任何感覺，但是對於整體的封包傳輸來說能夠節省花費的並提升效能。大部分情況下這個功能都是開啟的，Amazon Linux 2 預設也是打開這個選項。
然而針對作者的測試情境，由於所有的封包基本上都是同一條連線且資料量也不大，因此 GRO 雖然可以帶來聚合的效果，但是也會拖延封包進入到 Linux Kernel Network Stack 的時間點，因此開啟 GRO 帶來的好處沒有很大。

TCP 壅塞控制有不同的演算法，Amazon Linux2 內建兩種演算法 Cubic 以及 Reno，除此這兩個之外常見的還有 Google 多年前貢獻的 BBR。根據作者測試，其實驗環境中有比較好效能的則是 Reno

註: 不同算法針對不同應用場景，所以要切換演算法前要先釐清自己的應用情境以及用哪種演算法比較合適。

全部零零總總的修改後提升了 4%，整體的效能服務來到了 1.2M reqs/s

這篇文章真的很長，有些最佳化的方式是針對該應用場景而特別去使用的，這也意味者並非所有的修正方式都可以套用到各位的應用程式。
本篇文章還是很值得一讀，整個分析的思路與想法都非常有趣，雖然不一定用得到但是也許未來有一天會有機會使用。


https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

本篇文章是個新手教學文(複習文)，主要探討 Kubernetes Resource 的使用，主要是 CPU 與 Memory 兩個資源的使用。
本篇文章中我覺得很值得大家再次注意的就是單位的使用，以 Memory 來說有非常多種的設定方式
1. 直些用數字表示，其單位為 Byte，譬如 1024 就是代表 1024 Byte
2. 可以使用指數表示，譬如 129e6，代表 129000000，也就是 129 MB左右
3. 使用固定的 Suffix，譬如 E,P,T,G,M,K。這個代表的是 10^N 次方，所以 1M 就是 10^6 Byte
4. 使用固定的 Suffix，譬如 Ei,Pi,Ti,Gi,Mi,Ki。這個代表的是 2^N 次方(每個級距都是2^10)，所以 1Mi 就是 2^20 次方 Byte，大概就是 1,048,576 Byte

所以 123Mi 接近 129M 也接近 129e6，而實際的數值則是 128974848 Byte 。

CPU 代表的則是 CPU 單位，對於 CloudProvider 來說，該單位則是所謂的 vCPU/Core，對於實體的 bare-metal 機器來說則是 1 hyperthread。
使用上除了直接表示多少單位的 CPU 外也可以使用 m (Milli) 的概念來描述 millicpu，也就是千分之一。
因此常常會看到 500m 的概念，其實就是 0.5 顆CPU,而 0.5 顆CPU則會因為底層不同可能代表 vCPU 或是 hyperthread。

https://medium.com/swlh/understanding-kubernetes-resource-cpu-and-memory-units-30284b3cc866

本篇文章是 Netflix 技術分享文(Netflix 真的滿多技術文章的)，本內容想要探討的是 Netflix 如何使用 eBPF 這個技術來洞察所有的網路流量與封包。

Netflix 開發了一個觀察網路流量封包的 sidecar 服務，稱為 Flow Exporter。這個服務使用 eBPF 來達到即時的 TCP 流量抓取，而產生額外的 CPU/Memory 都少於 1%，整體來說是非常好的表現。

挑戰
Netflix 目前使用 AWS 底層的網路元件來搭建其雲端網路基礎建設，包含了 AWS VPC, DirectConnect, VPC Peering, Transit Gateways, NAT Gatewats 以及 Netflix 自己的裝置與設備。
而 Netflix 的軟體基礎建設則是基於 AWS 搭建的一個大型的分散式環境，這些環境產生了下列挑戰
1. App Dependencies and Data Flow Mappings
隨者微服務架構的擴展，有愈來愈多的服務被部署，但是這些服務背後的彼此的依賴關係則是一個很難清楚描述的現象。開發與維運人員因為沒有辦法清楚的去定位這些資料，所以很多時候沒有很辦法很漂亮的去解決系統性的問題
2. Service Segamentation
因為雲端部署的簡單操作，導致整個環境內有愈來愈多的 AWS 帳號，愈來愈多不同的部署策略以及各種網路互相連接的需求。
3. Network Availability
隨者整個 Netflix 整個生態系的成長，如何瞭解當前網路效能的瓶頸以及可能潛在的問題是一個困難回答的問題。

為了解決上述的問題，Netflix 認為一個基於雲端網路流向的洞察工具必須要能夠針對維運與分析兩種情境去提供相關的資料，並且有辦法去找出當前的網路問題。
Netflix 目前會收集並分析不同來源的網路除錯資料，譬如
VPC Flow logs, ELB Access Logs 以及 eBPF flow logs 等，將其整理並分析後就可以傳給使用者或是內部不同的團隊來進行後續的除錯與處理。

Flow Exporter
本篇文章後半部分主要在介紹Flow Exporter 這個基於 eBPF 的 sidecare 是如何設計與運作的，其使用到了 Hive 以及 Druid 這兩種不同的 DB 來存放資料，對於這塊有興趣的可以再仔細閱讀全文。

https://netflixtechblog.com/how-netflix-uses-ebpf-flow-logs-at-scale-for-network-insight-e3ea997dca96?gi=d5fd990c9368

本篇是一個新手教學文，作者分享如何撰寫一個基於 Library 概念的 Helm Chart。

Helm Chart 的使用基本上不會太困難，透過 Helm Create 也可以很輕鬆地創造出一個範例 Helm Chart，針對該 Helm Chart 簡單修改也可以變成符合使用者需求的 Helm Chart。

作者工作中遇到一個要求，該要求要將一個 mono-repo 內的所有應用程式都變成 Helm Chart 的形式，該 repo 內大概有 10 個左右的應用程式，而這些應用程式部署所需要的資源都差不多，因此最簡單的方式就是創建十個幾乎完全一樣的 Helm Chart，透過 values.yaml 來客製化每個服務即可。

不過作者認為這種做法有點痛苦，要是未來需要針對這些k8s資源加上一些定義或是一些欄位，有可能就要 Copy&Paste 十次來處理所有的 Helm Chart。
為了解決這個問題作者就嘗試創建第一個 Helm Chart Library，只要到 Charts.yaml 裏面將 type 修改為 library 即可。(一般來說是 application)

作者特別提到，Helm 在處理部署的時候，只要檔案開頭為_，則該資源就不會被嘗試部署到 Kubernetes 內，這也是為什麼預設的 helper 會叫做 _helpers.tpl。

對於開發一個供其他 Helm Chart 使用的 Library Helm Chart 有興趣的可以參考這個文來看看一個簡單的範例

https://medium.com/nontechcompany/how-i-create-my-first-library-helm-chart-4f23caf5287d

本篇文章是一個深度介紹文，除了探討 K3S 與 K3D 的關係之外，還針對 K3D 的架構與使用方法很詳細的介紹一番，包含了
1. K3D v3 的特色與架構
2. 如何替換 K3D 裡面的 CNI
3. 如何替換 k3D 預設的 Ingress Controller
4. 使用 private registry 來處理

Kubernetes 的變化版本很多，除了 k3s 之外後來還有 k0s 的出現，每個版本都有自己想要解決的問題，而 k3s 則是一個非常輕量的 Kubernetes 版本，其特色有
1. 使用 Flannel 作為其預設 CNI，不講求太多複雜功能，單純用 VXLAN 打造一個 L2 的 overlay 網路
2. 使用 CoreDNS，與原生一樣
3. 使用 SQLite3 當作預設的 DB，而非 etcd3
4. 使用 Traefik 當作預設的 Ingress Controller，原生 K8s 則把這個主動權交給使用者
5. 使用 Containerd 當作預設的 Container Runtime

而 K3D 就是基於 K3S 的測試環境， K3S in Docker，跟 KIND 類似，只是運行的 Kubernetes 發行版本不同。

相較於 KIND 而已， K3D 的架構稍微複雜一點
1. 為了方便測試與存取，k3D 部署的時候也會部署一個 Nginx Server 來當作簡易的 Load-Balacner，讓 K3D 內的 Ingress 服務可以更簡易的被存取。使用者只需要存取該 Load-Balancer 即可，不需要去針對 Node(Docker) 的 IP 存取
2. 可以支援動態加入與刪除節點

本篇文章算是非常詳細的介紹各種參數用法，對於 K3D 這種測試環境有興趣的可以參考看看
https://yannalbou.medium.com/k3s-k3d-k8s-a-new-perfect-match-for-dev-and-test-e8b871aa6a42

Cloud Native 這個詞近年來非常熱門，CNCF 甚至也有針對這個詞給出了一個簡短的定義，然而對於每個使用者來說，要如何實踐這個定義則是百家爭鳴。我認為很認真地去探討到底什麼樣才算 Cloud Native 其實就跟很認真的探討什麼是 DevOps 一樣，就是一個沒有共識，沒有標準答案的問題。

本篇文章從 CNCF 的定義衍伸出 Cloud Native 帶來的優勢，並且針對這個領域介紹了十三種不同面向的科技樹，每個科技樹也都介紹了幾個常見的解決方案。

好處:
1. Speed
作者認為 Cloud Native 的應用程式要具有快速部署與快速開發的特性，擁有這些特性才有辦法更快地去根據市場需求而上線面對。眾多的雲端廠商都提供不同的解決方案讓部署應用程式愈來愈簡單，而 Cloud Native 相關的工具則是大量採用抽象化的方式去描述這類型的應用程式，讓需求可能更簡單與通用的部署到不同環境中。
2. Scalability and Availability
Cloud Native 的應用程式應該要可以無痛擴張來對面不論是面對一百個或是一百萬個客戶。底層所使用的資源應該都要根據當前的需求來動態配置，避免無謂的金錢成本浪費。此外自動化的 Failover 或是不同類型的部署策略(藍綠/金絲雀..等)也都可以整合到 Cloud native 的工具中。
3. Quality
Cloud Native 的應用程式建置時應該要保持不變性，這特性使得應用程式本身能夠提供良好的品質一致性。此外大部分的 Cloud Native 工具都是開放原始碼專案，這意味者使用時比較不會遇到 vendor lock-ins 的問題。

以下是作者列出來認為 Cloud Native 生態系中不可或缺的十三種面向，以及該面向中幾個知名專案。

相關領域
1. Microservices (Node.js/Kotlin,Golang)
2. CI/CD (Gitlab CICD/ Github Actions)
3. Container (Docker/Podmna/LXD)
4. Container Orchestration (Kubernetes/Google Cloud Run)
5. Infrasturcutre as Code (Terraform/Pulumi)
6. Secrets (Valut/Selaed Secrets)
7. Certificates (cert-manager/Google managerd certificates)
8. API Gateway (Ambassador/Kong)
9. Logging (EKF/Loki)
10. Monitoring (Prometheus/Grafana/Datadog)
11. Alerting (Prometheus Alertmanager/Grafana Alerts)
12. Tracing (Jaeger/Zipkin)
13. Service Mesh (Istio/Consul)

https://medium.com/quick-code/how-to-become-cloud-native-and-13-tools-to-get-you-there-861bcebb22bb

What Are Snowflake IDs?

Credit by: Wei-Yu Chen (感謝分享)

本文介紹了 Universal Unique Identifiers（UUIDs）的用途及其重要性，UUID 以固定且標準的方式為每個物件產生出獨立的 ID，且 產生出來的 ID 幾乎不可能會重複導致發生碰撞。

通常 UUID 由幾個部分組合而成，像是以時間、執行節點的 MAC address，或以 MD5 hash 來生成。UUID 以 128 bits 的數字組成，為了更方便識別及操作，通常都會以十六進制來表示，總長度為 36 個字（加上連字符號 -）。也因用來產生 UUID 的亂數種子包含了時間、節點資訊等參數，所以 UUID 也具有獨特性，在分散式系統執行也不容易發生碰撞。

而為了避免在你的 apps 裡實作 UUID 的產生機制，常見會使用兩種作法，分別是：Persistence Layer Generated ID 和 ID Servers。一種使用 Database 自動產生出來的序號來作為識別物件的 ID（如 MongoDB 的 ObjectID、MySQL 的 AUTO_INCREMENT ... 等），另一種是使用獨立的 ID server 來產生物件的 ID。

以 Database 來作為序號產生器會碰到一個問題，當你在每次建立新物件時，都會需要向資料庫讀取這個物件的「自動產生 ID」，假設應用程式的規模一大，效能勢必會大受影響。

而使用 ID server（也就是本文主要介紹的 Snowflake IDs）去產生 UUID 的話，就可利用架構於 app 以外的第三方序號產生器。以 Twitter 來說，平均每秒鐘有九千個推文，在高峰期間更甚至會出現一秒 143199 則推文的流量，他們所需要的 UUID 不僅要能夠支援龐大的架構，也需要在以非常快的速度產生出 ID，這也是 Snowflake 專案的由來。

因此，Twitter 以這幾個參數來組成 UUID：
- 保留不使用的位元，固定為 0 - 共 1 位
- Timestamp（以毫秒為單位） - 共 41 位
- 機器 ID - 共 10 位
- 序列號 - 從 0 ~ 4095 依序重複使用 - 共 12 位

雖然說以 ID servers 來產生 UUID 之後，效能還是會被這種架構拖累（必須在建立物件就去向 ID server 發送請求，並等待產生出來的 ID），但這種作法和資料庫系統相比起來已經讓效能降低的問題變得更輕微。

在本文當中介紹了三種常見的 ID 產生方式：在 local app 端產生 ID、在資料庫產生 ID、集中式的 ID server 產生 ID，這些策略的選擇也根據你的使用情境而定，畢竟沒有一種一套打天下的解決方案，在選擇時仍須衡量每個專案的需求。

https://betterprogramming.pub/uuid-generation-snowflake-identifiers-unique-2aed8b1771bc

ref: https://sysdig.com/blog/dockerfile-best-practices/
如果你常用到容器化、微服務架構，這些輕量化的架構當碰到問題時，背後的資安事件調查、報告、修復卻是影響甚鉅。然而，這些影響都可以透過「把安全意識擺在開發階段 (shifting left security)」來降低風險，而這篇文章就會講述 Dockerfile 的最佳實作手段有哪一些。
首先，我們會從幾個大面向來說明各種控制安全風險的細節，像是權限控管、降低攻擊層面、預防機敏資料洩漏，以及在發布 container image 時的注意事項。而你需要特別注意的是，其實 Dockerfile 也只是算是開發階段的一部份，所以這邊能提醒到的內容都屬於部署前（特別是開發階段）的準備。以下共提及 20 個你可以注意的重點，但因為篇幅較長，筆者將選出較重要的幾個來談談。
讓我們從「權限控管」說起：
Rootless container
根據報告結果顯示，有超過 58% 的 image 都是用 root 作為執行服務的使用者，所以在此也會建議透過 USER 參數來設定容器的預設使用者，同時，也可以利用執行環境/架構的設定來避免容器的預設使用者是 root。
Make executables owned by root and not writable
服務的 binary file 應該避免被任何人修改，容器的預設使用者只需要執行服務的權限，而不是擁有權。
至於「減少攻擊面」的部分：
Multistage builds小
在 image 的建立，可以透過 multistage build 來建立很多層 container，例如在第一層安裝編譯所需的套件，而第二層則只需安裝 runtime 所需的套件（如 openssl 等），再複製第一層所編譯出來的執行檔就可以了。其餘的因開發/編譯所安裝的套件皆不需要放在最後的 image，這樣同時也可以把 image 的大小縮小。
Distroless & Truested image
採用最小/最輕量化的 base image 來作為你打造 image 的基礎，同時使用可信任來源的 image，避免不小心在未知的情況引入好幾個潛在的安全威脅。（在原文中，sysdig 也使用了自身開發的工具來檢測 image 是否有安全問題，如果有需要也能參考看看）
而再來關於「機敏資訊」的部分：
Copy
當你在從你的開發環境複製檔案到 image 當中時，需要非常小心，因為你很可能一不小心就把你的密碼、開發環境的 token、API key 等資訊複製進去了。而且不要以為把 container 裡面的檔案刪掉就沒事了，別忘了 container image 是一層一層堆疊起來的，就算刪掉了，還是能在前面的 layer 裡面找到。
但如果還是有需要用到這些機敏資料，也可以考慮使用環境變數（docker run -e 引入），或是 Docker secret、Kubernetes secret 也能夠幫你引入這些參數。如果是設定檔的話，則可以用 mount 的方式來掛載到你的 container 裡面。
總而言之，你的 image 裡面不該有任何機敏資料、設定檔，開發服務時讓服務在 runtime 的時候可以接受來自環境變數的參數才是相對安全的。
其他的部分：
其實文章當中還有提到很多製作 image 的注意事項，像是在 deployment 階段，可能你部署的 latest 與實際的 latest 因時間差而不同。又或是在 image 裡面加上 health check，也才能做到狀況監測。
在容器化服務的時代，開發者不僅需要具備撰寫開發程式的能力，也要對於虛擬化環境有足夠的理解，否則，在對架構不熟的情況就將服務部署上去，或把 image 推送到公開的 registry，都可能造成重要的資料外洩與潛在的資安危機。

ref: https://medium.com/opentelemetry/opentelemetry-specification-v1-0-0-tracing-edition-72dd08936978

這篇文章主要是介紹 OpenTelemetry v1.0 版本的發展與演進

OpenTelemetry 專案希望能夠打造出一個符合 Cloud Native 開發與維運使用的系統框架，該框架席望能夠針對可觀性的三大指標進行一系列的整合與提供一個方便且一致的介面。三大指標分別是 Logging, Monitoring 以及 Tracing。

OpenTelemetry v1.0 主要的開發與修改都是針對 Tracing 這面向，其設計中認為 Tracing 的使用環節會包含三種不同角色，分別是應用程式開發者，應用程式部署維運者以及相關 Plugin 的開發者。

應用程式開發者使用 OpenTelemetry API 來控制應用程式 Tracing 相關的處理， v1.0 除了帶來功能的修改與開發外，對於整體的維護與支持也有相當的決心。當下次主要版本 v2.x 公開發佈後， v1.0 還可以繼續受到團隊至少三年的維護與支持，所以開發者三年內可以確保應用程式不會因為大大小小版本的修改而導致應用程式功能出問題。

而 OpenTelemertry SDK 則提供了供應用程式部署維運者與 Plugin 開發者要使用的框架與設定，這部分的維護時間則是有至少一年的時間(當 v2.0 出現時)。

包含了相關的 API 與 SDK 的使用。透過 OpenTelemetry API，開發者可以很輕易的去整合應用程式到 Tracing 的場景中。而當下次大版本 v2.0 出現

除了 Tracing 之外，目前 OpenTelemetry 團隊也持續的於 Monitoring 以及 Logging 兩方面來努力，從過去一年來看，整個專案的開源貢獻程度與速度都明顯比 2019 來得更為踴躍，也許這也代表愈來愈多團隊開始注重可觀測性的重要性，同時也有更多的開發者願意使用 OpenTelemery 作為使用工具。

ref: https://blog.devgenius.io/disaster-recovery-on-kubernetes-98c5c78382bb

作者認為即使那些知名的託管K8s服務(AKS/EKS/GKE)本身有提供各種機制來強化系統的存取性，但是作為一個正式生產環境的 Kubernetes 勢必還是要有一套災難復原的機制，因為有些災難並不是底層架構導致，有可能是人員的操作錯誤導致叢集內發生問題(譬如刪除整個 namespace).

隨者愈來愈多的團隊會將跨地區當作解決方案的一個考量時，要如何能夠找到一個簡單的備份還原機制來面對 Kubernetes 則是一個複雜的問題。 而本篇文章將會探討如何使用 Velero 來針對 Kubernetes 叢集進行備份，還原甚至是災難復原等操作，透過這類型的機制實際上也可以做到遷移 Kubernetes 叢集。

文章開頭作者提出了一個很值得注意的論點，就是高可用性(HA)的環境並不代表該環境擁有備份與還原機制。

HA 用來確保單一底層架構出現問題時整體服務不受影響，還是有能夠繼續存取既有的服務。但是假如遇到資料損毀或是其他意外刪除的，HA 的機制並沒有辦法讓這些服務可以復原。

所以就算系統是運行到 HA 的環境下，對於備份相關的解決方案還是需要準備，而且最重要的是這類型的解決方案不能只有準備，而是需要真的練習，嘗試復原，確保團隊熟悉整個還原的步驟，否則當問題發生時有可能會變成不知道要如何從備份資料來進行有效還原。

文章後半部分探討關於 Velero 的架構與使用，同時也列舉其他相關的專案，如

kube-backup
Cohesity
Kasten 10
Portworx PX-Backup]
Rancher Longhorn

對於 Kubernetes 備份還不熟悉或是團隊尚未導入的讀者可以嘗試使用看看 Velero

Ref: https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

今天要探討的是一個由 Google Blog 於上個月所推廣的軟體安全性框架，該框架名為 SLSA，全名則是 Supply Chain Levels for Software Artifacts，中文部分我不知道該怎麼翻譯才可以精準達到意思，所以建議就唸英文就好了。

該框架的目的是希望於整個軟體生產鏈中能夠進一步的去提升且確保所有產物的完整性(Integrity 這個詞該怎麼翻呢..)。

文章中用了一個很簡易的流程來清楚的解釋到底何謂 Software Supply Chain 以及整個流程中可能會有什麼問題。

Software Supply Chain 一個範例譬如
1. 開發者撰寫程式碼，並且提交到遠方的 SCM Repository
2. SCM Repo 因為程式碼改變，所以觸發相關的 CI/CD 流程
3. CI/CD 建置結束後則需要打包整個程式碼，產生最後的 Package.
4. 產生後的 Packet 則可以正式上場使用

文章認為上述的流程中有兩個不同類別的安全性問題，分別是
1. Source Integrity
2. Build Integrity.

Source Integrity 這邊主要是針對 Source Code 相關的問題，譬如
1. 開發者是否有意的故意塞入一些會不懷好意的程式碼到 SCM Repo 內。
範例: Linux Hypocrite commits, 之前美國某大學研究團隊基於研究嘗試上傳一些不太好的程式碼而影響的討論風波
2. SCM 的管理平台是否可能被惡意攻擊
範例: PHP 事件: 之前自架的 PHP Git Server 被攻擊者惡意攻擊並且塞入兩筆不懷好意的 Commit

而 Build Integrity 本身則是有更多不同的面向，譬如
1. SCM 觸發 CI/CD 過程是否有可能有問題
範例: Webmin 事件，攻擊者去修改團隊的建置系統去使用沒有被 SCM 所記錄的修改檔案。
2. CI/CD 建置系統本身被攻擊
範例: SolarWinds 事件，攻擊者攻破建置系統去安裝一些軟體來修改整的建置流程
3. CI/CD 建置過程中引用到錯誤的 Dependency
4. 攻擊者上傳一些惡意產物到應該只有 CI/CD 系統才可以存取的場所。
... 等

目前來說， SLSA 還處於非常早期階段，經由業界的共識來思考每個領域有什麼好的措施與指引來避免與偵測系統是否被攻破。其最終目標狀態是希望能夠根據環境自動產生出一套可整合到系統中的產物，並且最後可以給出 SLSA 憑證來給平台或是建置後的 Package。

對 SLSA 這個專案有興趣看看的請參考原始連結，內容不長但是頗有趣的

ref: https://itnext.io/helm-3-secrets-management-4f23041f05c3

Secret Management 的議題一直以來都是 CI/CD 流程中不可忽似的一部分，本篇文章作者不同於以往採用常見的解決方案(Hashicorp Vault, Helm Secret, SealedSecret)，反而是使用 Helm 內建的 AES 加解密功能來實作 Heml Chart 資料的加解密需求。

作者認為一個良好的機密管理解決方案需要能夠為其團隊提供三個基本需求
1) 所有的機密資訊都要能夠存放到版本控制系統中(Git...etc)
2) 所有被上傳到 Chartmuseum 的 Helm Chart Package 都不能有任何 k8s secret 物件，要放的只能有加密後結果。反之使用者要使用時也必須要有能力去解密
3) 單一工具管理，以作者來說會希望能夠都使用 Helm 這個工具來處理，愈少的工具意味者依賴性愈少，同時在維護與管理上要花的心力也更少。

作者首先列舉了兩個現存的專案，分別是 Helm Secrets 以及 Hashicorp Vault 並且針對這兩者進行了簡單的介紹，並且舉出為什麼這兩個專案並不適合作者團隊的需求與使用情境。

作者最後開始認真研究 Helm 本身有什麼內建的加解密功能可以使用，最後發現 encryptAES 以及 descryptAWS 這兩個內建函式可以使用，譬如

value: encryptAES "secretkey" {{ .Values.valueToEncrypt }}
value: {{ .Values.valueToDecrypt }} | decryptAES "secretkey"

有了基本的概念與用法後，作者透過 shell script 實作一層 wrapper 來簡化整個處理流程。
最後將這些資訊也導入到 CI/CD 流程中來幫忙進行解密的相關動作，讓 CD 可以順利的將目標 Secret 給送到 Kubernetes 中。


個人心得: 採用加解密的系統個人還是喜歡採用 SealedSecret 的設計理念，將解密的時間點延後到 Kubernetes 內而並非 CI/CD 系統上，主要是 CI/CD 的 pipeline 要是沒有仔細設計其實很多人會不小心把過程命令給輸出的，這樣的話加解密的過程，使用的 Key 等都有可能會洩漏出去。

ref: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf

本篇文章是探討一個前後端互相合作的設計模式， Backend For Frontend 簡稱為 BFF。

文章開頭，作者舉了一個常見的應用情境，假設團隊需要基於微服務的概念去設計一套電商系統，背後服務包括了購物車，訂單，產品，顧客...等不同類型的資料。
但是很容易後端所回傳的資料格式並不能完全直接符合前端的需求，這意味前端必須要維護一套邏輯來轉換資料格式來符合其需求。

基於這種情況，作者希望將前端這些轉換格式的邏輯給抽出來並且移動一個中間層來進行處理，而這個中間層也就是所謂的 BFF。
當前端需要請求一些資料時，前端會對 BFF 去發送 API，而此時 BFF 會執行下列行為

1. 呼叫對應的 backend 服務來獲得需要的資料
2. 根據前端的需求將獲得的資料進行格式轉換
3. 將轉換後的格式回傳前端

這種架構下，能夠讓前端的程式邏輯更為簡單與乾淨

接者作者針對 BFF 的架構又探討了幾個問題，分別

The role of a BFF
1. BFF 單純就是一個前後端中間的轉換介面
2. 前端 Team 要負責維護這個 BFF 的應用程式
3. 每個 BFF 就是針對一個前端，一個 UI 去設定，同時盡可能地讓前端程式碼保持單純與專注

Will this increase latency?
由於 BFF 就是一個前後端中間的轉換層，這是否意味所有請求都會需要花費更長的時間來處理，
答案是沒錯，每個請求只要經過愈多的節點整個花費時間會增加是不可避免的。
不過作者認為這個帶來的影響微乎其微，特別是當瀏覽器介面本身需要需要跟眾多沒有針對前端最佳化的服務取得資料時，BFF 帶來的影響基本上可以忽略。

此外，作者認為透過 BFF 的架構可以讓前端更容易得基於批次的概念來一口氣呼叫眾多後端服務同時於一個 reply 中取得全部所需的資料，甚至直接得更為方便呈現的資料格式。
作者提到這個特色針對 2G/3G 這種本身需要花上數秒鐘才可以建立連線的網路情況來說特別有效，減少向後建立連線的數量，反而能夠讓前端更有效率地去呈現畫面。

When to use a BFF for your applications
如同其他眾多的設計模式一樣， 使用 BFF 也是要依據團隊的使用情境與架構來判別。 假設團隊的應用程式是一個 monolithic 的架構，則 BFF 基本上幫不上什麼忙，帶來的好處微乎其微。
不過如果是基於微服務的架構的話，則 BFF 就有機會可以幫上忙。

文章中還有針對 BFF 的架構圖是以及其他相關好處，譬如
1. Separation of concerns
2. Easier to maintain and modify APIs
3. Better error handling in the frontend
4. Multiple device types can call the backend in parallel
5. Better security
6. Shared team ownership of components

有興趣的可以參考看看原文

ref: https://javascript.plainenglish.io/what-is-http-3-and-why-does-it-matter-cb7d7b4b600f

這篇文章簡單的敘述何謂 HTTP/3，主要探討 HTTP/3 到底跟 HTTP/1, HTTP/2 的差異是什麼

HTTP/3，也可以稱為 HTTP ove QUIC，這對過往的 HTTP 來說帶來了巨大的改變，因為 HTTP/{1,2} 都是基於 TCP 來傳輸封包，而 HTTP/3 則是仰賴 QUIC (Google 於 2012 所開發的協定，底層基於 UDP)。

TCP 目前普遍被使用到各式各樣的網路應用程中，而 TCP 本身的設計到今日來看也是有不少為人詬病的地方，譬如說 TCP 當初發明的時空背景與當前網路環境已經不同，譬如網際網路中的頻寬大小等
所以後續也有不少的演算法想要針對 TCP 來進行改善，譬如 Congestion Control 相關就有不少演算法可以選擇。

另外一個更直接簡單的就是直接跳過 TCP，直接使用 UDP 做為底層傳輸協定並且於應用層級重新打造一個如 TCP 一樣可信賴的傳送方式，這也是 QUIC 這個協定的基本概念。

透過 QUIC 的幫助，作者提到 HTTP/3 能夠得到下列的好處

Faster request multiplexing
HTTP/2 以前， 瀏覽器每次都只能對 Server 發送一個 Request，這導致網頁讀取速度緩慢，而 HTTP/2 則試圖改善這個機制，不過 TCP 本身的設計就不是針對這類型的使用
譬如眾多封包中只要有一個失敗， TCP 本身就會針對所有發送的 Request 去進行一個重送的動作來確保封包傳輸正常。
HTTP/3 因為不再使用 TCP 為底層協定而是 UDP，所以當上述情況發生時，也只需要針對失敗的 Request 進行重送即可，也因為此協定帶來的好處， HTTP/3 的表現會相較於之前版本來得更快更穩。


Faster Encryption
HTTP/3 允許最初的 HTTP Request 以加密的形式去傳送。過往傳統的 HTTPS 封包傳輸過程中，最初的握手階段交換資訊時，這些還是基於非加密的形式，要等到握手完畢後才可以能力將接下來的資料進行加密。
而 QUIC 本身可以針對 Initial Connection 進行 TLS 的處理，這使得 HTTP/3 於加密方面可以更順利也更簡單。

文章後半部分提到關於目前 HTTP/3 實作的部分，有興趣的人可以參考參考原文

ref: https://medium.com/event-driven-utopia/comparing-enterprise-messaging-and-event-streaming-e714f7b5fc40

本篇文章要來介紹 Event Streaming 與 Enterprise Messaging 兩種概念的不同
作者一開始就指出這兩種系統都很普遍被用來實作非同步且可高度擴展的應用程式，不過大部分的人其實一直混用這兩套系統但是卻不知道這兩套系統的差異。

因此本文假設一個有一個室內空調的應用程式，並且打算以開應用程式來解釋上列兩種系統的不同。
該應用程式的架構如下

溫度感知器 ----> Messaging System -----> 空調應用程式

感知器每十秒會將訊息送到 Messaging System，而空調應用程式會從 Messaging System 去讀取該訊息來決定是否要提高溫度或是降低溫度。
一個典型的訊息內容如下
{
"sensor_id": "sd1039eiruqo239023",
"room": "BEDROOM",
"timestamp": "2018-08-20'T'13:20:10*633+000",
"reading": 24
}

接者作者打算從五個不同的維度來解釋這兩種系統的不同

1. Message processing style
2. Message consumption style
3. Access to message history
4. Fine-grained subscription to messages
5. Message delivery guarantees

Message Processing style
對於應用程式來說，要如何從 Messaging System 讀取資訊來處理總共有兩種方式

1. 採用 Messaging 的類型，針對每個單一訊息去讀取並且處理
2. 採用 Streaming 的方式，將讀取到的訊息給聚合起來，譬如得到一段時間內的平均值並且基於該平均值去處理
舉例來說，應用程式想要根據前一分鐘的平均值來判斷當前溫度是否要調整

Message consumption style
對於 Messaging 類別的系統來說，只要有使用者讀取了該資料，該資料就會從系統中被刪除
但是對於 Streaming 的系統來說，這些資料的刪除跟是不是有使用得讀取是獨立事件，完全由 Streaming 系統去決定的

對於剩下三種維度的比較有興趣的人別錯過原文囉-

ref: https://medium.com/devopscurry/securing-your-ci-cd-pipelines-with-devsecops-in-2021-1a6a6e34f2e7

本篇文章作者想要探討的是如何透過 DevSecOps 的概念來強化你的 CI/CD 流程。

文章開頭探討了些關於 DevOps 文化以及對團隊帶來的改變，如何將 Dev, Ops 的工作流程給帶入到一個不同的領域，這部分想必大家都熟識了，所以這邊就不敘述太多。

接者作者開始思考，CI/CD 這種自動化的過程中，如果我們想要檢查資安與安全性相關，那到底有什麼樣的資訊市值得我們去檢查與研究的?

假設今天採用的是市面上 SaaS 服務的所提供的 Pipeline 平台，這些平台本身的資安問題並不是使用者可以去處理的，這方面只能仰賴這些服務提供商能夠有效且安全的去防護系統。因此作者認為我們應該要將注意力放在我們自行設計的 pipeline 過程中。

作者接者列舉了幾個議題，譬如

1. Source Code Vulnerabilities
這個議題要檢查的是軟體本身是否有相關的漏洞

2. OSS Library Vulnerabilities
所有使用到的 OSS Library 也都可能有漏洞需要注意，所以平常也要多注意 CVE 相關的資訊，有任何可以修復的機會時，團隊一定要評估是需要升級相關的 OSS

3. OSS Version
OSS 的社群也是會不停的開發與迭代，某些版本可能多年後就不被該社群團隊給維護，所以如果目前使用的 OSS 版本已經被標示為 deprecated，那意味就算有任何漏洞可能都不會有相關維護者去補修。因此團隊也要審慎評估是否要趕緊升級到一個有被維護的版本

4. Identifying Compromising Credentials
CI/CD 系統中不免都會有一些跟機密資訊有關的資料，這些資料是有可能當初處理時沒有被妥善管理，譬如不小心被 commit 到 source code 之類的，這部分的錯誤也都要避免。

檢查方面，作者提出不同的方式來檢查，譬如
1. Static Application System Testing(SAT)
程式編譯前的靜態掃描，該方法會嘗試分析程式碼本身是否有安全性漏洞，也是俗稱的白箱測試。

2. Active and Passive penetration t est (Dynamic Analysis)
3. Infrastructure Analysis
該方法包含了檢查環境中用到的設定檔案，伺服器狀態等，透過這些資訊來了解當前是否有什麼潛在的問題

最後，作者列舉出一些相關的工具，譬如
1. Checkmarx
2. IMMUNIO
3. Aqua Security
4. OWASP Zed Attack Proxy
5. Twistlock
6. CyberArk
7. WhiteSource
8. CHef InSpec
9. Fortify Webinspect

ref: https://towardsdatascience.com/five-things-i-have-learned-after-solving-500-leetcode-questions-b794c152f7a1

本文是作者敘述自身解決 500 題 leetcode 後的一些想法

對於每個軟體工程師來說，基本上都有聽過 leetcode 這平台，也勢必理解刷題這個行為

Leetcode 中的題目五花八門，大部分都聚焦於資料結構與演算法類別，而這類型的刷題也變得愈來愈普遍廣泛，
不論公司規模與否，很多都會需要透過刷題來進行面試，然而這類型的行為的確也出現了不少討論的聲音
譬如面試者擅長 leetcode 但是這項能力卻沒有辦法反映到日常工作所需要的真正技能上。

不考慮到底 Leetcode 這類型的刷題行為到底好不好，作者列出五個自己刷題完畢後學到的一些心得
1) The importance of Data Structures & Algorithms
2) There is always someone more knowledgeable than you
3) An edge case can ruin your day
4) Hard work beats talent…
5) Planning is an essential part of software development

The importance of Data Structures & Algorithms
Leetcode 本身不是一個資料結構與演算法的教學平台，不過其本身的題目可以幫助你瞭解更多資料結構與演算法使用的場景與使用方式。
作者提到這類型的基本功應該是每個軟體工程師都要有的，特別舉例不久前一篇玩家修改 GTA V 裡面某些資料結構的處理方式，使得整個讀取速度提升70% 的範例來闡述為什麼
需要掌握好資料結構與演算法。

There is always someone more knowledgeable than you
Leetcode 的解題過程中，最大的特點永遠都是留言區，裡面總是會有各種神奇厲害的解法，甚至會出現比官方解答更漂亮的解答方式。
作者自述有很大半的時間其實都是再重新實作這些很棒的解法。
這經驗讓作者體會到，人外有人天外有天，永遠都有比你厲害的人，工作上要盡可能的向那些厲害的人討教與學習，他們花了很多時間與經驗得來的知識都是非常寶貴且難得的，能夠學會就盡量學會。


An edge case can ruin your day
作者認為 Leetcode 的題目都擁有豐富的測試資料，包含了各種極端案例，這也意味刷題的時候如果沒有考慮各種不同情境常常沒有辦法順利通過問題。
這種思考過程的訓練對作者帶來了實質上的幫助，工作上能夠用更嚴謹的思路去思考每個撰寫的程式，思考有沒有可能有任何遺漏的案例可以在寫程式的過程中就找出來。

Hard work beats talent…
這句話的全文是
Hard works beats talent when talent doesn't work hard.
就算本身不是天選之人，但是透過努力還是有機會在天選之人松懈怠惰之時展現出自己強大與良好的一面。

註: 我想於如果天選之人比你還努力...那就讓天選之人拯救世界吧，我們還是做些簡單的事情就好

Planning is an essential part of software development
從眾多練習與面試的過程中，作者瞭解到 Coding 其實只是解決問題的一小部分，而聽到問題瞬間就馬上開始寫程式非常有可能走冤忘路。

軟體開發過程充滿各種不確定性，很多時候面試時遇到的問題其實都是那種曖昧或是不夠完整的敘述，再沒有掌握問題的全貌前就貿然寫程式常常只會愈走愈糟。
此外，軟體開發除了撰寫程式外，還必須要針對解決方法進行分析，該方法帶來的優點都需要仔細思考，同時也要確保團隊內對於該方法有一致性的同意才可以開始往下去撰寫程式。
作者最後強調，這個概念是真實工作中最重要的一環，透過溝通去理解所有的需求，確保一切都有共識後才開始實作。

剩下有興趣的歡迎閱讀全文

ref: https://loft-sh.medium.com/11-of-the-best-open-source-kubernetes-tools-2021-edition-b4aa49487845

本文會從三個類別來介紹作者認為跟 Kubernetes 開發維運有關的好用工具，這三個領域分別是
1. Running Kubernetes Environments
a. Minikube 依然好用，可以輕鬆創建環境，作者提到創建一個 cluster 只要 23 秒即可 <--- 我是懷疑加上 VM 時間應該沒辦法，除非單純用 container mode.
b. Helm 目前依然是部署方面最普遍被使用的包裝方式，
c. K3S 目前依然是輕量級 k8s 的選擇，特別是 IoT 等輕量級環境下想要部署k8s叢集則k3s幾乎是唯一選擇。

2. Simplify Feedback Loop
這個領域主要探討的針對開發者來說，如何能夠有效的提升開發流程，如何讓開發者能夠與 k8s 的互動更為抽象與簡單，讓開發者可以不需要學會太多k8s的指令又能夠將開發的結果送到k8s叢集內進行測試。
這類型的反饋資訊也就是標題所述的 Feedback Loop

a. 由 Google 開源維護的 Skaffold 專案目前能夠簡化開發者開發k8s 應用程式的流程，將建置Image,部署到k8s等步驟都自動化，開發者只需要呼叫指令或是存擋即可讓最新的程式碼自動部署到k8s叢集內。
b. 另外一套名為 Tilt 的軟體與 Skaffold 非常類似，不同點是 Tilt 有提供友善的介面，讓使用者可以更快地去知道當前撰寫的程式碼部署到k8s後會有什麼問題，從基本的 YAML 錯誤到部署後哪邊出問題都能夠盡量的點出
c. DevSpace 也是一套針對開發流程的開源專案，跟 Tilt 一樣都有提供介面，而全部的操作都是基於 devspace 這個指令來完成。
d. Lens 這套 Kubernetes 的 GUI 軟體功能愈加強大，作者甚至稱其為 IDE 而非單純的 GUI 功能，透過各式各樣不同的 Plugin 幾乎可以完成你想要達到的任何功能。

3. IDE Dev Tools I Can’t Live Without
a. 作者推薦 VSCODE 上面的 Kubernetes Tool 這個擴功功能，作者認為如果你的 IDE 不能夠有效地分辨 Helm Template 與 K8s vanilla YAML 的差異的話，你的開發速度跟體驗將會奇差無比。
b. VSCODE 上面的 YAML Language Support 這個功能也很好，能夠針對各種 YAML 文件的操作給予自動補齊與偵錯
c. 另外一個作者推薦的 VSCODE 擴充功能是 Footsteps，作者提到對於一個數百行以上的 YAML 檔案來進行修改有時候是厭煩的，而這個擴充功能會幫你把最近修改的內容用顏色給標示強調同時也透過快捷鍵可以讓你快速地跳於最近修改的行數之間往返。

這篇文章主要就是作者分享自己使用的一些工具，有興趣的可以參考原文

ref: https://medium.com/swlh/quick-fix-sharing-persistent-disks-on-multiple-nodes-in-kubernetes-ef5541fd8376

這篇文章是 kubernetes 與 Storage 整合的經驗分享文，該文章包括了下列內容
Cloud Storage, NFS, Kubernetes, PV/PVC.

Kubernetes 內針對這些儲存相關的使用方式有
1. 使用 ephemeral 的儲存設備
ephemeral 只適合暫存資料使用，因為該儲存設備不是持久保存的，這意味 Container 如果重啟，資料就會消失。
2. 使用 Bind Mount 的方式將資料從節點掛載到容器中
就如同過往使用 Docker 時會使用 -v 的方式將同節點中的儲存目錄給掛載到容器中來使用。

基本上有任何永久性儲存的需求都會採用(2) 這個方式來處理，而目前很多 Cloud Provider 都有提供相關的儲存裝置讓你的 VM(k8s Node)
可以輕鬆存取與使用。

舉例來說，AWS 有 EBS， GCP 有 GPD，這類型的 Block Storage Device 本身支援動態掛載與卸載，所以就算 Kubernetes 將目標 Container 重新部署到
不同節點上也不需要擔心資料會不同，因為這些 Storage 可以隨者不同節點動態掛載上去，讓你的 Container 看到相同的資料。
但是以上兩個裝置都有一個限制，就是並不支援同時多人寫入的動作，於 Kubernetes 只能使用 Read/Write 模式。
這意味每個 Storage 同時只能有一個 Container 去進行讀寫操作(but Azure 的服務就沒有這個限制)

作者假設今天有一個服務底層是由三個元件組成，這些元件會需要針對相同一個資料集一起處理。
舉例來說有服務 A,B,C
A: 將資料寫入到儲存系統中
B: 從儲存系統中讀入資料進行二次處理，處理完畢再寫回去儲存系統中
C: 將資料從儲存系統中讀出並且供外部使用

上述情境簡單說就是一個儲存設備，會有三個服務同時想要讀取，一個專心寫，一個同時讀寫，一個專心讀。
這種需求就沒有辦法單純使用 EBS/GPD等裝置來使用，因此作者接下來就會針對如何使用 NFS 這套網路儲存系統來搭建一個符合上述需求的用法。
該解決方案流程如下
1) 透過 EBS/GPD 的方式掛載一個儲存空間到 k8s 節點中
2) 部署一個 NFS Server 的容器到 Kubernetes 中，該 NFS Server 會使用 EBS/GPD 作為其儲存空間的來源
3) NFS Server 透過 service 分享服務
4) 部署 PV/PVC 物件到 Kubernetes 中
5) A,B,C 三種容器透過 PVC 的方式來存取 NFS Server

因為 NFS 本身就是一個可多重讀寫的解決方案，作者透過這種方式讓多個應用程式可以同時讀寫，同時將這些資料保存到 EBS/GPD 的儲存空間中。
不過這種用法帶來的問題可能就是速度問題，從同節點直接存取變成透過網路存取，所以如果本身對於存取有非常高的頻寬需求時，使用這種解決方案也許會遇到
很難解決的瓶頸，畢竟大部分人的 k8s 叢集都是 data/control 兩種資料交雜於底層的網路架構中，沒有辦法將 data plane/control plane 給分開來。

有興趣看作者如何一步一步搞定上述流程的可以參考全文

ref: https://svpino.com/lessons-learned-from-the-smartest-software-engineer-ive-met-35895ac9fe3a

本篇文章是工作經驗談，作者想要分享這十多年的工作經驗中，從那些聰明人身上所學到的事情，包含了
1. Fast is better than good
2. Unlearn what you know about technical debt
3. There aren’t stupid questions
4. Communication outweighs technical skills
5. Just because you can doesn’t mean you should
6. Share like there’s no tomorrow
7. Take full responsibility
8. The best code is the one nobody wrote
9. If you don’t test, it doesn’t work
10. Embrace failures

Fast is better than good
大部分的情況下，一個稱得上是好的解決方案勢必都要能夠針對時間，精力與成本這三個方面取得平衡。
太多人很容易一開始就會想要設計最完美個解決方案，導致一開始花費大量時間在思考跟設計，卻遲遲沒有動手。
作者認為不是說不要思考，而是不要認為有辦法一開始就可以想到一個最佳解，而是應該一邊做一邊改進。

Unlearn what you know about technical debt
技術債想必是大家都很厭惡的一個情境，作者希望大家可以從不同層面的地方去看待技術債
作者認為只要能夠用正確的方式去面對，技術債身上也可以有值得學習的機會，因為大部分的技術債
都是因為時間與人力不足下進行取捨所造成的結果，這邊帶來的隱含是到底哪些事情是團隊當前最重要的，哪些是不重要可以之後再改善的
最後來個公道話，計畫債太多一定有問題，但是沒有技術債更大的機率代表你都把時間花費在不是最重要的事情身上

There aren’t stupid questions
有問題就使勁地去發問，更多時候努力工作並不會讓你這個人獲得一個很深刻的印象，但是有效率與聰明的工作相對容易讓你被人記住。
任何不清楚的地方就問，問到一切都明瞭。

最後補上一個引言
「會問問題的人會當傻子五分鐘，但是不問問題人的人則是一生傻子」

Communication outweighs technical skills
能夠透過溝通來清楚描述想法的能力可謂是一個不可或缺的技能。
相對於技術能力來說，溝通能力很容易被大家給遺忘，甚至大家都不會覺得這記得有什麼值得重要的。
但是良好的溝通帶來的效果是無形的，所以請投資時間去學習如何有效的溝通。

Just because you can doesn’t mean you should
最簡單為團隊帶來影響的方式就是好好的針對所有事情排定優先順序，學會如何分辨重要性其實非常重要
畢竟時間有限，如何於有效的時間內帶來最大的效益也是一個不可或缺的技能

Share like there’s no tomorrow
隱瞞各種資訊並不會讓你成為團隊中不可或缺的關鍵人物，相反的，願意分享事情與知識的人更容易變成團隊中的核心角色
學會分享也同時藉由分享的這個步驟讓整體團隊一起成長

後續有興趣的可以參閱原文

ref: https://ably.com/blog/no-we-dont-use-kubernetes

八月第一篇，就來個有趣的文章，來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes，不但當前沒有使用，甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊，千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。

我個人覺得這篇文章滿好的，因為是認真的去比較導入 Kubernetes 帶來的改變，而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云，人家要我也要，人家不要我也不要...

文章分成兩部分，前述介紹當前 Ably 的環境架構是什麼，而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下，會發現導入 Kubernetes 沒有帶來實質上的好處。

文章開頭先簡述了一下 Kubernetes 這幾年的風潮，從最初 Google Borg 的開發開始談起，作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用，
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中，透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果，對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。

Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider，並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container，取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。

對於 Ably 來說，團隊中沒有任何 scheduler 相關的服務來調度各種服務，這意味每個 VM 就代表一種服務，所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務，用來確保運作的 Container 如果掛掉後可以被重啟，甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。

流量方面，因為每個 Autoscaling Group 就代表一個服務，所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題，畢竟每個機器本身都會被 VPC 賦予一個 IP 地址，所以使用上沒有什麼太大的問題。

接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變，分別有 (原文很多，這邊摘要不然文章會太長)
題外話，由於 Ably 的 Infra Team 數量有限，所以要考慮 K8s 只會考慮 K8s Service，如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM，畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說，透過這種方式能夠盡可能的榨乾機器的資源，整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源，這種被稱為 nosy neighbors 的常見問題已經不是首次出現了， Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用，而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務，不過這個做法跟團隊目前的作法已經完全一致，所以就資源管理這一塊，團隊看不到使用 Kubernetes 的優勢。

2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量，基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務，所以其收費是針對客戶實際上用多少服務來收，如果開了過多 EC2 VM，則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量，
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整，根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點，但是閒置並不代表沒有任何服務部署再
上面，因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說，k8s 有兩個動態調整的部分，動態節點與動態服務，而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。


3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案，基本上團隊只要能夠維持每個服務與背後的機器的關係圖，網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務

K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP，這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller，這些 Container 可以跟 AWS LB 直接整合，讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定，所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。

4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本，後續相關機制就會將 VM 給替換掉，然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果，雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。

上次四個分析基本上就是，使用 k8s 沒有帶來任何突破性的好處，但是 k8s 本身還有其他的功能，所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處

Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭，「除非經過評估，否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊，同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說，光 Storage 每家的做法都不同，而 K8s 沒有辦法完全將這些差異性給抽象畫，這意味者開發者終究還是要針對這些細節去處理。

Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由，畢竟這種用法就跟當初 Google Borg 用法一致，是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時，底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫，所以這個優點也沒有辦法幫助到團隊

Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC，所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。

Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群，社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下，一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s，但是真正理解 k8s 的人微乎其微，所以想要透過社群來幫忙解決問題其實比你想像的還要難，畢竟裡面的問題太雜，很多時候根本很難找到一個真正有效的答案。

Added Costs of Kubernetes