ref: https://betterprogramming.pub/software-engineering-interview-tips-7f3f33e15219

這篇文章是一個面試分享文，作者從自己過往的面試求職經驗中累積了哪些該做以及哪些不該做的事情，算是一個輕鬆小文。

看完這篇文章就做一個簡單的總結加上一些自己的想法

# 該做的事情

作者本身大學是念商的，以前一直自己比不上那些本科就是資工的競爭者，對自己的能力與經歷會產生懷疑。
但是面試的經驗讓她瞭解到，很多時候技術是一回事情，眼界與想法又是一回事情，不同背景的人對於相同主題往往會有不同的觀點，不同觀點交錯而成才有機會成就更好的專案，
因此相對於糾結自己的學習背景與經歷不夠純血，不如想辦法將自己過往的經歷融合到自己的思緒中，培養能夠從不同觀點來看待事物的能力，這種能力往往是很多團隊跟公司更加喜歡的。
畢竟整天待在軟體領域上，很多軟體技術都是可以學習的，不同背景的知識就沒有辦法那麼順利的重新學習。

找工作就如同找愛情，最重要的都是先釐清自己的需求，又不是鰲拜什麼都能要，所以必須要針對自己的需求去排序，譬如說
1. 薪資高低
2. 公司規模/領域
3. 職位發展
4. 工作/生活平衡
每個人需求不同，因此本來就沒有一個標準答案，但是如果連自己想要什麼都不清楚的話，很多時候就會展現出一臉茫然的問題，會讓人覺得你換工作這個大事情都沒有仔細思考，那你對日常工作的內容會不會也沒有辦法很專心的去思考？

此外，面試是雙方的事情，公司面試你的同時你也在面試公司，所以不要吝嗇地去問問題，不同類型的面試有不同的問題要詢問，譬如是技術方面探討時，永遠都要釐清問題再下手，就跟日常工作一樣，整體規劃都還沒有共識就直接實作，很多時候就會得到一些四不像沒人要的成品。
因此面試過程遇到的技術問題都需要仔細確認所有需求，一方面是確保你不會走歪，一方面也是展現出你解決問題的能力與方式。如果是主動詢問時，就想辦法透過問題將自己心目中的疑惑都給解決，這也是為什麼前面提到要先釐清自己的需求，面試過程中想辦法把這些需求都釐清，讓你瞭解當前這家公司是否有符合自己的需求。網路上也許可以看到很多消息，有的是真實爆卦，有的是廣告寫手，當然也有的是虛假欺騙。這中間要如何分辨真偽其實也沒有一個絕對的辦法，至少透過自己去觀察得到的結論會更容易說服自己。

作者也建議每次面試完畢後，盡可能快速的筆記一下當次面試的內容，如果下次還有二面/三面時，這些筆記內容都可以幫你回想一些事情，可以讓你的表現至少看起來不會是跟上次一樣一張空白，也許不會加分，但是至少力求不扣分。

# 不該做的事情
面試這種事情就是一個相親場合，你問題全部答對也有可能沒有拿到 Offer, 你問題有部分弄錯還是有機會拿到 Offer，很多時候沒有一個標準的答案去解釋為什麼沒有被錄取，與其自己幫公司腦補為什麼不被錄取，不如禮貌地詢問公司關於自己不被錄取的理由，好好的利由這些回饋幫助自己面對之後的面試。

也因為面試沒有一個標準答案，技術問題的相關面試其實不是要追求 100% 完美全對，更多的情況團隊想要看到的是面試者如何去面對問題，分解問題，然後有邏輯的處理問題。不要因為某一個環節自己好像講不好就開始垂頭喪氣並直接表現出來，永遠都是保持良好溝通，盡力即可。

履歷上往往後會列出一些過往成就與經驗，如果列出來就要好好表現與回答，每個人過往都可能參與很多專案，有大有些，有的可能都忘記相關細節了。這種連自己都沒有辦法講清楚到底該專案是什麼，自己又進行了何種貢獻的經歷就不建議寫出來放到履歷上，畢竟寫了還回答不出來只會讓面試關覺得那你這個經歷有什麼用？
不論是臨時抱佛腳還是真的都記得，所有列在履歷上的項目都應該要能夠侃侃而談，聊整體經驗，聊自己的貢獻，含糊帶過只會讓人印象更不好。

作者表示面試過程都是個高壓環境，為了讓自己表現盡可能保持正常水準，睡眠與健康都很重要，不要以為自己是超人一天排滿一堆面試，東跑西跑導致自己的體力與精神都花費於交通上，等到真正面試時就沒有精力去面對這些問題了。

文章中還有一些細節都沒有補充
覺得這類型的文章就是其實多參加面試，或是有機會的話也可以當面試官，久了其實就會有一套自己的經驗與想法。

ref: https://medium.com/cast-ai/8-best-practices-to-reduce-your-aws-bill-for-kubernetes-43e01c8b8e42

本文探討的是如何幫 AWS 上的 Kubernetes 進行預算控制，根據調查，大部分雲端使用者的帳單都是超額 23% 左右。
以 AWS 來說，光 EC2 的類型就超過 150 種，使用者怎麼可能很理解每種差異然後選出真正適合的?

不論是使用 EKS 或是使用雲端資源架構 Kubernetes, 本篇文章都提供相關訣竅來幫你省錢。
整個訣竅分成 10 部分
1. Quick guide to AWS pricing
2. Start by understanding your AWS Kubernetes bill
3. Defined your requirements
4. Choose the right instance type
5. Verify storage transfer limitations
6. Check if your workload is spot-ready
7. Cherry-pick spot instances
8. Bid your price on spot
9. Use mixed instances
10. Make multiple availability zones work for you

# Quick guide to AWS pricing
要最佳化整個 AWS 的消費前提是先理解 AWS 的計費方式，EC2 VM 基本上分成三大類， On-Demand, Reserved 以及 spot

## On-Demand
On-Demand 基本上就是 Pay-As-You-Go 的運作模型，你用多少資源就付多少錢。 舉例來說 AWS 根據你每小時的 VM 使用量作為收費基準，用多少就付多少，沒有任何合約或相關限制。
很多人使用這種機器都會搭配一些腳本來達到動態關閉，譬如晚上離峰時間關閉一些機器，然後白天尖峰前再動態開啟機器進行。

這種模型是三種模型中最貴的，畢竟其使用起來最彈性，不受任何限制。很適合用於那些難以預測使用情境的狀況，機器開下去就是了。
不過如果今天使用情境很規律，那也許可以考慮看看另外兩種模型

## Reserved
On-Demand 的變形版，可以直接跟 AWS 購買一份 VM 合約(1~3年)，該合約標定要使用的機器類型與地區(AZ, Global)。透過該合約可以將整體花費給縮小到 on-demand 的 60% 左右。
所以如果有機器是確定需要長期使用且沒有太多變化的，那就可以使用 Reserved 來購買合約省錢

## Spot
Spot 的用法更為特別，用類似競標的方式去取得機器的使用權，相對於 on-demand 來說，其花費有機會降到 10% 左右。
不過這種類型的機器的可用性就無法保證，當你使用的機器要被回收輪給別人使用的時，你會收到兩分中左右的警告通知。

由於 Spot 的特性，並非所有的應用程式都很適合部署上去，所以需要更加瞭解應用程式的型態才可以確保是否適用 Spot 的機器。

另外不要忘記的是 AWS 上的服務都要收費，譬如網路流量，儲存設備，NAT GW 等，所以計算整體成本的時候不要忘記把這些算進去。

# Start by understanding your AWS Kubernetes bill

AWS 的帳單內容非常多，為了有效率的找出花費瓶頸，最好搭配 AWS 提供的三個工具來使用，分別是 Cost Explorer, Budgets 以及 Cost & Usage Report.

如果團隊內有多個 team 要共用 AWS，那這種情況就需要藉由不同的方式讓 AWS bill 更加清楚，譬如透過 Organizations 的方式來管理多個 AWS 帳號，讓每個團隊/部門/專案分配一個專屬的 AWS 帳號
Organizations 中會準備一個 Root 帳號，可以讓帳號去負責處理所有 AWS 帳號的 bill，同時 billing 報告中也會基於帳號去顯示，這樣就可以比較清楚的去區分每個帳號的花費。

接下來針對幾個省錢技巧進行些摘要

# Choosing the right VM instance type
## Defined your requirements
首先要先評估自己需要用到的資源，包含
1. CPU 數量與架構
2. Memory
3. Storage (容量/速度)
4. Network (Public/Private, 效能)

要注意的是選擇一個非常貼近需求的機器型態聽起來符合需求又省錢，但是還是要考慮到如果應用程式有可能會突然使用更多的記憶體，這種情況下到底要不要用更強的機器來提供一個更靈活的環境則是一個要思考的問題

此外如果有 GPU 需求的也要想一下，到底是要追求速度而使用 GPU 還是為了成本而使用 CPU 慢慢處理。

## Choose the right instance type
基本上來說， AWS 的帳單中佔最大比例的一定是 EC2 的 VM 資源，選擇一個正確的 VM 類型有可能省下高達 50% 左右的花費

AWS 針對不同情境提供不同類型的 VM ，每個類型又有不同的等級，對使用者來說想要找到一個符合自身應用程式需求的 VM 非常困難。
而且更多的情況下是挑選到一個過於強大的機器等級，而使用者也渾然不知道然後每個月就繳納更多的錢。
作者團隊認為這問題的解決方法很暴力，就是準備好相關的 benchmark，然後針對所有的 VM 類型去進行測試，作者團隊還特別寫了一篇文章介紹如何執行這件事情以及相關的過程與心得
文章中有相關連結

## Verify storage transfer limitations
Storage 也是一個需要花錢的部分，請仔細確認過到底應用程式需要的 storage 存取速度與效能需求，譬如沒有需求的話就不要沒事情去使用 premium SSD 這類型等級的儲存設備

文章後半份探討更多關於 Spot 的概念，包含什麼樣的 Task 適合放到 Spot，什麼樣不適合，最後還要探討 Autoscaling 相關的討論。

ref: https://netflixtechblog.com/what-is-an-a-b-test-b08cc1b57962

本篇文章來自於 Netflix 的技術 blog, 主要是介紹何謂 A/B Testing 並且透過一個可想像的案例來介紹 Netflix 會怎麼使用 A/B Testing 來提升整體用戶的黏著度

該篇文章最開頭就假設一個 UI/UX 上的變化，如果 Netflix 將所有影片的小圖都給上下顛倒，這種改變是否會對使用者帶來什麼樣的改變？

所謂的 A/B Testing 基本上就是要有兩個群組，兩個群組分別套用不同的變化來藉此觀察群組內的行為，由於要觀察的是 UI/UX 變化的影響，因此其他的部分就要盡量確保兩個群組是相同的，譬如年齡分數，地區分布，人種分佈等。
當群組都準備完畢後，接下來要仔細去思考想要觀察的目標是什麼，這個部分會根據控制變因不同而有不同，想要觀察跟搜尋有關的實驗，其測量的基準就會跟探討使用者會花多少時間讀取一部影片就是完全不同的，因此設計一個 A/B Testing 前
也必須要仔細思考假如有了這個實驗，你要如何去測量這個實驗所帶來的變化。

文章中先舉例為什麼需要有兩個不同的群組來進行比對，假設今天是針對一群人於不同的時間點給予不同版本的 UI，譬如 1-15 日採用舊版本的 UI， 16-30 日採用新版本的 UI，然後結果很明顯地告訴你 16-30 的新版本讓使用者有更高的黏著度，這時候你有多少的信心去相信
這些變化真的是新版本 UI 帶來的改變？
對於 Netflix 的串流服務來說來說，其實就算什麼 UI/UX 都不改變，使用者的黏著度本來就會根據當前的一些大事件而改變，譬如一些著名影集出續集，有一些突然爆紅的影集引起流行等，這種情況下這個測試變得非常難去測量，到底黏著度的提升是不是新 UI 所帶來的？

這種情況下必須要說整個測試基本上是沒有用的，因為變數太多，根本沒有辦法給予一個有信心的答案，這也是為什麼測試需要同時針對多個群組去進行比較。將上述的問題分成兩個群組，其中一個採用舊版 UI 而一個採用新版 UI然後觀察一段時間。
不論當前有什麼流行事件或是新影集，兩個群組內的人都會同時被影響，所以這兩組人唯一的差異還是只有 UI 的變化，因此測試出來的資料就會加容易分析，團隊也更有信心針對這次的變化去給一個結論。

文章後半部分探討「當加入當前地區所觀賞前 10 趨勢」新介面的一些想法與過程，有興趣的可以閱讀全文

ref: https://thenewstack.io/duplication-not-consolidation-the-path-forward-for-apps/

「DevOps 的時代，到底不同團隊之間要怎麼合作，要採取一個統一個工具語言還是每個團隊要保持自己的形狀？」

作者這篇文章想要從不同角度來探討為什麼團隊還是要保持自己的形狀而不是一股腦地全部都導入相同工具講相同語言。

隨者近年微服務，雲原生等各種生態浮現，IT, DevOps 團隊都必須面對這波轉型階段，一種常見的做法就是將所有的架構都慢慢轉向一些共同的平台語言，如 Kubernetes, 雲原生, 微服務 等。
作者看到很多公司都要求所有團隊都要使用相同的平台講相同的語言使用相同的工具，希望透過這種合併的方式讓個團隊間溝通更加順暢。

實務上來說， NetOps, SecOps, DevOps 這三個團隊的職責都不同，需要的指標與 KPI 也都完全不同，因此要求這三個團隊採用相同的機制與語言實際上整合的過程則是非常痛苦。
很多大公司目前內部架構都是由雲原生與那些 monolithic 應用程式所組成。

舉例來說， NetOps 與 DevOps 對於流量控管這件事情就有完全不同的想法與期望，NetOps 看重的是整體流量的安全性與穩定性，其必須要確保整個公司網路都是穩定且運作中，所有部門都能夠透過其正常上網。
有些狂熱份子會希望 NetOps 也可以導入快速迭代與快速部署等概念，讓所有底層的防火牆，負載平衡器以及相關的網路設備都可以享受到快速更新與藍綠部署的優點，但是對於 NetOps 來說這類型的服務是整個公司的命脈，謹慎嚴謹更為重要
畢竟網路壞了你是要怎麼存取網路來快速迭代與快速部署？
或是說希望 NetOps 介入 Kubernetes 的世界，要負責幫忙管理所有網路相關功能，然而對於 NetOps 來說這類型的操作與玩法與過去的經驗不同，因此有可能整體處理的時間就完全不符合 DevOps 團隊的需求。

DevOps 重點則是配置適當的防火牆規則與路由規則使得後方的應用程式能夠正確地被外界存取，因此很明顯在意的東西與 NetOps 是完全不同的，這時候要求兩個團隊強迫使用相同的方式與流程實際上反而會讓彼此效率減半。
SecOps 來說，微服務與 Kubernetes 的出現也對資安帶來很大的挑戰，很多現有的工具都是針對叢集外的架構去進行檢測與防衛，容器的到來使得這些工具需要轉換期，並且還要思考如何將資安流程給整合到 Kubernetes 平台中。
這時候就會遇到一些困境，DevOps 想要更快速的迭代與部署，SecOps 不想因為很多資安部分都還沒有橋定與設定好，這時候貿然部署太多新服務可能會其他潛在的資安問題，因此兩個團隊就有需求衝突。

作者針對這類型問題提出了一個想法，「Duplication, Not Consolidation」，違反直覺但是又顯而易見，就是停止一統江湖的操作，擁抱與允許底層架構工具的重複，不要求大家使用相同的工具與平台。
以流量控管來說，NetOps 團隊專心控管底層網路，使用自己擅長的工具與方式去管理整個公司門面，確保效能與 DDOS 的防護能力與其他的網路設備。
NetOps 透過底層網路將流量轉發到每個應用團隊中，應用團隊的網路流量就像是整個大公司中的沙盒一般，DevOps 根據自己需求創建一個輕量級的 Ingress Controller 來管理而不需要讓 NetOps 來幫忙處理。
任何的規則變化都由 DevOps 自行維護，這種架構讓 NetOps 能夠用穩定的方式去維護底層網路，而 DevOps 可以專注於自己的需求，

文章後半部分還有幾個範例，探討SecOps/DevOps 的其他共享案例，有興趣的可以參閱全文

ref: https://www.cncf.io/blog/2021/10/20/a-guide-to-choosing-an-ingress-controller-part-1-identify-your-requirements/

本篇文章是由 F5 Nginx 所發表的系列文，主要是探討如何選擇一個適合團隊的 Ingress Controller，第一篇系列文探討的概念適用於所有問題，就是釐清需求。
測試環境與正式生產環境的需求不太一樣，測試環境可以幫忙釐清功能需求，但是生產環境還需要在意的則是規模問題，譬如能否處理大規模流量。

Kubernetes 透過 Ingress Controller 的概念來負載平衡 L4/L7 的流量，不論是進入到 K8s 叢集或是離開 K8s 叢集的流量都有機會被 ingress controller 給處理。
以下是業界常用來表達流量的專業術語
1. Ingress Traffic: 進入 K8s 的流量
2. Egress Traffic 離開 K8s 的流量
3. North-Sourth Traffic: 同 Ingress Traffic
4. East-West Traffic: Serivce 之間的流量

Ingress Controller 主要針對 Ingress 與 Egress 這兩個流量進行處理，常見功能有
1. 接受外部流量(Ingress Traffic)，根據情境動態調整流量內容並且負載平衡到後方容器。
2. 監控所有想要被外界存取 Pod 的生命週期，確保所有的流量轉發都能夠順利的達到當前存活的 Pod，避免有任何流量被轉發到先前已經死去的 Pod
3. 針對 Egress 的流量進行二次處理，譬如限流或是透過 mTLS 提高安全性。

如果想要針對 East-West 進行處理的話，通常會使用 Servive Mesh 這類的解決方案。

挑選一款 Ingress Controller 時很有可能會先從所謂的 Feature 清單開始挑起，看看誰的功能多誰的功能少，但是這種選擇方式很有可能最後會挑到一個看起來功能很多結果完全不符合團隊需求的產品。
因此作者認為一個比較好的方式是從兩個方面去看起，分別是使用情境以及資源使用。

# 使用情境

Ingress Controller 的核心功能就是流量控管，所以很直覺可以想到下列情境
1. 負載平衡 (HTTP2, HTTP/HTTPS, SSL/TLS termination, TCP/UDP, WebSocket, gRPC)
2. 流量控制 (rate limiting, circuit breaking, active health checks)
3. 流量 分群 (debug routing, A/B testing, canary deployment, blue-green deployment)

但是大部分的 Ingress Controller 能夠做的事情不單純只有流量控管，譬如

1. Monitoring and Visibility
由於 Ingress Controller 處於 K8s 叢集與外界流量交換的邊界點，因此 Ingress 非常適合針對這類型的流量進行分析以便後續除錯。特別是 1)存取速度變慢的應用程式 2)資源耗量過大
為了滿足可觀察與可觀測的功能， Ingress 必須要可以即時地提供當前狀態，讓管理者能理解當下流量到底是什麼，有什麼問題，同時也要可以跟常見專案如 Prometheus/Grafana 進行整合，讓管理者更容易去瀏覽與觀察。
2. Authentication and SSO
將身份驗證等發生點從 Kubernetes Service 給拉到 Ingress 來處理能夠提供兩個好處，譬如透過 SSO 的功能讓使用者能夠單套帳密存取多套服務以及讓每個應用程式都不需要獨立建制驗證與授權等機制，簡化每個應用程式的設計與部署。
3. API Gateway
4. Web Application Firewall Integration

# 資源使用
Ingress Controller 的選擇會帶來兩種資源的消耗，分別時間與金錢。
選擇錯誤的 Ingress Controller 可能會導致團隊花費過多時間再研究要如何設定與配置，甚至可能根本沒有辦法達成需求，更詳細的說法有
1. 團隊中誰要負責配置與管理這個 Ingress Controller？ 該員工是全職管理維護還是只是兼職處理？
2. 該員工是否有足夠的時間去學習習該 Ingress Controller? 或是該解決方案必須要很容易上手？
3. 當今年 Ingress Controller 發生問題或是有新的功能需要研究時，是否能夠讓開員工有足夠的時間去處理？

其實上述的問題都圍繞於該 Ingress Controller 是否與 Kubernetes 有高度整合，是否容易理解以及是否容易管理，如果團隊不打算讓一個人全職處理，讓選擇一個複雜難以管理與理解的 Ingress Controller 就只會讓該負責的員工很難準時完成交付的任務

就 F5 自己於業界的觀察，滿多公司都會將這類型網路功能的管理與擁有權都交予 NetOps 團隊，讓該團隊專心處理如 Ingress, External Load Balancer 等連接 K8s 與外部網路的服務，然後 DevOps 團隊則是更加專注於內部應用程式的部署。

對於 Ingress Controller 來說，有滿多開源專案可以使用，基本上使用上沒有太多問題，但是如果今天要想要的特殊功能只有商業版本才有支援時，就意味者團隊需要針對 Ingress Controller 去付費
這種情況下就要思考到底要採用基於 Cluster 數量來付費還是基於 Ingress Pod 數量來付費？

原文中還有更詳細的探討與分析，有興趣的可以點選全文

ref: https://www.nginx.com/blog/guide-to-choosing-ingress-controller-part-3-open-source-default-commercial/

這邊依然是 F5 Nginx 的 Ingress Controller 系列文，針對 Ingress Controller 的領域繼續探討，這篇要探討的是不同來源方式的優缺點。
F5 Nginx 將其分成三個領域，分別是 Open Source, Default 以及 Commercial。

Open Source 代表的是由社群使用者所維護或是一群特定團隊所維護的開源版本，最知名的就概念就屬 Nginx 的開源版本。實際上去收尋的話會發現網路上有兩套 Nginx Ingress Controller，一套是由社群自行維護，另外一套則是由 Nginx 公司內部維護並且開源的版本。
優點:
1. 社群導向: 除了免費之外，有部分公司傾向於使用社群導向的解決方案
2. 功能開發速度快: 這類型的解決方案都很樂意也積極的去開發新的功能

缺點:
1. 時間成本: 通常這類型的工具整合方便都不會太簡單，很少有一鍵安裝之類的工具，這意味每個使用者都需要先熟讀文件來理解如何安裝與使用甚至還要針對自己環境進行客製化。
2. 潛在危險: 產品規模大之後都會開始考慮關於穩定性，安全性等指標。社群驅動的版本有時候太針對功能開發或是貢獻者不夠穩定導致功能不穩是很常見的事情。
3. 由於沒有任何金錢成本，所以基本上也沒有什麼售後服務與技術支援，唯一有的大概就是相關的 Issue 與討論串，但是因為這一切都是社群維護，所以你的問題也沒有什麼優先度保障。

Default 代表的是由特定公司開發與維護的版本，這些版本通常都與某些平台有強烈整合，甚至是完整解決方案中的一環，譬如各大公有雲的 Ingress Controller, Rancher 以及 RedHat OpenShift router.
優點:
1. 成本不高: Ingress Controller 都已經整合到服務的平台中，所以使用上都相對簡單，沒有複雜的設定，可以大幅度減少研究時間。
2. 穩定且有技術支援: 通常這類型的產品會比純開源產品來得更為穩定一些，因為所有的開發都是基於整個平台的整合為考量，不會單純為了衝功能而開發。技術支援部分免費版本可能都沒有，但是有額外付費購買平台的話也會有技術支援。

缺點:
1. 產品綁定： 由於這類型的 Ingress Controller 都是綁定特定平台，因此使用上也變成很難單獨使用，都要跟平台一起
2. 只有基本功能: 這類型的 Ingress Controller 通常只有最基本的功能，沒有比較進階的流量控管與安全監控等功能。
3. 難以預測的時間與金錢成本: 由於功能簡單，所以一開始使用上不會有太大問題，但是如果有進階需求時可能就會發現該平台並不支援，這樣會導致花費大量時間研究還可能沒有辦法得到好的結果，此外雲端服務還要考慮到流量帶來的成本問題。

Commercial 代表的是有授權相關的商業產品，通常都是針對大規模應用環境去開發的。
優點:
1. 功能更多: 商業版本因為要付費，所以必須要有其應該有的價值，譬如會有更多進階功能是免費開源版本所有沒有的，這些功能可以讓團隊更輕鬆的整合各種服務
2. 穩定與技術支援: 商業軟體的一個特色就是穩定，通常每次的釋出前都會有完整的測試來確保足夠穩定，畢竟這類型產品就是公司的商業命脈，因此公司會比開源社群用更嚴謹的方式去面對每次的更新

缺點:
1. 緩慢地開發流程: 商業軟體更在意的是整體的穩定性，所以功能開發的速度會相對慢。
2. 價格考量: 這類型的產品什麼都好就是價錢不好，同時也要看一下該產品的付費方案有哪些。

更多比較與介紹可以參考全文

ref: https://www.forbes.com/sites/greatspeculations/2021/10/12/gitlab-another-overpriced-tech-company/?sh=5480a1235286

不知道大家有沒有注意到 GitLab 於 10/14/2021 正式於美國 IPO 上市，代號 GTLB。
本篇文章的作者從別的角度來解釋為什麼他認為 GitLab 又是一個估值被高估的科技公司。

估值來看，作者認為每股 $55-60 的 Gitlab 價格實在是過高了，實際上大概只有 $5 左右，而接下來的文章內容都在闡述為什麼作者會有這樣的想法

# 盈利模型不可靠
Gitlab 的營收模組與很多軟體公司都一樣，採取免費版本讓你用，進階版本收你錢的模式。直到 06/2021, GitLab 全球大概有三千萬的使用者，但是真正付費的使用者數量只有一萬五千多。
簡單來說，GitLab 的營收轉化能力不到 1%，低於同業營收模型的 2%~5% 轉化率，而且大部分付費的使用者都採取價格較低，利潤較低的方案，以 GitLab 的資料來看，大概有 3632 的基本客戶每年提供 $5000 美元的收入，
只有大概 383 位用戶每年提供超過 10 萬美元的收入。
從淨收入來看， 2021 相對 2020 的年成長率高達 87 %，所以是有更多使用者願意付費，但是其核心業務盈利(Core Earnings)則從 -1.25 億美元下降到 -2.13 億美元，這意味核心業務的賺錢能力是下降的。

GitLab 的營收策略顯然更像是專注於增長收入能力而放棄於整體營收，其他數字包含 (2020 -> 2021)
1. 稅後淨營業利潤(NOPAT)從 -158% 提升到 -141 %，整體小成長但是賠錢的。
2. 投資資本回報率(ROIC)從 -41% 下降到 -76%
3. 現金流從 -1.49 億美金下降到 -2.29 億美金

作者認為雖然整體收入提升，但是對於股東來說整體價值是下降的。

整體文章非常長，從非常多角度去探討，對於這個議題有興趣的可以參考看看

ref: https://engineering.linkedin.com/blog/2020/making-the-linkedin-experimentation-engine-20x-faster

今天這篇是 LinkedIn 的記錄部落格，探討到底 LinkedIn 的 A/B Testing 到底有多瘋狂，如何並行高達三萬五千多種不同的 A/B Testing.

因為 LinkedIn 依賴基於資料分析來辦別每個改動是否能夠達到預期上的效果，因此 LinkedIn 所有新功能都必須要經過 A/B Testing 來決定每個新功能最後的方向。
其內部開發了一套專門針對有大量 A/B Testing 需求的系統，該系統著名的指標有
1. 網路呼叫高達 800,000 QPS (Query Per Second)
2. 並行運行了 35,000 不同的 A/B Testing 實驗
3. 每天會執行高達 23 trillion (23,000,000,000,000,000) 次的邏輯判斷
4. 邏輯判斷的平均延遲時間是 700ns，99百分位的時間則是 3μs
5. 有高達 500 個正式上線服務使用這個平台

這個 A/B Testing 的平台準確來說稱為 Lix Engine，整個運作流程就如同 A/B Testing 的想法一樣。
Service 發送 A/B Testing 的請求到 Lix Engine，該系統去計算與評估來確認到底該次 Request 是屬於控制組還是不變組，最後將結果給回傳給 Service
最後 Service 根據這個結果讓使用者有不同的行為。


文章後半部分就開始針對這個名為 Lix Engine 的平台進行詳細介紹，包含
1. 到底什麼是 Lix Engine，其實際上到底做了哪些事情
2. 這個從 2012 左右就開發的系統實際上又遇到了哪些困境與缺陷
3. 該系統最後打算重寫，而重寫的過程中是如何決定各項重要指標，譬如使用何種指標，何種使用方式
4. 最後探討整個實作細節

整篇文章非常深入了去介紹這個系統，不單純只是從表面去介紹其功能，而是從內部跟實作方面都有涉獵，非常推薦對 A/B Testing 或是系統設計有興趣的人閱讀一番

ref: https://towardsdatascience.com/3-python-projects-that-will-help-automate-your-life-b6d48a4c1fa2

本篇文章作者想分享三個能夠幫忙自動化日常工作的 python 專案

日常工作中如果有些事項需要反覆執行，而每次執行又覺得有點煩瑣惱人的話，通常都可以考慮看看是否有自動化的價值，因此作者就分享自己使用過且有巨大幫助的三個專案。

# Automate Excel Reporting(mito)
為了準備一個 Excel 報表，通常除了基本資料外，還會使用內建函式，資料轉換然後會畫各種不同圖表。
這類型的工作執行一次可能還行，但是如果今天需要頻繁的準備 Excel 報表，那就可以考慮將其自動化。

Python 方面有很多相關的專案可以用來處理，譬如 openpyxl 與 Pandas 來完成，但是 openpyxl 的問題在於不容易上手，初學者要先花不少時間熟悉其架構與語法。
因此作者推薦另外一套更為簡單的專案 mitosheet(mito)，該專案最爲特別的是其提供了一個友善的介面讓使用者去操作，接者會將這些操作全部轉為 Python code，所以對於初學者來說
可以達到所見即所得的方式。

文章中有作者使用 jupyter notebook 的範例來操作 mitosheet 並且產生相關的程式碼最後完成自動化 Excel 報表的範例。

# Automate Data Visualization(mito)
# Web Automation（Selenium)

後面兩個領域有興趣的可以參閱全文

ref: https://medium.com/system-design-concepts/distributed-cache-system-design-9560f7dd07f2

本篇文章是一個系統設計分享文，內容不會非常深入，我認為算是一篇如果滿好的入門文。
該文探討的是如果想要設計一個分散式的 cache 系統，到底要從何處切入以及整體架構上需要考量的點。

Cache 的概念現在無所不在，從作業系統， CDN, DNS 到各式各樣的應用程式都有快取的概念。談到快取時最簡單的想法就是比硬碟讀寫快，能夠讓應用程式夠有效率地去讀寫資料。

文章接者針對幾個核心概念去探討，包含
1. Cache 的存取模式
2. HashTable 的運作模式
3. 分散式架構下的 HashTable
4. Cache 驅逐舊資料的演算法
5. 內部程式設計
6. Fault-Tolerant
7. 高可用性

這邊就針對幾個議題進行簡單摘要，對於整個細節都有興趣的可以參考

# Cache 的存取模式
三種常見模式，分別是 Write through, Write around 以及 Write back (實際上有更多做法，甚至還要考慮 Read 的路徑，本篇文章只是介紹幾個)
從這三個模式的名詞可以觀察到差異主要是針對寫入這個選項去探討，使用者今天要新增一筆資料時到底該整個更新路徑是如何
rite through: 先寫到 Cache 並且寫入到 DB，當資料同時寫入到 Cache 與後端 DB 且都成功才可以算是該筆寫入成功。
Write around: 資料只會寫到後端 DB，當相同資料下次發生 Cache Miss 時才會讓該資料被寫入快取
Write back: 寫入到 Cache 並且馬上回傳給應用程式，應用程式感受到的延遲性最低。會需要有額外的應用程式幫忙將 Cache 的資料同步回後端 DB

# Cache 驅逐舊資料的演算法
因為 Cache 通常代表的就是小而貴，能夠存放的資料量也不能這麼多，因此當愈來愈多的資料需要被快取使用時勢必要有所取捨，哪些資料要保留，哪些不保留。
一個比較直覺的做法就是 LRU，將最近沒有使用到的資料給剔除，文章內就針對 LRU 寫了一個範例 Code.

# Fault-tolerant
假設 Cache 內的所有資料都存放於記憶體中，那運行節點如果出現問題譬如斷電重開機，記憶體清除就會導致 Cache 的資料都完全消失，這邊列舉兩種做法來處理
1. 定期針對資料進行快照。透過一個背景程式定期地將記憶體內的內容給複製一份給寫入到硬碟中，這樣當系統重開機時就可以從硬碟中的內容還原上次的 Cache 資料
2. 透過 log 的方式重造系統。讓 Cache 系統針對每次操作都會撰寫一個相關的 log，所以系統重開機時可以針對這些 log 內容重新操作來復原之前的資料

ref: https://medium.com/capital-one-tech/10-microservices-best-practices-for-the-optimal-architecture-design-capital-one-de16abf2a232

本篇文章探討十個關於微服務架構的十個實戰技巧。
微服務概念的出現大大地改變整個應用程式的組成架構，從過往單一包含所有功能與商業邏輯的 monolithic 架構變成由多個單一功能的元件互相合成的微服務架構，本篇文章分享十個微服務的基本概念，希望透過這些概念能夠讓你打造出更有效率且少走冤枉路的架構

相對於 monolithic 來說，微服務的架構會有幾個不同點，包含
1. 每個元件可以採用不同的程式語言實作，同時可以有自己的開發與發佈週期
2. 組織中的每個團隊都有自行維護的微服務元件，不同團隊可以併行開發與測試，整體來說會更快速與有效率的去面對市場變化
3. 由於目前是多個元件共同組成服務，所以單一元件的壞掉不太會導致其他的元件一起壞掉。過往 monolithic 的情況很有可能一個地方沒寫好導致整個應用程式都無法運行，最後所有功能都沒有辦法正常運行

然而當微服務的元件數量逐漸成長，彼此之間的關係沒有仔細規劃時，可能會導致這些元件之間的關係錯綜複雜，這會使得整個維護成本上升，跨團隊之間的合作成本也會一起提升，
因此設計一個良好的微服務架構是需要訓練與學習的，並不是單純把所有功能都單獨拆開就是一個好架構，因此底下的十個架構就是希望能夠避免打造出一個悲劇的微服務架構
1. The Single Responsibility Principle
微服務應該要與過往寫程式的習慣一樣，每個元件都專注一項功能，同時牽扯太多服務就像一個 class 同時牽扯過多不同的商業邏輯一樣，基本上是個不好的設計

2. Have a separate data store(s) for your microservice
過往 monolithic 架構下很容易看到所有服務都採用相同的 database，但是因應微服務架構的特性，這種架構未必是好的。任何對該 DB 的修改或是問題都會影響到所有使用到該 DB 的微服務元件，
因此比較好的做法是針對每個應用的需求去選擇自己的 DB，不需要強迫與勉強所有微服務共用同樣的 DB。

3. Use asynchronous communication to achieve loose coupling

為了避免打造一個非常複雜互相依賴的元件關係圖，可以考慮使用非同步的方式來處理不同元件之間的溝通請求，這邊提出兩種方式
譬如可以考慮使用 message bus 之類的系統，讓你的元件將相關的事件內容都推向到 Message bus 的系統，然後其他的元件針對自己有興趣的主題去讀取內容來處理。

4. Fail fast by using a circuit breaker to achieve fault tolerance
5. Proxy your microservice requests through an API Gateway
6. Ensure your API changes are backwards compatible
7. Version your microservices for breaking changes
8. Have dedicated infrastructure hosting your microservice
9. Create a separate release train
10. Create Organizational Efficiencies


剩下有興趣的就去閱讀全文囉

ref: https://towardsdatascience.com/tired-of-airflow-try-this-c51ec26cd29d

本篇文章是探討的是類似於 Airflow 但是更為輕量與簡易的管理工具，Prefect

作者加入公司初期的首要目標就是決定一個用來分析資料的架構，網路上查來查去會看到很多關於 airflow 的相關介紹文，但是作者仔細比較與評估後，認為 Airflow 更加適合一個團隊專屬維運與使用，
而自己這家新創公司能夠負責這個工作的只有一個人，也就是作者自己。
時間有限的情況下，作者希望能夠將大部分的時間放在最有價值的工作，因此會希望這個解決方案能夠盡量的簡潔有力，最後就找到一個名為 Prefect 的替代方案。

Prefect 是一個 workflow 的解決方案，一樣可以用來建制，運行與監控各式各樣的 data pipeline。使用方面也不會太困難， Prefect 是基於 Python 撰寫的，所以熟悉 Python 的使用者都可以滿輕鬆的去建立屬於自己的 Data pipeline.

作者有先嘗試過使用 Airflow，結果整個環境建置複雜，嘗試使用 astronomer 來搭建整個環境結果也屢屢碰壁，讓作者更為崩潰的是 astronomer 的支援服務也不好，有問題有找不到圖隊處理
因此花費不少時間測試後，最後還是決定轉往 Prefect，因為其整體使用起來更容易上手

文章中還有其他關於這兩個專案的比較以及作者其他在意的點，對於這領域有興趣的可以參考

一個 patch 去修改 Linux Kernel 底層針對 TCP 連線釋放 skb (Kernel 內放所有網路的物件) 的時間點，竟然可以讓 100G 網卡的效能提升不少
Tested:
100Gbit NIC
Max throughput for one TCP_STREAM flow, over 10 runs
MTU : 1500
Before: 55 Gbit
After: 66 Gbit
MTU : 4096+(headers)
Before: 82 Gbit
After: 95 Gbit
從 MTU 1500 的情況來看提升竟然有 20% 左右，MTU 4096 大概也有 15% 左右。
這故事告訴我們底層基本功還是很重要，資源的使用與釋放的時機沒有處理好是可能白白浪費你一堆的系統效能的。

ref: https://fluxcd.io/blog/2021-11-10-flux-security-audit/

Flux 與 ArgoCD 可以說是 Kubernetes 中較為出名的 GitOps 解決方案，而這篇文章是 Flux 來分享關於該專案目前針對資安方面的安全性進展，也包含一個近期的 CVE-2021-41254 介紹。

Flux 本身是 CNCF 內的孵化專案，資安方面與 OSTIF (the Open Source Technology Improvement Fund) 與 ADA Logics 等互相合作，而這篇文章就是 ADA Logics 再分析 Flux 開源程式碼後所觀察到的相關問題
最重要的是 Flux 專案的第一個 CVE 就此誕生，任何可以創建 Kubernetes Secret, Service Account 與 Flux Kustomization CRD 的使用者都可以透過一系列的手法提權最後透過 kubectl 來獲得整個 Cluster 的權限。

這個 CVE 已經於 Flux v0.15.0 修復，所以如果你有使用 Flux 且版本是低於 v0.15.0 的，那非常推薦趕緊升級來修復 CVE，避免叢集被人提權操控。

ADA Logics 總共發現 22 獨立的潛在問題，其中包含 5 個 informational 等級， 13 個低嚴重性， 3 個中等嚴重性以及一個被判為 CVE 的高危險性。

本篇文章後續還有分享這些問題的相關分類以及這些問題該如何處理，有興趣的可以閱讀全文

ref: https://engineering.linkedin.com/blog/2021/building-in-the-cloud-with-remote-development

本篇文章是 LinkedIn 的技術分享文，探討如何透過 Kubernetes 打造一個遠端開發環境，什麼叫做遠端開發環境呢？ 就是本地開發，但是所有的資源消耗都是使用雲端資源來進行處理的開發模式。

LinkedIn 過往的經驗證明透過該套遠端開發環境能夠有效地簡化大部分產品的開發流程，讓所有的初始化與建制時間從過往的 10-30 分鐘降低到只要 10 秒左右，而這篇文章就是細探這套系統的概念。
LinkedIn 內的產品多元，使用的程式語言超多，譬如 Java, Python, C/C++, Go, JS, iOS 以及 Android，多元的環境其實對於對於每個新人來說都是個環境惡夢，設定方面總是要花費好多時間去處理，
同時作者也聽到不少同事討論產品建置與編譯的速度過慢連帶影響整個產品的開發效率。

COVID-19 期間，整個公司都採取遠端工作模式，所有的開發環境都變成以筆電為主，相較於桌機來說筆電的規格會使得如何使用有限的 CPU/Memory 等資源來建置與開發公司產品。

遠端開發環境這個專案的目的就是希望能夠改善開發效率，希望能夠提供一個基於遠端存取，高依賴性，高效率且簡易操作的遠端開發環境，而這套環境就稱為 RDevs。

RDevs 架構是基於 Container 去提供每個開發者一個開發建置環境，而這些 Container 透過 remote SSH 的方式來開發者存取，同時因為架構的關係，這些 container 能夠更有效與更快地去存取各種網路資源，
圖中提到以 LinkedId 一個大型的應用程式來看，使用 PDevs 建制的時間大概只有一兩分鐘，而一個本地擁有 16Core 的 macOS 則需要五分鐘， 4 core 數量的 macOS 則需要高達 15 分鐘左右的建置時間。
這種情況下開發者就可以用 RDev 來處理所有的建置需求，而所有的操作都是基於 SSH，因此只需要確保自身的網路環境能夠提供有效率的 SSH 環境即可，也不用擔心筆電上的各種背景應用程式影響整個建置速度。

RDev 架構是基於 Kubernetes 開發的，所有的建置環境其實就是一個又一個的 Kubernetes Pod，每個 Pod 是由多個不同功能的 Container 所組成，同時這些 Pod 也會透過 Mount 的方式來準備相關的使用資料，譬如開發者的家目錄
為了讓整體運作更加順利， RDev 還開發了自己的 Operator，能夠根據開發者的需求而動態產生 Pod 來使用，此外也有提到使用 PostStart Hook, Startup Probe 等相關概念。

這篇文章非常實在的展現了 Kubernetes 的不同用法，如何透過 Kubernetes 來提升團隊內的建置與編譯速度進而提升開發效率。

ref: https://medium.com/system-design-concepts/tinyurl-system-design-16868b5435de

本篇又是另外一個系統設計的分享文，想要探討的是如何想要設計一個 tinyurl 的系統，那到底有哪些事項需要注意？

TinyURL 的概念很簡單，使用者輸入一串 URL，最後回傳一串很短的 URL 讓使用者更方便存取，然後整個設計簡單為主。
這次的 tinyurl 先假設該系統需要滿足的條件有
1. 使用者數量: 三千萬使用者
2. 短網址長度: 使用 7 個字元

根據上述需求，先來估計要使用的資料結構與整體大小
1. Long URL: 2KB -> 2048 chars
2. Short URL: 7 bytes -> 7 chars
3. Created at: 7 bytes -> 7 chars
4. Expire at: 7 bytes -> 7 chars

所以每一個欄位大概需要 2069 Bytes，大概就是 2.021 KB，所以三千萬個使用者來說，如果要
1. 保存一個月，那至少需要 60.63 GB
2. 保存一年就需要 727 GB
3. 保存五年則需要 3.6 TB 左右

根據這些使用量會用來幫忙評估最後要使用 RDBMS 或是 NoSQL DB

# 7個字元的產生
作者提出兩種簡易方法來產生一個長度七的URL
1. 給定一個大數，使用 base62(0-9a-zA-Z) 的方式去產生出一個長度七的字串
2. 給定一個唯一字串(Long URL)並且基於 base62 回傳一個長度七的字串，譬如使用 MD5 來處理，但是MD5前七個字元就有可能會發生重複的問題，不同的 Long URL 最後得到相同的 7個字元。

基於 base62 的短網址總共有 62^7 總可能，相對於 Base10 只有一百萬來說，62^7 大概有 3.5 兆左右可能性。
所以如果採用第一個方式就是針對每個 LongURL 去產生一個不重複的隨機數字，並且將該數字以 base62 呈現來代表短網址。

# 第一種方式
假設今天已經選好短網址了，下一個步驟就是要將這個 long url 與 short url 的關係給寫入到資料庫中
但是寫入並不是單純寫入這麼簡單，因為亂數的產生是有可能重複的，因此當前產生的 short url 是有可能已經存在於 DB 之中，這種情況下就需要重新產生亂數直到找到一個沒有被使用過的 short url.
如果整個系統只有一個人會進行讀寫的話，這種操作基本上沒有問題，但是要是同時有多個系統要進行讀寫又沒有相關機制妥善處理的話，就會發生重複資料被同時寫入到DB內了。

一種解決方式就是讓 shortURL 變成所謂的 unique key，同時還可以搭配 `put if not exists` 等概念讓 DB 本身來處理這類型的限制，不過這部分的功能通常只有 RDBMS 有支援，如果是 NoSQL 的話則沒有辦法搞定。


# 第二種方式
假設採用的是 MD5 的方式來處理 long url 並且取前七個字元來使用，基本上跟前述會有一樣的問題，都有可能會發生不同的 long url 最後獲得相同的短網址，
這情況下還是會有重複資料的問題

# 別的想法
使用 counter 的概念，將 counter 以 base62 的方式來呈現，不過這個作法只適合單一 server 來處理，當同時有多個 server 時又變成要維護 counter 的共同讀寫問題。

雖然探討的是 TinyURL 的簡易實作，但是作者後半部分還繼續探討如何導入 ZooKeeper 讓上述的環境可以同時部署多個 server，藉此來處理更大規模的需求。
有興趣的可以閱讀全文

ref: https://www.linuxjournal.com/content/everything-you-need-know-about-linux-containers-part-i-linux-control-groups-and-process

本篇文章是個深度技術文，認真探討 Container 技術底下的 Control Groups 以及 Process Isolation 到底是什麼。
Container 這個詞大家都聽說，也很多人聽過到底如何實作 Container 這種輕量級虛擬化概念的，但是以 Linux 為範例，到底真正技術上的實作是什麼這點則是硬知識，而本篇文章是個 container 系列文
希望能夠讓讀者對於 Container 的實作有更進一步的理解。

為了穩定性與安全性，事實上大部分的應用程式都應該受到相關程度的控管與限制，避免應用程式出現問題影響到其他應用程式或是機器本身，而 Linux Kernel 有提供一個名為
Control Groups (cgroup) 的概念用來限制與隔離不同的資源，譬如 CPU, Memory, DIsk I/O 以及 network。

cgroup 當初設計的目的是希望提供一個統一的介面讓管理者可以去管理多個 process 或是系統本身，該系統能夠達到
1. 資源控管: 控管群組特定資源的使用量不能超過多少
2. 優先順序: 控管該群組可以使用的資源量是更多或是更少，跟其他群組競爭時使用的優先權。
3. 資源監控: 可以監控與測量群組內的資源用量
4. 控管: 可以凍結，停止或是重啟群組內的應用程序

每個 cgroup 都是由數個 process 所組成的，這些 process 都會套用到相同的設定。同時為了提供更好的管理方式， cgroup 還提供了階層式的管理，就像 Tree 的架構一樣，
子節點會繼承自根節點的設定。
Kernel 內根據不同的資源實作不同的 controller，譬如 memory controller 則是專注於 memory 相關的設定，而 cpuacct 則是專注於 CPU 的使用量。

文章後半段就是實戰操控，如何透過系統上的 /sys/fs/cgroup 資料夾來跟 cgroup 互動，包含基本的資料檢查與創建一個範例應用程式
簡易的方式也可以使用 cgroup 系列的工具，譬如 cgcreate, cgexec, cgdelete 來操作。
如果系統中有運行 Kubernetes 環境有設定相關資源控管的話，是很推薦使用這類型的工具來幫忙釐清 YAML 設定與底層的關係，藉此加強自己對這方面的認知。

ref: https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/

Dockershim 從 Kubernetes 中移除的時間逐漸逼近，所有 Kubernetes 的使用者都明瞭這個改變並且準備好面對了嗎?

Dockershim 這個元件過去設計的目的是為了讓 Kubernetes 可以使用 Docker 作為底層的 Container Runtime，Kubernetes 意圖使用 CRI 來兼容百川，所以需要 dockershim 這層將所有的請求給轉移到 Dockerd 進行處理。
如今有愈來愈多的 Container Runtime 原生或是更容易支援 CRI 的標準，所以 Dockershim 存在的必要性也就逐漸下降。

根據目前的計畫， dockershim 將於 kuvernetes 1.24 給正式移除，大概會於 2022/04 左右發布該版本，對於 1.24 想要進行測試的玩家可以於今年年底先行使用看看 1.24 的 alpha/beta 版本。

文章中還有列出一份 dockershim migration documentation 的文件來介紹該如何檢視當前系統的設定以及要轉移需要注意哪些事項
此外如果你的 Kubernetes 是由第三方服務所架設與維護的，譬如 GKE/AKS/EKS/Rancher..等諸如環境，那就需要去確認這些服務是否有提供其他的 container runtime 選擇以及未來更新時應該要採取何種升級方式。

如果對於 dockershim 移除對於 kubernetes 使用者會有什麼影響還是不清楚的可以參閱這個影片
https://www.youtube.com/watch?v=nc3mBN3LzvM&t=62s

ref: https://medium.com/system-design-concepts/whatsapp-system-design-b094cbded096

本篇也是一個系統設計的分享文，這類型的文章都是從一個真實應用出發去分享一些可能的設計方式，這些設計方式不是萬靈丹也不是準則，單純是一個不同的思考方式
對於讀者我們來說也是一個思考的好機會，看看作者所講述的架構是否合理，以及如果自己去實作的話可能會採取何種架構去實作。

這篇文章想要探討的是類似 WhatsApp 這類型聊天通訊軟體的實作架構，聊天軟體不外乎就是
1. 互相傳遞訊息
2. 訊息是否已讀
3. 傳送不同類型的檔案
4. 加密
5. 通話

而這篇文章大抵上只有涵蓋前面三個功能的探討。

作為一個聊天通訊軟體，基本的架構都會是 Client/Server 架構， Client 就是所有使用該 app 的使用者，而 Server 則是背後幫忙進行訊息交換複雜處理的角色，文章中使用 messaging server 的代號來形容這個 server。
為了能夠處理大量的使用者，適度的根據用量去調整 messaging server 的數量是必要的，所以 client 連接上就不會直接跟這些 server 進行連線，相反的則是會使用 load-balancer 的概念來幫忙處理連線。

接者 server 架構中一定也會有相關資料庫的存在，文章中沒有特別探討要使用 RDBMS 還是 NoSQL。

試想一個情況，當 Client A 想要離線傳送訊息給 Client B 的時候，偏偏這時候 Client A 的手機沒有網路，沒有辦法連上 server，那這些訊息勢必都會存在於
手機端上的空間，可能是伴隨app的小型資料庫或是任何形式。當 Client A 順利連上 server 後就會將這些訊息給傳送到 server 上。
但是如果此時 Client B 也沒有跟 server 有連線，那這些要傳送的訊息理所當然的也要先暫時存放到 server 上，待 Client B 連上線後就會將這些訊息一次性的傳送給 Client B，接者 Client B 就能夠順利的收到這些訊息。

從上述的一個流程就可以看到只是簡單的傳送訊息中間就會牽扯到三個不同的角色，更何況有些軟體想要提供點到點的加密傳送服務，基本上還是要依賴 server 幫忙轉發，只是傳送的內容是否加密與否而已。

文章後去探討使用基於 Thread/Process 的概念來處理每個連線，然後不同的情況下要如何做到已讀的功能，同時如果還想要知道對方上一次看的時間是什麼時候這類型的功能該怎麼實作。
對於傳送檔案如圖檔之類的檔案，如果想要整合 CDN 等概念近來家速食，又會導入其他 HTTP Server 來進行檔案存放，並且讓每個訊息都是夾帶這些媒體檔案的資訊，動態其他的 CDN server 抓取。

對於整體有興趣的可以閱讀全文。

ref: https://medium.com/@arielstkuo/not-just-a-pretty-face-%E9%81%8A%E6%88%B2%E7%95%AB%E9%9D%A2%E5%BE%8C%E4%BD%A0%E4%B8%8D%E7%9F%A5%E9%81%93%E7%9A%84%E4%BA%8B-frame-1-2d-3d-2-5d-f0465ad4b736

本篇不探討 Cloud Native 相關概念，而是從一個科普文來分享一下遊戲世界的基本概念。
作者身為一個前暴雪員工，對於遊戲開發有諸多經驗，且本文非常貼近一般玩家日常同時又不會有太過於艱深的詞彙與技術，更重要的還是一篇實實在在的中文分享文。

資深遊戲玩家來說一定對於 2D(平面)/3D(立體) 世界不陌生，從早期的 Gameboy 到現在 Switch/PS4/PS5 等擁有更佳運算效能的主機後，愈來愈多的遊戲都會採用 3D 的方式來製作，但是你知道除了簡單的 2D 與 3D 之外，還有一個介於中間的 2.5D 嗎?

2.5D 的遊戲想要透過 2D 的平面素材來打造出一個類似於 3D 立體環境，同時看起來又不能太假，不能讓玩家一眼就覺得這整體不協調太奇怪，
文章中列舉了不少範例來解釋不同類型的 2.5D 以及使用最近才重製的 Diablo II 來進行比較，讓你看看到底早期的 Diablo II 是如何用 2D 裝 3D 以及後來採用全 3D 重新製作後的差異。

文章內科普了基本的固定視角模式外，也介紹了利用視差錯覺造成的距離感，可以讓開發商用較低的遊戲成本來打造出一個近似 3D 的遊戲環境。

簡單來說，本篇就是一個遊戲科普文，分享一些關於 2D, 3D, 2.5D 的一些概念，
有興趣的歡迎閱讀全文

ref: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d40ce48cb3a68b54be123a1f99157c5ac613e260

又是一個非常有趣的 kernel patch, 光看標題「af_unix: Replace unix_table_lock with per-hash locks.」就可以感覺到這次的改動很有機會帶來效能上的改變。

過往的 AF_UNIX socket 依賴一個大 lock 來管理 kernel 內所管理的所有 AF_UNIX socket，而這個 patch 就採用基於 hash 的方式創建多個小 lock 來個別管理，光用直覺都覺得整體效能會有進步的空間。

不過要特別注意的是本 patch 修改的只有 AF_UNIX socket 這類型的服務，所以採取 TCP 等 socket 依然還是本來的做法。常見使用這種 domain socket 有 containerd, cri-o 等，不過這類型的服務本身就不是 I/O 為主，所以就算改成多 lock 似乎也不會有什麼明顯的幫助。
不知道大家有沒有注意有什麼 I/O 很重的服務預設都會吃 domain socket 的？
有的話不彷使用包含該 patch 版本的 kernel 來測試看看效能是否有顯著的改變